I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n

ITU-T G.8275.2/Y.1369.2
TELECOMMUNICATION (06/2016)
STANDARDIZATION SECTOR
OF ITU

SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

DIGITAL SYSTEMS AND NETWORKS
Packet over Transport aspects – Synchronization, quality
and availability targets
SERIES Y: GLOBAL INFORMATION
INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS
AND NEXT-GENERATION NETWORKS, INTERNET OF
THINGS AND SMART CITIES
Internet protocol aspects – Transport
Precision time protocol telecom profile for
phase/time synchronization with partial timing
support from the network

Recommendation ITU-T G.8275.2/Y.1369.2

 ITU-T G-SERIES RECOMMENDATIONS
TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS

INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100–G.199

GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER- G.200–G.299
TRANSMISSION SYSTEMS
INDIVIDUAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE G.300–G.399
SYSTEMS ON METALLIC LINES
GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS G.400–G.449
ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH METALLIC
LINES
COORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY G.450–G.499
TRANSMISSION MEDIA AND OPTICAL SYSTEMS CHARACTERISTICS G.600–G.699
DIGITAL TERMINAL EQUIPMENTS G.700–G.799
DIGITAL NETWORKS G.800–G.899
DIGITAL SECTIONS AND DIGITAL LINE SYSTEM G.900–G.999
MULTIMEDIA QUALITY OF SERVICE AND PERFORMANCE – GENERIC AND USER- G.1000–G.1999
RELATED ASPECTS
TRANSMISSION MEDIA CHARACTERISTICS G.6000–G.6999
DATA OVER TRANSPORT – GENERIC ASPECTS G.7000–G.7999
PACKET OVER TRANSPORT ASPECTS G.8000–G.8999
Ethernet over Transport aspects G.8000–G.8099
MPLS over Transport aspects G.8100–G.8199
Synchronization, quality and availability targets G.8200–G.8299
Service Management G.8600–G.8699
ACCESS NETWORKS G.9000–G.9999

For further details, please refer to the list of ITU-T Recommendations.

 ITU-T Y-SERIES RECOMMENDATIONS
GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-
GENERATION NETWORKS, INTERNET OF THINGS AND SMART CITIES

GLOBAL INFORMATION INFRASTRUCTURE

General Y.100–Y.199
Services, applications and middleware Y.200–Y.299
Network aspects Y.300–Y.399
Interfaces and protocols Y.400–Y.499
Numbering, addressing and naming Y.500–Y.599
Operation, administration and maintenance Y.600–Y.699
Security Y.700–Y.799
Performances Y.800–Y.899
INTERNET PROTOCOL ASPECTS
General Y.1000–Y.1099
Services and applications Y.1100–Y.1199
Architecture, access, network capabilities and resource management Y.1200–Y.1299
Transport Y.1300–Y.1399
Interworking Y.1400–Y.1499
Quality of service and network performance Y.1500–Y.1599
Signalling Y.1600–Y.1699
Operation, administration and maintenance Y.1700–Y.1799
Charging Y.1800–Y.1899
IPTV over NGN Y.1900–Y.1999
NEXT GENERATION NETWORKS
Frameworks and functional architecture models Y.2000–Y.2099
Quality of Service and performance Y.2100–Y.2199
Service aspects: Service capabilities and service architecture Y.2200–Y.2249
Service aspects: Interoperability of services and networks in NGN Y.2250–Y.2299
Enhancements to NGN Y.2300–Y.2399
Network management Y.2400–Y.2499
Network control architectures and protocols Y.2500–Y.2599
Packet-based Networks Y.2600–Y.2699
Security Y.2700–Y.2799
Generalized mobility Y.2800–Y.2899
Carrier grade open environment Y.2900–Y.2999
FUTURE NETWORKS Y.3000–Y.3499
CLOUD COMPUTING Y.3500–Y.3999
INTERNET OF THINGS AND SMART CITIES AND COMMUNITIES
General Y.4000–Y.4049
Definitions and terminologies Y.4050–Y.4099
Requirements and use cases Y.4100–Y.4249
Infrastructure, connectivity and networks Y.4250–Y.4399
Frameworks, architectures and protocols Y.4400–Y.4549
Services, applications, computation and data processing Y.4550–Y.4699
Management, control and performance Y.4700–Y.4799
Identification and security Y.4800–Y.4899

For further details, please refer to the list of ITU-T Recommendations.

Recommendation ITU-T G.8275.2/Y.1369.2

Precision time protocol telecom profile for phase/time synchronization

with partial timing support from the network

Summary
Recommendation ITU-T G.8275.2/Y.1369.2 contains the ITU-T precision time protocol (PTP)
profile for phase/time distribution with partial timing support from the network (unicast mode). It
provides the necessary details to utilize IEEE 1588 in a manner consistent with the architecture
described in Recommendation ITU-T G. 8275/Y.1369. This Recommendation defines the PTP
profile for unicast mode only. Future editions of this Recommendation may contain a separate
profile for a mixed unicast/multicast case.

History
Edition Recommendation Approval Study Group Unique ID*
1.0 ITU-T G.8275.2/Y.1369.2 2016-06-22 15 11.1002/1000/12833

Keywords
IEEE 1588, partial timing support, phase and time synchronization, PTP, telecom profile.

* To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web
browser, followed by the Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/11
830-en.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) i

 FOREWORD
The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
telecommunications, information and communication technologies (ICTs). The ITU Telecommunication
Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical,
operating and tariff questions and issuing Recommendations on them with a view to standardizing
telecommunications on a worldwide basis.
The World Telecommunication Standardization Assembly (WTSA), which meets every four years,
establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on
these topics.
The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.
In some areas of information technology which fall within ITU-T's purview, the necessary standards are
prepared on a collaborative basis with ISO and IEC.

NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some
other obligatory language such as "must" and the negative equivalents are used to express requirements. The
use of such words does not suggest that compliance with the Recommendation is required of any party.

INTELLECTUAL PROPERTY RIGHTS

ITU draws attention to the possibility that the practice or implementation of this Recommendation may
involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence,
validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others
outside of the Recommendation development process.
As of the date of approval of this Recommendation, ITU had not received notice of intellectual property,
protected by patents, which may be required to implement this Recommendation. However, implementers
are cautioned that this may not represent the latest information and are therefore strongly urged to consult the
TSB patent database at http://www.itu.int/ITU-T/ipr/.

 ITU 2016
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the
prior written permission of ITU.

ii Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

 Table of Contents
Page
1 Scope............................................................................................................................. 1
2 References..................................................................................................................... 1
3 Definitions .................................................................................................................... 2
3.1 Terms defined elsewhere ................................................................................ 2
3.2 Terms defined in this Recommendation ......................................................... 2
4 Abbreviations and acronyms ........................................................................................ 2
5 Conventions .................................................................................................................. 3
6 Use of PTP for phase/time distribution ........................................................................ 4
6.1 High-level design requirements ...................................................................... 4
6.2 PTP modes and options .................................................................................. 5
6.3 PTP modes ...................................................................................................... 7
6.4 PTP mapping .................................................................................................. 8
6.5 Message rates.................................................................................................. 8
6.6 Unicast message negotiation .......................................................................... 8
6.7 Alternate BMCA, telecom slave model and master selection process ........... 11
6.8 Phase/time traceability information ................................................................ 19
6.9 Use of alternate master flag ............................................................................ 20
7 ITU-T PTP profile for phase/time distribution with partial timing support from the
network ......................................................................................................................... 21
8 Security aspects ............................................................................................................ 21
Annex A – ITU-T PTP profile for time distribution with partial timing support from the
network (unicast mode) ................................................................................................ 22
A.1 Profile identification ....................................................................................... 22
A.2 PTP attribute values ........................................................................................ 22
A.3 PTP options .................................................................................................... 26
A.4 Best master clock algorithm options .............................................................. 27
A.5 Path delay measurement option (delay request/delay response) .................... 27
A.6 Configuration management options ............................................................... 27
A.7 Clock identity format ...................................................................................... 28
A.8 Security aspects .............................................................................................. 28
A.9 Other optional features of IEEE 1588 ............................................................ 28
A.10 PTP common header flags .............................................................................. 28
Annex B – Options to establish the PTP topology with the Alternate BMCA ........................ 29
Annex C – Inclusion of an external phase/time input interface on a PTP clock...................... 30
Annex D – TLV for PTP interface rate (optional) ................................................................... 31
Annex E – Synchronization uncertain indication (optional) .................................................... 33

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) iii

 Page
Appendix I – Considerations on the use of priority2 ............................................................... 34
Appendix II – Considerations on a T-TSC-A or T-TSC-P connected to an end application .. 35

iv Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

Recommendation ITU-T G.8275.2/Y.1369.2

Precision time protocol telecom profile for phase/time synchronization

with partial timing support from the network

1 Scope
This Recommendation specifies a profile for telecommunication applications based on IEEE 1588
precision time protocol (PTP). The profile specifies the IEEE 1588 functions that are necessary to
ensure network element interoperability for the delivery of accurate phase/time (and frequency)
synchronization. The profile is based on the partial timing support (PTS) from the network
architecture as described in [ITU-T G.8275] and definitions described in [ITU-T G.8260].
It is assumed that this profile will be used in well-planned cases where network behaviour and
performance can be constrained within well-defined limits, including limits on static asymmetry.
Control of static asymmetries can be achieved in case of assisted partial timing support. Use of this
profile in non-assisted mode would require careful considerations on how to control static
asymmetries.
This version of the profile specifies the high-level design requirements, modes of operation for the
exchange of PTP messages, the PTP protocol mapping, the best master clock algorithm (BMCA)
options, as well as the PTP protocol configuration parameters.
Further information on the setup of the protocol in the network is planned to be included in future
versions of this Recommendation. In particular, this information will be related to architectures that
imply rearrangements of the synchronization direction, and to architectures that include clocks with
multiple PTP ports, especially when ports not in the MASTER state provide synchronization
services.
At the time of publication of this profile, performance analysis, network limits, and clocks used in
the profile, namely boundary and slave clocks, are for further study.
This Recommendation also specifies some aspects necessary for use in a telecom environment that
are outside the scope of the PTP profile, but complement it.

2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[ITU-T G.781] Recommendation ITU-T G.781 (2008), Synchronization layer functions.
[ITU-T G.810] Recommendation ITU-T G.810 (1996), Definitions and terminology for
synchronization networks.
[ITU-T G.8260] Recommendation ITU-T G.8260 (2015), Definitions and terminology for
synchronization in packet networks.
[ITU-T G.8265.1] Recommendation ITU-T G.8265.1/Y.1365.1 (2014), Precision time protocol
telecom profile for frequency synchronization.
[ITU-T G.8271] Recommendation ITU-T G.8271/Y.1366 (2016), Time and phase
synchronization aspects of packet networks.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 1

[ITU-T G.8272] Recommendation ITU-T G.8272/Y.1367 (2012), Timing characteristics of
primary reference time clocks.
[ITU-T G.8273] Recommendation ITU-T G.8273/Y.1368 (2013), Framework of phase and time
clocks.
[ITU-T G.8273.2] Recommendation ITU-T G.8273.2/Y.1368.2 (2014), Timing characteristics of
telecom boundary clocks and telecom time slave clocks.
[ITU-T G.8275] Recommendation ITU-T G.8275/Y.1369 (2013), Time and phase distribution
through packet networks.
[ITU-T G.8275.1] Recommendation ITU-T G.8275.1/Y.1369.1 (2016), Precision time protocol
telecom profile for phase/time synchronization with full timing support from
the network.
[IEEE 1588] IEEE 1588 (2008), IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems.

3 Definitions

3.1 Terms defined elsewhere

This Recommendation uses the following terms defined elsewhere:
The terms and definitions used in this Recommendation are contained in [ITU-T G.810] and
[ITU-T G.8260].

3.2 Terms defined in this Recommendation

None.

4 Abbreviations and acronyms

This Recommendation uses the following abbreviations and acronyms:
APTS Assisted Partial Timing Support
BC Boundary Clock
BMCA Best Master Clock Algorithm
ePRTC Enhanced Primary Reference Time Clock
EUI Extended Unique Identifier
GM GrandMaster
GNSS Global Navigation Satellite System
IP Internet Protocol
OC Ordinary Clock
ParentDS Parent Data Set
PDV Packet Delay Variation
PRC Primary Reference Clock
PRS Primary Reference Source
PRTC Primary Reference Time Clock
PTP Precision Time Protocol
PTPVAR PTP Variance

2 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

PTS Partial Timing Support
PTSF Packet Timing Signal Fail
QL Quality Level
SDH Synchronous Digital Hierarchy
SF Signal Fail
SSM Synchronization Status Message
SSU Synchronization Supply Unit
SSU-A Primary level SSU
SSU-B Secondary level SSU
ST2 Stratum 2
ST3E Stratum 3 Enhanced
T-BC-P Partial-Support Telecom Boundary Clock
TC Transparent Clock
T-GM Telecom Grandmaster
TLV Type, Length, Value
T-TC-P Partial-Support Telecom Transparent Clock
T-TSC-A Assisted Partial-Support Telecom Time Slave Clock
T-TSC-P Partial-Support Telecom Time Slave Clock
UDP User Datagram Protocol
VLAN Virtual Local Area Network

5 Conventions
Within this Recommendation, the following conventions are used: the term PTP refers to the PTP
version 2 protocol defined in [IEEE 1588]. PTP messages used within this Recommendation are
defined in [IEEE 1588] and are identified using italicized text.
The term telecom grandmaster (T-GM) refers to a device consisting of a grandmaster (GM) clock as
defined in [IEEE 1588] and this Recommendation, with additional performance characteristics for
further study.
The term partial-support telecom boundary clock (T-BC-P) refers to a device consisting of a
boundary clock (BC) as defined in [IEEE 1588], with additional performance characteristics for
further study. A T-BC-P may be assisted by having a primary reference time clock (PRTC) (e.g.,
global navigation satellite system (GNSS)) support.
The term partial-support telecom transparent clock (T-TC-P) refers to a device consisting of a
transparent clock (TC) as defined in [IEEE 1588], with additional performance characteristics for
further study.
The term partial-support telecom time slave clock (T-TSC-P) refers to a device consisting of either
an ordinary clock (OC), with one PTP port, or a boundary clock (BC), with multiple PTP ports, as
defined in [IEEE 1588] and this Recommendation, that does not support providing synchronization
using PTP to other PTP clocks in the PTP domain, and with additional performance characteristics
for further study. A T-TSC-P may be assisted by having PRTC (e.g., GNSS) support.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 3

The term assisted partial-support telecom time slave clock (T-TSC-A) refers to a T-TSC-P that is
assisted by having PRTC (e.g., GNSS) support as a primary source of time. Note: In the case of a
T-TSC-A or T-TSC-P, with multiple PTP ports (BC), only one PTP port can be in PTP SLAVE
state at any instant in time based on the BMCA. Other PTP ports not in the PTP SLAVE state may
actively exchange synchronization messages with other PTP clocks populated in the unicast master
table using unicast negotiation.
The term primary reference time clock (PRTC) refers to the clock defined in [ITU-T G.8272]. The
term enhanced primary reference time clock (ePRTC) refers to an enhanced version of the PRTC,
which is being studied.

6 Use of PTP for phase/time distribution

The 2002 version of the IEEE 1588 standard was developed by the IEEE initially to support the
timing requirements of industrial automation and test and measurement, defining the precision time
protocol (PTP) designed to enable accurate time transfer in this context.
The 2008 version of IEEE 1588 (defined in [IEEE 1588]) contains features useful to the transport of
the protocol over a wide area network, and introduces the concept of "profile", whereby aspects of
the protocol may be selected and specified for a particular use other than the originally intended
industrial automation.
A PTP profile was defined by ITU-T in [ITU-T G.8265.1] to address applications requiring
frequency synchronization only. An additional PTP profile was defined by ITU-T in
[ITU-T G.8275.1] in order to allow the distribution of phase/time with full timing support from the
network. This Recommendation defines another PTP profile to allow the distribution of phase and
time with partial timing support (PTS) from the network.
The [IEEE 1588] telecom profile defined within this Recommendation is intended to be used by
telecom applications requiring accurate phase and time synchronization. It covers applications
where there is need for phase alignment and/or time of day. It supports the specific architecture
described in [ITU-T G.8275] in order to allow the distribution of phase/time with PTS from the
network, and is based on the 2008 version of PTP defined in [IEEE 1588]. This includes the case of
assisted partial timing support (APTS).
This profile uses only the unicast mode.
In order to claim compliance with the telecom profile, the requirements of this Recommendation
and the relevant requirements of [IEEE 1588], as referenced in Annex A, must be met.
The detailed aspects related to the telecom profile are described in the following clauses, while the
profile itself is contained in Annex A. It follows the general rules for profile specification developed
in [IEEE 1588].
This PTP telecom profile defines the [IEEE 1588] parameters to be used, in order to guarantee
protocol interoperability between implementations and specifies the optional features, default
values of configurable attributes and mechanisms that must be supported. However, it does not
guarantee that the performance requirements of a given application will be met. Those performance
aspects are currently under study, and imply additional elements beyond the content of the PTP
profile itself. These are planned to be addressed in other ITU-T Recommendations.

6.1 High-level design requirements

Clause 19.3.1.1 of [IEEE 1588] states:
"The purpose of a PTP profile is to allow organizations to specify specific selections of attribute
values and optional features of PTP that, when using the same transport protocol, inter-work and
achieve a performance that meets the requirements of a particular application."

4 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

For operation in a telecom network, some additional criteria are also required to be consistent with
standard telecom synchronization practices. With that in mind, the PTP profile for time and phase
distribution must meet the following high-level requirements:
1) Mechanisms must be specified to allow interoperability between the various phase/time
clocks belonging to the architecture defined in [ITU-T G.8275] and described in
[ITU-T G.8273].
2) Mechanisms must permit consistent operation over managed wide area telecom networks.
3) Packet-based mechanisms must allow the synchronization network to be designed and
configured in a fixed arrangement.
4) Protection schemes used by packet-based systems must be based on standard telecom
operational practice and allow partial-support telecom time slave clocks (T-TSC-P and
T-TSC-A) to have the ability to take phase and time from multiple geographically separate
T-GM clocks.
5) Phase/time reference source selection based on received phase/time traceability and local
priority, as well as automatic establishment of the phase/time synchronization network
topology, should be permitted.

6.2 PTP modes and options

6.2.1 PTP Domains
A domain consists of a logical grouping of clocks communicating with each other using the PTP
protocol.
PTP domains are used to partition a network within an administrative domain. The PTP messages
and data sets are associated with a domain and therefore the PTP protocol is independent for
different domains.
In this PTP telecom profile, the default PTP domain number is 44, and the range of applicable PTP
domain numbers is {44 – 63}.
NOTE  This range has been selected from the user-defined PTP domain number range defined in
[IEEE 1588]. Although non-overlapping ranges have been considered for the different PTP telecom profiles
so that interactions between the profiles are prevented, nothing precludes another industry from using the
same user-defined PTP domain number range when defining a non-telecom PTP profile. It is the
responsibility of the network operator to identify if the risk of unintentional interactions between PTP
profiles exists, and to take the necessary actions to prevent such behaviour.
6.2.2 PTP messages
[IEEE 1588] defines two categories of message types: event and general PTP messages. The two
types differ in that event messages are timed messages and require or contain an accurate
timestamp. General message types do not require accurate timestamps.
[IEEE 1588] defines the following message types: Sync, Delay_Req (i.e., "delay request"),
Announce, Follow_Up, Delay_Resp (i.e., "delay response"), Pdelay_Req, Pdelay_Resp, and
Pdelay_Resp_Follow_Up, Management and Signalling.
Sync, Delay_Req, Announce, Follow_Up, Delay_Resp, and Signalling messages are used in this
profile.
Pdelay_Req, Pdelay_Resp, and Pdelay_Resp_Follow_Up messages are not used in this profile.
The use of Management messages is for further study.
6.2.3 Types of PTP clocks supported in the profile
The OC and BC according to [IEEE 1588] are used in this profile.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 5

There are two types of OCs:
1) OC that can only be a grandmaster (T-GM according to the architecture defined in
[ITU-T G.8275], and as included in [ITU-T G.8272]).
2) OC that can only be a slave, i.e., slave-only OC (T-TSC-P with only one port or T-TSC-A
with only one port according to the architecture defined in [ITU-T G.8275]). The clock
specifications for T-TSC-P and T-TSC-A are for further study.
There are three types of BCs:
1) BC that can only be a grandmaster (T-GM according to the architecture defined in
[ITU-T G.8275], and as included in [ITU-T G.8272]).
2) BC that can become a grandmaster and can also be slaved to another PTP clock (T-BC-P
according to architecture defined in [ITU-T G.8275]). The clock specifications for T-BC-P
are for further study.
3) BC that can only be a slave (T-TSC-P with more than one port or T-TSC-A with more than
one port according to the architecture defined in [ITU-T G.8275]). The clock specifications
for T-TSC-P and T-TSC-A are for further study.
NOTE  T-GM and GM are different concepts; GM is a status defined in [IEEE 1588] that a PTP clock may
obtain if it wins the BMCA, while T-GM is a type of clock defined in the [ITU-T G.8275] architecture.
The mapping between these PTP clock types and the phase/time clocks defined in the
[ITU-T G.8275] architecture is described in Table 1.

Table 1  Mapping between [ITU-T G.8275.2] and PTP clock types

Clock type from Description Clock type from
[ITU-T G.8275.2] [IEEE 1588]
Master-only ordinary clock
(master with a single PTP port, cannot be slaved to another OC
PTP clock)
T-GM
Master-only boundary clock BC
(master with multiple PTP ports, cannot be slaved to another
PTP clock) (Note)

Boundary clock
T-BC-P BC
(may become a GM, or may be slaved to another PTP clock)
Slave-only, single port, ordinary clock
OC
(always a slave)
T-TSC-P
PTP clock at the end of the PTP synchronization chain, BC
multiple port clock (Note)
Slave-only, single port, ordinary clock
OC
(always a slave) with local PRTC assistance
T-TSC-A
PTP clock at the end of the PTP synchronization chain, BC
multiple port clock with local PRTC assistance (Note)
NOTE – According to [IEEE 1588], a clock that has multiple PTP ports is by definition a boundary clock.

6 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

6.3 PTP modes
[IEEE 1588] describes several modes of operation between a master-port (which is a PTP in
MASTER state) and a slave-port (which is a PTP port in SLAVE state). The term grant-port refers
to a PTP port granting and providing PTP message service, and the term request-port refers to a
PTP port requesting and receiving PTP message service. Typically, the grant-port is a master-port
and the request-port is a slave-port. Information related to grant-ports and request-ports in other
PTP states will be included in a future version of this Recommendation related to PTP clocks with
multiple PTP ports.
NOTE 1 – A grant-port may be in the MASTER state, PASSIVE state, LISTENING state, PRE_MASTER
state, UNCALIBRATED state, or SLAVE state. (but not INITIALIZING, FAULTY, or DISABLED state).
NOTE 2 – A request-port may be in the MASTER state, PASSIVE state, LISTENING state, PRE_MASTER
state, UNCALIBRATED state, or SLAVE state. (but not INITIALIZING, FAULTY, or DISABLED state).
This clause describes these modes with respect to functionality needed to be compliant with this
profile.
6.3.1 One-way versus two-way operation
A PTP master-port or grant-port compliant with the profile must be capable of supporting one-way
and two-way timing transfers. For APTS, since only PTP synchronization may be required, a slave-
port or request-port may only utilize one-way mode, or may utilize two-way mode, but is not
required to support both methods; otherwise for PTS, a slave-port or request-port must utilize
two-way.
NOTE – In the APTS case, even if performance objectives are specified by means of two-way metrics, this
does not prevent the slave-port or request-port from utilizing one-way mode, although for a more accurate
interpretation of how the network characteristics relates to the expected performance of the clock, two-way
operation may be preferred.
6.3.2 One-step versus two-step clock mode
PTP defines two types of clock behaviour: the "one-step clock" and the "two-step clock". In a one-
step clock, the precise timestamp is transported directly in the Sync message. In a two-step clock, a
Follow_Up message is used to carry the precise timestamp of the corresponding Sync message. The
use of Follow_Up messages is optional in the PTP protocol.
The one-step clock approach enables equipment to reduce significantly the number of PTP
messages sent by the master-port or grant-port, and relax the master-port or grant-port capacities.
However, there might be situations where the two-step clock approach might be required (e.g.,
when some security features are required). These situations are for further study.
Both one-step and two-step clocks are allowed in the profile. A PTP master-port or grant-port
compliant with the profile may use either a one-step clock or a two-step clock or both.
NOTE – The performance of the PTP timing flow generated by the master-port or grant-port with those two
approaches is for further study.
To be compliant with [IEEE 1588], a slave-port or request-port must be capable of handling both
one-step clock and two-step clock, without any particular configuration.
As per clause 7.3.8.3 of [IEEE 1588], when a two-step clock is used, the value of the flag
"twoStepFlag" shall be TRUE to indicate that a Follow_up message will follow the Sync message,
and that the slave-port or request-port must not consider the originTimestamp embedded in the Sync
message. When a one-step clock is used, the value of the flag "twoStepFlag" shall be FALSE, and
the slave-port or request-port must consider the originTimestamp embedded in the Sync message in
this case.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 7

6.3.3 Unicast versus multicast mode
PTP allows the use of unicast and multicast modes for the transmission of the PTP messages.
For the PTP profile specified in Annex A, the unicast mode is used for all the PTP messages.
A master-port or grant-port compliant with the PTP profile specified in Annex A must support the
unicast mode.
A slave-port or request-port compliant with the PTP profile specified in Annex A must support the
unicast mode.

6.4 PTP mapping

This PTP telecom profile is based on the PTP mapping defined in [IEEE 1588] Annex D, Transport
of PTP over User Datagram Protocol over Internet Protocol Version 4 and [IEEE 1588] Annex E,
Transport of PTP over User Datagram Protocol over Internet Protocol Version 6.
Therefore, a master-port, grant-port, slave-port, or a request-port compliant with the profile
described in this Recommendation must be compliant with [IEEE 1588] Annex D and may be
compliant with [IEEE 1588] Annex E.
NOTE – The use of the Internet Protocol (IP)/user datagram protocol (UDP) mapping is to facilitate the use
of IP addressing. It does not imply that the PTP flow can be carried over an unmanaged packet network. It is
assumed that a well-controlled packet network will be used to control and minimize packet delay variation.

6.5 Message rates

The message rate values are only defined for protocol interoperability purposes. It is not expected
that any slave clock shall meet the relevant target performance requirements at all packet rates
within the given range, specifically at the lower packet rate. The appropriate value depends on the
clock characteristics and on the target performance requirements. Different packet rate needs may
also apply during the stabilization period.
NOTE – A specific slave clock implementation, in order to meet its target performance requirements, may
support a subset of the message rates within the ranges noted below. A master-port or grant-port, on the other
hand, is required to support the full range of message transmission rates. Unless an implementation specifies
otherwise, the default value listed below is assumed to be used.
Within the scope of the profile, the following messages can be used and the corresponding indicated
range of rates must be respected for unicast messages:
– Sync messages (if used, Follow_up messages will have the same rate) – minimum rate: 1
packet-per-second, maximum rate: 128 packets-per-second.
– Delay_Req/Delay_Resp messages – minimum rate:1 packet-per-second, maximum rate:
128 packets-per-second.
– Announce messages – minimum rate:1 packet-per-second, maximum rate: eight packets-
per-second.
– Signalling messages – no rate is specified.
The use of Management messages is for further study.

6.6 Unicast message negotiation

Within a telecommunication network, there are benefits to allowing PTP request-ports to request the
synchronization service from PTP grant-ports. [IEEE 1588] offers a mechanism to allow request-
ports to request this service within a unicast environment (see [IEEE 1588] clause 16.1). This
profile supports the unicast message negotiation in accordance with [IEEE 1588] and as described
below.

8 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

PTP clocks compliant with the profile must support the unicast negotiation mechanism as per
clause 16.1 of [IEEE 1588] and as described in this clause.
When using the unicast mode, PTP request-ports request synchronization service by sending a PTP
Signalling message in unicast, containing the REQUEST_UNICAST_TRANSMISSION type,
length, value (TLV), to the IP address of the selected PTP grant-port.
NOTE 1 – In this telecom profile, unicast connection establishment without negotiation is for further study.
The Signalling message containing the REQUEST_UNICAST_TRANSMISSION TLV is
periodically renewed.
When initiating unicast negotiation with a grant-port, a request-port can use all 1's as the initial
value for the targetPortIdentity field of the Signalling message. Based on the response from the
grant-port, the request-port can then learn the clockIdentity and portNumber of the grant-port and
may use this in any subsequent Signalling message. The request-port may also continue to use all
1's. Similarly, the grant-port may either learn and use the clockIdentity and portNumber of the
request-port, or use all 1's value for the targetPortIdentity field of the Signalling messages that it
sends. Both grant-port and request-port must be prepared to handle both situations in reception, i.e.,
receive PTP Signalling messages with either their own clockIdentity and portNumber or with all 1's
values for the targetPortIdentity field.
The logInterMessagePeriod can be configured to adjust the requested transmission rate of Sync,
Announce and Delay_Resp messages.
The configurable range for the logInterMessagePeriod is given in Annex A for all the relevant
messages.
The durationField value in each REQUEST_UNICAST_TRANSMISSION TLV has a default
initialization value of 300 seconds and a configurable range of 60 to 1000 seconds.
In the event that a PTP grant-port is unable to meet a given request-port request, it should deny the
request entirely rather than offer the request-port less than it originally requested.
In the event of being denied service by a grant-port, or receiving no response to the service request:
– A request-port should wait a minimum of one second (after denial or no response received)
before issuing a new unicast service request for that message type to the same grant-port.
– If a request-port has issued three service requests for the same message type with either no
response or a "grant denied" response, it should either:
• cancel any granted unicast service it may have for other message types, and request
service from a different grant-port, or
• wait a further 60 seconds before re-issuing the request to the same grant-port.
An example of the message exchange to initiate the unicast synchronization service is shown in
Figure 1. The timing diagram example represents the exchange of unicast messages for a one-step
clock (i.e., no Follow_up messages) using one-way mode (i.e., no Delay_Req or Delay_Resp).
The example shows a unicast negotiation process for a packet request-port sending Signalling
messages for Announce and Sync requests; a packet grant-port granting the packet request-port the
requested message rates; a packet grant-port transmitting the requested Announce and Sync message
rates and the renewal of Announce and Sync before the expiration of durationField.
Note that several timing diagrams could be represented based on various exchanges of message
types, the use of single or concatenated TLVs in Signalling messages, the use of different
durationFields for each message type, etc. Figure 1 provides an example of message interaction;
it is for illustrative purposes only and does not represent a particular implementation.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 9

 Figure 1 – Unicast negotiation example

PTP request-ports may request several types of PTP messages from a PTP grant-port (e.g., request-
port working in two-way mode, which may request Sync and Delay_Resp messages, or request-port
requesting Announce and Sync messages from the same grant-port). To request unicast transmission
of different PTP message types, and to respond to such requests, [IEEE 1588] allows the use of a
single Signalling message containing multiple TLVs or the use of multiple Signalling messages.
Grant-ports and request-ports compliant with this profile must be prepared to handle those two
situations. The expected behaviour during the initial negotiation and during the consecutive unicast
service renewals is described in the paragraphs that follow.
Each request for unicast transmission from a specific request-port to a grant-port should start by
issuing an Announce service type request first for that specific grant-port. Only after the request-
port has been granted unicast service for the Announce message and received the first unicast
Announce message from the specified grant-port, can the rest of the service type request take place.
Such practice would ensure that the attributes (e.g., clockQuality) and capabilities of the specified
grant-port are acceptable from the request-port's perspective before the rest of the services are
contracted.
Upon receiving the first Announce message from the grant-port, the first Signalling message
containing a REQUEST_UNICAST_TRANSMISSION TLV issued by the request-port should
include all the service types the specific request-port requires from the grant-port using multiple
REQUEST_UNICAST_TRANSMISSION TLVs. Such practice will reduce the chance that the
grant-port will only grant part of the requested services in case it has been over-subscribed (due to
simultaneous requests from other request-ports). The grant-port is allowed to respond to this request
either with a single Signalling message containing multiple TLVs, or with multiple Signalling
messages (e.g., each containing a single TLV).

10 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

When renewing the unicast services, the request-port, in sending Signalling messages (for 'keep-
alive' purposes), may either continue to request all service types with a single Signalling message
containing multiple TLVs, or with multiple independent Signalling messages (e.g., each containing
a single TLV). The grant-port is allowed to respond to requests either with a single Signalling
message containing multiple TLVs, or with multiple Signalling messages (e.g., each containing a
single TLV).
The following text provided in clause A.9.4.2 of [IEEE 1588] should be followed: "For receiving
continuous service, a requester should reissue a request in advance of the end of the grant period.
The recommended advance should include sufficient margin for reissuing the request at least two
more times if no grant is received."
In case the unicast transmission sessions are cancelled as defined in clause 16.1.1 of [IEEE 1588], a
PTP clock cancelling several types of PTP messages may use a single Signalling message
containing multiple TLVs or multiple Signalling messages. Grant-ports and request-ports compliant
with this profile must be prepared to handle those two situations.
The PTP clock cancelling the session may either cancel the multiple service types with a single
Signalling message containing multiple CANCEL_UNICAST_TRANSMISSION TLVs, or with
multiple independent Signalling messages (e.g., each containing a single
CANCEL_UNICAST_TRANSMISSION TLV). The other PTP clock receiving the cancellation is
allowed to respond to these requests either with a single Signalling message containing multiple
ACKNOWLEDGE_CANCEL_UNICAST_TRANSMISSION TLVs, or with multiple independent
Signalling messages (e.g., each containing a single
ACKNOWLEDGE_CANCEL_UNICAST_TRANSMISSION TLV).
NOTE 2 – The "renewal invited" flag described in [IEEE 1588] clause 16.1.4.2.6 is not used in this profile.

6.7 Alternate BMCA, telecom slave model and master selection process
This clause describes the Alternate BMCA algorithm, the telecom slave model and the associated
master selection process. These are described in the following clauses.
6.7.1 Alternate BMCA
The PTP profile specified in this Recommendation uses an Alternate BMCA, as described in
clause 9.3.1 of [IEEE 1588]. This Alternate BMCA differs from the default BMCA of [IEEE 1588]
in the following:
a) The Alternate BMCA considers the per-port Boolean attribute masterOnly. If masterOnly is
TRUE, the port is never placed in the SLAVE state, and will always go to the MASTER
state. If masterOnly is FALSE, the port can be placed in the SLAVE state. The masterOnly
attribute is set via the configurable port data set member portDS.masterOnly.
The default value and range of values for this attribute, for the ports of a BC or OC that can
only be a GM (i.e., T-GM), are TRUE and {TRUE}.
The default value and range of values for this attribute, for the port of a slave-only OC
(i.e., T-TSC-P or T-TSC-A) are FALSE and {FALSE}.
The default value and range of values for this attribute, for the ports of a BC that may or
may not be a GM (i.e., T-BC-P) are TRUE and {TRUE, FALSE}.
b) The computation of Erbest is according to the description provided in clause 9.3.2.3 of
[IEEE 1588], with the exception that the Erbest of a port r must be set to the empty set when
the masterOnly attribute of this port r is set to TRUE, irrespective of any other
consideration. This is so that the computation of Ebest will not use the information contained
in any Announce messages received on a port r where the masterOnly attribute is set to
TRUE.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 11

c) The Alternate BMCA allows for multiple clocks to be active GMs simultaneously (clocks
with clockClass less than 128 cannot be a slave). If there are multiple active GMs, every
clock that is not a GM is synchronized by a single GM in the PTP domain.
d) The per-port attribute localPriority is assigned to each port r of a clock and is used in the
determination of Erbest and Ebest. Each parent clock or foreign master clock data set, whose
Announce information was received on the port r, is appended with the localPriority
attribute of the local port r before the data set comparison defined in Figure 3 and Figure 4
below is invoked. The localPriority attribute is not transmitted in Announce messages. This
attribute is used as a tie-breaker in the data set comparison algorithm, in the event that all
other previous attributes of the data sets being compared are equal. The localPriority
attribute is set via the configurable, unsigned integer, port data set member
portDS.localPriority. The data type for this attribute is UInteger8. The range of values for
this attribute is {1-255}. The default value for this attribute is 128. A clock compliant with
this PTP profile is allowed to support a subset of the values defined in the range.
e) The attribute localPriority is assigned to the local clock, to be used if needed when the data
associated with the local clock, D0, is compared with data on another potential GM received
via an Announce message. The local clock localPriority attribute is set via the configurable,
unsigned integer, default data set member defaultDS.localPriority. The data type for this
attribute is UInteger8. The range of values for this attribute is {1-255}. The default value
for this attribute is 128. A clock compliant with this PTP profile is allowed to support a
subset of the values defined in the range.
f) The data set comparison algorithm is modified according to Figures 3 and 4 in clause 6.7.9.
NOTE 1  Because the value of the masterOnly attribute is, per definition, always TRUE on all PTP ports of
a T-GM, the localPriority attribute is, in practice, not used for a T-GM.
NOTE 2  For a T-GM, the Alternate BMCA output is in practice static and provides a recommended state =
BMC_MASTER, because the masterOnly attribute = TRUE for all the PTP ports of a T-GM. The resulting
decision code can be M1 or M2 (see Figure 2 below), depending on the status of the T-GM (i.e., clockClass
value of the T-GM).
NOTE 3 – When the value of the masterOnly attribute is TRUE on a PTP port, the PTP port typically does
not request unicast services from other ports.
6.7.2 Considerations on the use of the localPriority attributes
The localPriority attributes provide a powerful tool in defining the synchronization network
architecture.
The use of the default values for these attributes as defined by the Alternate BMCA results in a
timing-loop free synchronization network.
Proper planning will be mandatory to avoid timing-loops when configuring values different from
the default ones.
6.7.3 Static clock attribute priority1
In this PTP profile, the clock attribute priority1 is static. It is initialized to a default value equal to
the midpoint value, 128, of its range, and this value must not be changed.
The priority1 parameter is not used in this version of the PTP telecom profile. Future versions may
consider using this attribute, this is for further study.
6.7.4 Clock attribute priority2
In this PTP profile, the clock attribute priority2 is configurable.

12 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

It is initialized to a default value, equal for T-GM and T-BC-P clocks to the midpoint value, 128, of
its range {0-255}. The default value for T-TSC-P and T-TSC-A clocks is 255, and the range is
{255}.
A T-GM or T-BC-P compliant with this PTP profile must support all the values of priority2 defined
in the range. A T-TSC-P or T-TSC-A compliant with this profile must support, on reception, all the
values of priority2 defined in the full [IEEE 1588] range (i.e., {0-255}).
Appendix I describes possible use cases for the priority2 attribute; other cases are for further study.
6.7.5 Clock attribute clockClass
A PTP clock compliant with this PTP profile must support all values of clockClass upon reception
(shall not discard) defined in the full [IEEE 1588] range. The applicable values of the clock
attribute clockClass are specified in clause 6.8 of this Recommendation.
NOTE 1  The behaviour on reception of a clockClass value not specified in Table 2 is for further study.
6.7.6 Clock attribute clockAccuracy
A PTP clock compliant with this PTP profile must support all the values of clockAccuracy upon
reception (shall not discard) defined in the full [IEEE 1588] range. The values that can be
transmitted in the clockAccuracy field are shown in Table A.1. The following values of the clock
attribute clockAccuracy apply for the following situations:
– 0x20 for a T-GM connected to an ePRTC in locked-mode (i.e., e PRTC traceable to
GNSS).
– 0x21 for a T-GM connected to a PRTC in locked-mode (i.e., PRTC traceable to GNSS).
– 0xFE for a T-BC-P not connected to a GNSS in locked mode on a virtual PTP port.
The clockAccuracy for a T-BC-P when connected to a GNSS in locked mode on a virtual PTP port
is for further study.
6.7.7 Clock attribute offsetScaledLogVariance
The following values of the clock attribute offsetScaledLogVariance apply for the following
situations:
– 0x4B32 for a T-GM connected to an ePRTC in locked-mode (i.e., ePRTC traceable to
GNSS). This corresponds to TDEV of 10 ns, at observation interval of 10000 seconds. The
corresponding value of PTP Variance (PTPVAR) is 1.271  10–16 s2 (see Appendix IX of
[ITU-T G.8275.1]).
– 0x4E5D for a T-GM connected to a PRTC in locked-mode (i.e., PRTC traceable to GNSS)
This corresponds to TDEV of 30 ns, at observation interval of 10000 seconds. The
corresponding value of PTPVAR is 1.144  10–15 s2 (see Appendix IX of
[ITU-T G.8275.1]).
– 0xFFFF for a T-GM not connected to a PRTC in locked-mode.
– 0xFFFF for a T-BC-P not connected to a GNSS in locked mode on a virtual PTP port.
The offsetScaledLogVariance for a T-BC-P when connected to a GNSS in locked mode on a virtual
PTP port is for further study.
6.7.8 State decision algorithm
The state decision algorithm applicable to the Alternate BMCA of the PTP profile specified in this
Recommendation is given in Figure 2. After a decision is reached by use of this algorithm, the data
sets of the local clock are updated as specified in clause 9.3.5 of [IEEE 1588]. Details on the use of
the algorithm are given in clause 9.3.3 of [IEEE 1588].

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 13

6.7.9 Data set comparison algorithm
The data set comparison algorithm for the Alternate BMCA of the PTP profile specified in this
Recommendation is given in Figures 3 and 4 below. With this algorithm, one clock is compared
with another using the data sets representing those clocks, appended with the localPriority attribute.
Details on the use of the algorithm are given in clause 9.3.4 of [IEEE 1588].
If either of the data sets, A or B, in Figures 3 and 4 contain the data of the parent clock or a foreign
master clock, the corresponding localPriority for its data set is the localPriority of the local port r on
which the information from that parent clock or foreign master clock has been received (see item
(d) of clause 6.7.1).
If either of the data sets, A or B, in Figures 3 and 4 contain the data of the local clock, D0, the
corresponding localPriority for that data set is the localPriority of the local clock (see item (e) of
clause 6.7.1).
NOTE 1  It is recommended that the entire data set comparison algorithm described in Figures 3 and 4 be
implemented even if some parameters are currently static, because they may be used in future versions of
this Recommendation.
NOTE 2 – For the block "Compare SF values of A and B" in Figure 3, the comparison is made based on the
values of 1 for TRUE and 0 for FALSE. Signal fail (SF) is described in clause 6.7.11.

14 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

Figure 2  State decision algorithm for Alternate BMCA

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 15

 Figure 3  Data set comparison algorithm, part 1, for Alternate BMCA

16 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

 Figure 4  Data set comparison algorithm, part 2, for Alternate BMCA

NOTE 3 – stepsRemoved used in the BMCA does not characterize or reflect the amount of packet delay
variation (PDV) or asymmetry on a connection. The BMCA may not select the path with the lowest PDV or
asymmetry.
6.7.10 Unused PTP fields
Some PTP fields are not used in this PTP profile. This clause defines the actions applicable to these
unused PTP fields.
Table A.6 in clause A.10 of this Recommendation defines the PTP common header flag values, and
whether or not each flag is used in this profile.
In addition, the following fields are not used in this profile:
– The "controlField" in the common header of PTP messages is not used in this profile. This
field must be ignored by the receiver for all types of PTP messages.
– The "priority1" field in the Announce message is not used, and must be set to a fixed value
specified in clause 6.7.3.
When a PTP clock receives a PTP message with a field, whose use is not specified in this PTP
profile, containing a value outside the allowed range, then this field of the PTP message must be
ignored, without discarding the PTP message.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 17

As an example, a PTP clock compliant with this PTP profile must ignore on reception the field
value for the following fields. A clock compliant with this PTP profile must not update its local data
sets with the ingress value for these fields.
– flagField – PTP profile Specific 1
– flagField – PTP profile Specific 2
When a PTP clock receives a PTP message with a field, whose use is specified in this PTP profile,
containing a value outside the allowed range for reception, then this entire PTP message must be
discarded. Except for the attributes clockClass, clockAccuracy, offsetScaledLogVariance, and
priority2 (see clauses 6.7.4, 6.7.5, 6.7.6 and 6.7.7), the ranges for reception and defaultDS members
are the same.
As an example, a compliant clock must discard on reception the ingress packet (General and Event
messages) when any of the following fields are outside of the allowed range for the profile. The
clock's local data set must not be updated with the ingress value.
– domainNumber
– versionPTP
– flagField – unicastFlag
NOTE 1  If a clock receives an Announce message with the "priority1" field set to a value other than 128,
and if the clock advertising this value is selected as the GM, then 128 must be re-advertised by the receiving
clock. The unused attribute priority1 is ignored by the receiving clock for the purpose of the Alternate
BMCA.
NOTE 2  The allowed ranges for reception for the clock attributes priority2, clockClass, clockAccuracy,
and offsetScaledLogVariance are the respective full [IEEE 1588] ranges, see clauses 6.7.4, 6.7.5, 6.7.6 and
6.7.7 of this Recommendation.
6.7.11 Packet timing signal fail
This clause defines the notion of packet timing signal fail (PTSF), which corresponds to a signal
indicating a failure of the PTP packet timing signal received by the slave.
Two types of PTSF may be raised in a slave implementation:
1) PTSF-lossSync, lack of reception of PTP timing messages from a master (loss of the packet
timing signal): if the slave no longer receives the timing messages sent by a master (i.e.,
Sync and subsequently Follow_up and Delay_Resp messages), then a PTSF-lossSync
associated to this master must occur. A timeout period for reception of Sync messages or
Delay_Resp messages (these are analogous to "syncReceiptTimeout" and
"delayRespReceiptTimeout" in [ITU-T G.8265.1]) for these timing messages must be
implemented in the slave before triggering the PTSF-lossSync (the range and default value
of this timeout parameter are for further study).
2) PTSF-unusable, unusable PTP packet timing signal received by the slave, exceeding the
input tolerance of the slave (noisy packet timing signal): if the PTP packet timing signal is
not usable for the slave to achieve the performance target (e.g., violates the slave input
tolerance because of excessive PDV noise), then a PTSF-unusable associated to this master
must occur. The criteria used to determine that the packet timing signal is not suitable to be
used is for further study (An example of criteria to be studied may relate to the PDV
experienced by the packet timing signal as it traverses the network from the master to the
slave).
When a PTSF occurs, the clock will set the PTP portDS.SF to TRUE and generate a state decision
event.

18 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

6.8 Phase/time traceability information
In order to deliver phase/time traceability information, the clockClass values described in Table 2
below must be used in this PTP telecom profile.
The frequencyTraceable flag present in the header of the PTP messages is defined in this profile as
follows: if the PTP clock is traceable to a PRTC in locked mode or to a primary reference clock
(PRC), e.g., using a PRC-traceable physical layer frequency input, then this parameter must be set
to TRUE, otherwise it must be FALSE. This flag is not used in the Alternate BMCA defined in
clause 6.7; the values provided for this flag in Table 2 can be used by the network operator for
monitoring purposes or by the end applications to take definitive action as described in Appendix II.
When a T-GM first enters holdover, it downgrades the clockClass value that it uses to 7. It then
calculates if the time error at its output is still within the holdover specification. When the T-GM
determines that the time error at its output has exceeded the holdover specification, it downgrades
the clockClass value that it uses to 140, 150 or 160 depending on the quality of its frequency
reference (internal oscillator or physical layer frequency signal received on an external interface).
As an example, when a T-BC-P first enters holdover, it downgrades the clockClass value that it uses
to 135. It then calculates if the time error at its output is still within the holdover specification.
When the T-BC-P determines that the time error at its output has exceeded the holdover
specification, it downgrades the clockClass value that it uses to 165 (internal oscillator or received
physical layer frequency signal on an external interface).
NOTE 1  The applicable holdover specification depends on the design and budgeting of the synchronization
network.
NOTE 2  The case of a T-BC-P acting as a GM, with an external phase/time input coming from a PRTC, is
handled by means of a virtual PTP port with associated Erbest attributes as described in Annex C of this
Recommendation. The general case of a T-BC-P with a phase/time external synchronization input different
from PRTC is for further study.

Table 2 – Applicable clockClass values

Phase/time traceability description defaultDS frequencyTraceable timeTraceable
clockClass flag flag
T-GM connected to a PRTC in locked 6 TRUE TRUE
mode (e.g., PRTC traceable to GNSS)
T-GM in holdover, within holdover 7 TRUE TRUE
specification, traceable to Category 1
frequency source
(Note 1)
T-GM in holdover, within holdover 7 FALSE TRUE
specification, non-traceable to Category 1
frequency source
(Note 1)
T-BC-P in holdover, within holdover 135 TRUE TRUE
specification, traceable to Category 1
frequency source
(Note 1)
T-BC-P in holdover, within holdover 135 FALSE TRUE
specification, non-traceable to Category 1
frequency source
(Note 1)
T-GM in holdover, out of holdover 140 TRUE FALSE

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 19

 Table 2 – Applicable clockClass values
Phase/time traceability description defaultDS frequencyTraceable timeTraceable
clockClass flag flag
specification, traceable to Category 1
frequency source
(Note 1)
T-GM in holdover, out of holdover 150 FALSE FALSE
specification, traceable to Category 2
frequency source
(Note 1)
T-GM in holdover, out of holdover 160 FALSE FALSE
specification, traceable to Category 3
frequency source
(Note 1)
T-BC-P in holdover, out of holdover 165 (Note 2) FALSE
specification
(Note 1)
T-GM, T-BC-P, T-TSC-P, or T-TSC-A 248 (Note 2) FALSE
without time reference since start-up
T-TSC-P or T-TSC-A acting as an OC 255 (Note 2) As per PTP
NOTE 1 – The holdover specification threshold controlling the time spent advertising clockClass values 7
or 135 could be set to zero so that the T-GM or T-BC-P would advertise a degraded clockClass value
directly after losing traceability to a PRTC. In this case, initially after advertising clockClass values 140,
150, 160 or 165, a clock may still be within the holdover specification. For a description of frequency
source "Category" see Table 3 below.
NOTE 2 – The frequencyTraceable flag may be TRUE or FALSE, depending on the availability of a PRC-
traceable physical layer frequency input signal.
NOTE 3 – The term "holdover" in this table refers to "time holdover".
Table 3 describes how the clock quality levels (QLs) defined in [ITU-T G.781] are mapped to
Category 1, 2, and 3 frequency sources used in Table 2.

Table 3  Mapping of [ITU-T G.781] clock QLs to

Category 1, 2, 3 frequency sources
Category ITU-T G.781 ITU-T G.781
(in Table 2) Option I QLs Option II QLs
Category 1 frequency source QL-PRC QL-PRS
Category 2 frequency source QL-SSU-A QL-ST2
Category 3 frequency source QL-SSU-B QL-ST3E

6.9 Use of alternate master flag

A PTP clock must only synchronize to a PTP timing service being provided by its parent clock,
whose port is in the PTP MASTER state. To ensure this operation, this profile uses the
alternateMasterFlag field defined in clause 7.3.8.2 of [IEEE 1588] with the following behaviour.
a) On transmission of an Announce message, a PTP port will set the alternateMasterFlag to 0
when the transmitting PTP port state is MASTER; otherwise the PTP port must set the
alternateMasterFlag to 1.

20 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

b) Referring to clause 13.3.2.6 of [IEEE 1588], the alternateMasterFlag is only set on
transmission of Announce, Sync, Follow_Up and Delay_Resp messages.
c) On reception, a PTP port that receives a PTP Announce message with alternateMasterFlag
value 1 must discard (and not process) the message. For example, such an Announce
message must not be input into the BMCA.
While the alternateMasterFlag is used in this version of the profile, clause 17.4 of [IEEE 1588] is
not used.

7 ITU-T PTP profile for phase/time distribution with partial timing support from the
network
The [IEEE 1588] profile that supports time distribution in unicast mode is contained in Annex A.

8 Security aspects
Security aspects are for further study.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 21

 Annex A

ITU-T PTP profile for time distribution with partial timing support from the
network (unicast mode)
(This annex forms an integral part of this Recommendation.)

This annex contains the telecom profile for time distribution as required by [IEEE 1588]. In order to
claim compliance with the telecom profile, the requirements in this annex and in the body of this
Recommendation must both be met.

A.1 Profile identification

profileName: ITU-T PTP profile for time distribution with partial timing support from the network
(unicast mode)
profileVersion: 1.0
profileIdentifier: 00-19-A7-02-01-00
This profile is specified by ITU-T.
A copy may be obtained from www.itu.int.

A.2 PTP attribute values

The default values and ranges of the PTP attributes for use in this profile are contained in
Tables A.1, A.2, A.3, A.4 and A.5. For the attributes clockClass, clockAccuracy,
offsetScaledLogVariance, and priority2, the ranges shown are those for the defaultDS.
NOTE – A boundary clock follows the rules of [IEEE 1588] for selection of parent clock, updating of
parentDS, and transmission of Announce messages, so it may transmit values different from the defaultDS
values.
Attributes not specified by this profile shall use the [IEEE 1588] default initialization values and
ranges.

22 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

 Table A.1  defaultDS data set member specifications
Clause Members of the data Telecom grandmaster Partial support telecom Partial support telecom
from set requirements time slave clock boundary clock
[IEEE requirements requirements
1588]

Default Range Default Range Default Range

initialization initialization initialization
value value value
8.2.1.2.1 defaultDS.twoStepFlag As per PTP {FALSE, As per PTP {FALSE, As per PTP {FALSE,
(static) TRUE} TRUE} TRUE}

8.2.1.2.2 defaultDS.clockIdentity As per PTP, As per PTP As per PTP, As per As per PTP, As per PTP
(static) based on based on PTP based on
EUI-64 EUI-64 EUI-64
format format format
8.2.1.2.3 defaultDS.numberPorts 1 for OC {1} for OC 1 for OC {1} for As per PTP As per PTP
(static) As per PTP As per PTP As per PTP OC
for BC for BC for BC As per
PTP for
BC
8.2.1.3.1.1 defaultDS.clockQuality. 248 {6, 7, 140, 255 for OC {255} for 248 {135, 165,
clockClass 150, 160, 248 for BC OC 248}
(dynamic) 248} {248} for
BC
8.2.1.3.1.2 defaultDS.clockQuality. 0xFE As per 0xFE {0xFE} 0xFE {0xFE}
clockAccuracy (Note 2) PTP (Note 2) (Note 2) (Note 2) (Note 2)
(dynamic) (Note 2)
(Note 4)
8.2.1.3.1.3 defaultDS.clockQuality. 0xFFFF As per 0xFFFF {0xFFFF} 0xFFFF {0xFFFF}
offsetScaledLogVariance PTP
(dynamic) (Note 4)
8.2.1.4.1 defaultDS.priority1 128 {128} 128 {128} 128 {128}
(configurable) (Note 1) (Note 1) (Note 1) (Note 1) (Note 1) (Note 1)

8.2.1.4.2 defaultDS.priority2 128 {0-255} 255 {255} 128 {0-255}

(configurable)

8.2.1.4.3 defaultDS.domainNumber 44 {44-63} 44 {44-63} 44 {44-63}

(configurable)
8.2.1.4.4 defaultDS.slaveOnly FALSE {FALSE} TRUE for {TRUE} FALSE {FALSE}
(configurable) OC for OC
FALSE for {FALSE}
BC for BC
New defaultDS.localPriority 128 {1-255} 128 {1-255} 128 {1-255}
member (configurable)
New defaultDS.SF FALSE {FALSE} FALSE {FALSE} FALSE {FALSE}
member (dynamic)
NOTE 1 – As per PTP, not applicable for this profile.
NOTE 2 – For the case where the PTP grandmaster is syntonized to a PRC for frequency, but not synchronized to a reference
source of time, the grandmaster should set defaultDS.clockQuality.clockAccuracy to 0xFE, "UNKNOWN".
NOTE 3 –Equipment implementing multiple slave ports, with defaultDS.clockClass value of 255, should be treated as having
multiple instantiations of slave-only OCs. This is out of scope of this Recommendation.
NOTE 4 –Examples of applicable values are shown in clauses 6.7.6 and 6.7.7.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 23

 Table A.2  currentDS data set member specifications
Clause Members of the Telecom grandmaster Partial support telecom Partial support telecom
from data set requirements time slave clock boundary clock requirements
[IEEE requirements
1588]

Default Range Default Range Default Range

initialization initialization initialization
value value value
8.2.2.2 currentDS.stepsR As per PTP As per PTP As per PTP As per PTP As per PTP As per PTP
emoved
(dynamic)
8.2.2.3 currentDS.offset As per PTP As per PTP As per PTP As per PTP As per PTP As per PTP
FromMaster
(dynamic)
8.2.2.4 currentDS.mean As per PTP As per PTP As per PTP As per PTP As per PTP As per PTP
PathDelay
(dynamic)

Table A.3  parentDS data set member specifications

Clause Members of the Telecom grandmaster Partial support telecom Partial support telecom
from data set requirements time slave clock boundary clock
[IEEE requirements requirements
1588]

Default Range Default Range Default Range

initialization initialization initialization
value value value
8.2.3.2 parentDS.parentPort As per PTP As per PTP As per PTP As per PTP As per PTP As per PTP
Identity
(dynamic)
8.2.3.3 parentDS.parentStats (Note) (Note) (Note) (Note) (Note) (Note)
(dynamic)
8.2.3.4 parentDS.observedP (Note) (Note) (Note) (Note) (Note) (Note)
arentOffsetScaledL
ogVariance
(dynamic)
8.2.3.5 parentDS.observedP (Note) (Note) (Note) (Note) (Note) (Note)
arentClockPhaseCh
angeRate
(dynamic)
8.2.3.6 parentDS.grandmast As per PTP As per PTP As per PTP As per PTP As per PTP As per PTP
erIdentity
(dynamic)
8.2.3.7 parentDS.grandmast As per PTP As per PTP As per PTP As per PTP As per PTP As per PTP
erClockQuality
(dynamic)
8.2.3.8 parentDS.grandmast As per PTP As per PTP As per PTP As per PTP As per PTP As per PTP
erPriority1 (Note) (Note) (Note) (Note) (Note) (Note)
(dynamic)
8.2.3.9 parentDS.grandmast As per PTP As per PTP As per PTP As per PTP As per PTP As per PTP
erPriority2 (Note) (Note) (Note) (Note) (Note) (Note)
(dynamic)
NOTE  As per PTP, not applicable for this profile.

24 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

 Table A.4  timePropertiesDS data set member specifications
Clause Members of the Telecom grandmaster Partial support telecom Partial support telecom
from data set requirements time slave clock boundary clock
[IEEE requirements requirements
1588]
Default Range Default Range Default Range
initialization initialization initialization
value value value
8.2.4.2 timePropertiesDS.c As per PTP As per PTP As per PTP As per PTP As per PTP As per PTP
urrentUtcOffset
(dynamic)
8.2.4.3 timePropertiesDS.c FALSE {FALSE, FALSE {FALSE, FALSE {FALSE,
urrentUtcOffsetVali TRUE} TRUE} TRUE}
d
(dynamic)
8.2.4.4 timePropertiesDS.le FALSE {FALSE, FALSE {FALSE, FALSE {FALSE,
ap59 TRUE} TRUE} TRUE}
(dynamic)
8.2.4.5 timePropertiesDS.le FALSE {FALSE, FALSE {FALSE, FALSE {FALSE,
ap61 TRUE} TRUE} TRUE}
(dynamic)
8.2.4.6 timePropertiesDS.ti FALSE {FALSE, FALSE {FALSE, FALSE {FALSE,
meTraceable TRUE} TRUE} TRUE}
(dynamic)
8.2.4.7 timePropertiesDS.fr FALSE {FALSE, FALSE {FALSE, FALSE {FALSE,
equencyTraceable TRUE} TRUE} TRUE}
(dynamic) (Note) (Note) (Note)

8.2.4.8 timePropertiesDS.pt TRUE {TRUE} TRUE {TRUE} TRUE {TRUE}

pTimescale
(dynamic)
8.2.4.9 timePropertiesDS.ti 0xA0 As per PTP 0xA0 As per PTP 0xA0 As per PTP
meSource
(dynamic)

NOTE  If the clock is traceable to a PRTC in locked mode or a PRC (e.g., using a PRC-traceable physical layer frequency input),
then this parameter must be set to TRUE, otherwise it must be FALSE.

Table A.5  portDS data set member specifications

Clause Members of the Master port requirements Slave port requirements Partial support telecom
from data set of telecom grandmaster of partial support telecom boundary clock requirements
[IEEE time slave clock
1588]

Default Range Default Range Default Range

initialization initialization initialization
value value value
8.2.5.2.1 portDS.portIdentity. As per PTP, As per As per PTP, As per As per PTP, As per PTP
clockIdentity based on PTP based on PTP based on EUI-
(static) EUI-64 EUI-64 64 format
format format
8.2.5.2.1 portDS.portIdentity. 1 for OC {1} for OC 1 for OC {1} for OC As per PTP As per PTP
portNumber As per PTP As per As per PTP As per
(static) for BC PTP for for BC PTP for
BC BC
8.2.5.3.1 portDS.portState As per PTP As per As per PTP As per As per PTP As per PTP

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 25

 Table A.5  portDS data set member specifications
Clause Members of the Master port requirements Slave port requirements Partial support telecom
from data set of telecom grandmaster of partial support telecom boundary clock requirements
[IEEE time slave clock
1588]
(dynamic) PTP PTP

8.2.5.3.2 portDS.logMinDelay (Note 1) (Note 1) (Note 1) (Note 1) (Note 1) (Note 1)

ReqInterval
(dynamic)

8.2.5.3.3 portDS.peerMeanPat (Note 1) (Note 1) (Note 1) (Note 1) (Note 1) (Note 1)

hDelay
(dynamic)
8.2.5.4.1 portDS.logAnnounc (Note 1) (Note 1) (Note 1) (Note 1) (Note 1) (Note 1)
eInterval
(configurable)

8.2.5.4.2 portDS.announceRe 2 {2} As per PTP As per As per PTP As per PTP
ceiptTimeout PTP
(configurable)

8.2.5.4.3 portDS.logSyncInter (Note 1) (Note 1) (Note 1) (Note 1) (Note 1) (Note 1)

val
(configurable)

8.2.5.4.4 portDS.delayMecha 01 {01} '01' for a {01,FE} 01 {01}

nism (Note 2) (Note 2) two-way
(configurable) slave-port,
and 'FE' for a
one-way
slave-port
8.2.5.4.5 portDS.logMinPdela (Note 1) (Note ) (Note 1) (Note 1) (Note 1) (Note 1)
yReqInterval
(configurable)
8.2.5.4.6 portDS.versionNum 2 {2} 2 {2} 2 {2}
ber
(configurable)
New portDS.masterOnly TRUE {TRUE} FALSE {FALSE} TRUE {TRUE,
member (configurable) FALSE}
New portDS.localPriority 128 {1-255} 128 {1-255} 128 {1-255}
member (configurable)
New portDS.SF FALSE {FALSE} FALSE {TRUE, FALSE {TRUE,
member (dynamic) FALSE} FALSE}

NOTE 1  As per PTP, not applicable for this profile.

NOTE 2  The master must support two-way operation.

A.3 PTP options

A.3.1 Node types required, permitted or prohibited
In this profile, the permitted node types are: ordinary clocks and boundary clocks.
The use of transparent clocks is for further study.

26 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

A.3.2 Transport mechanisms required, permitted, or prohibited
In this profile, the required transport mechanism is UDP/IPv4 as per Annex D in [IEEE 1588]. Bit 0
of the transportSpecific field must be set to "0".
In this profile, a permitted transport mechanism is UDP/IPv6 as per Annex E in [IEEE 1588].
A.3.3 Unicast messages
All messages are sent in unicast.
In this telecom profile, unicast negotiation is enabled per default.
The slave will initiate the session by following the unicast message negotiation procedure defined in
[IEEE 1588] clause 16.1.
A.3.4 REQUEST_UNICAST_TRANSMISSION TLV
The value of logInterMessagePeriod is the logarithm, to base 2, of the requested mean period, in
seconds, between the requested unicast messages.
For requesting unicast Announce messages: The configurable range is 0 to –3 (which represents a
range from 1 message per second to eight messages per second). No default rate is specified.
For requesting unicast Sync messages: The configurable range is 0 to –7 (which represents a range
from 1 message per second to 128 messages per second). No default rate is specified.
For requesting unicast Delay_Resp messages: The configurable range is 0 to –7 (which represents a
range from 1 message per second to 128 messages per second). No default rate is specified.
The durationField value in each REQUEST_UNICAST_TRANSMISSION TLV has a default
initialization value of 300 seconds. The configurable range is 60 seconds to 1000 seconds.
NOTE 1 – A specific slave implementation, in order to meet its target performance requirements, as normal
operation, may support a subset of the message rates within the ranges noted above. A master, on the other
hand, is required to support the full range of message transmission rates. Unless an implementation specifies
otherwise, the default value listed above is assumed to be used.
NOTE 2 – A specific slave implementation may support a subset of the durationField values within the range
noted above. A master, on the other hand, is required to support the full range of durationField values.
Unless an implementation specifies otherwise, the default value listed above is assumed to be used.
The maintenance and configuration of these default and configuration range values is
implementation specific.
A.3.5 GRANT_UNICAST_TRANSMISSION TLV
In implementing the GRANT_UNICAST_TRANSMISSION TLV mechanism, the granted values
shall be the same as requested in the received REQUEST_UNICAST_TRANSMISSION TLV as
long as the requests are in the configurable range.

A.4 Best master clock algorithm options

This profile uses the Alternate BMCA described in clause 6.7 of this Recommendation.

A.5 Path delay measurement option (delay request/delay response)

The delay request/delay response mechanism can be used in this profile. The peer delay mechanism
shall not be used in this profile.

A.6 Configuration management options

Management aspects are for further study, and will be specified in a future version of this profile.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 27

A.7 Clock identity format
The use of IEEE EUI-64 to generate the clock identity must be supported as indicated in
clause 7.5.2.2.2 of [IEEE 1588]. Non-IEEE extended unique identifier (EUI) formats are not
supported.

A.8 Security aspects

Security aspects are for further study. The experimental security protocol of Annex K of
[IEEE 1588] is not used.

A.9 Other optional features of IEEE 1588

Other optional features of [IEEE 1588] are not used in this version of the profile. These include
alternate timescales (clause 16.3), grandmaster clusters (clause 17.3), alternate master (clause 17.4),
acceptable master table (clause 17.6), and the experimental cumulative frequency scale factor offset
(Annex L) all within [IEEE 1588].

A.10 PTP common header flags

The PTP common header flag values, and whether or not each flag is used in this profile, are given
in Table A.6.
NOTE  Some of these flags are used only in certain PTP messages, and not in all the PTP messages, see
[IEEE 1588] clause 13.3.2.6. The following rule defined in [IEEE 1588] clause 13.3.2.6, must be respected:
"For message types where the bit is not defined in Table 20, the values shall be FALSE."

Table A.6  PTP flags

Flag Value to be sent Behaviour for the receiving node
alternateMasterFlag See clause 6.9 of this Used
Recommendation
twoStepFlag As per PTP Used
unicastFlag TRUE Used
PTP profile Specific1 FALSE Flag is ignored
PTP profile Specific2 FALSE Flag is ignored
Reserved FALSE Reserved by PTP and flag is ignored
leap61 As per PTP Used
leap59 As per PTP Used
currentUtcOffsetValid As per PTP Used
ptpTimescale TRUE Used
timeTraceable See Table 2 Used
frequencyTraceable See Table 2 Used
Octet 1, Bit 6 Note 1 Note 1
NOTE 1 – An additional flag "synchronizationUncertain" has been defined in Annex E; the use of the
"synchronizationUncertain" flag is optional.

28 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

 Annex B

Options to establish the PTP topology with the Alternate BMCA

(This annex forms an integral part of this Recommendation.)

This PTP telecom profile defines an Alternate BMCA that allows using two main approaches to set
up the topology of the phase/time synchronization network:
1) Automatic topology establishment: when configuring the localPriority attributes defined in
this Recommendation to their default value, the PTP topology is established automatically
by the Alternate BMCA based on the Announce messages exchanged by the PTP clocks. A
synchronization tree with shortest paths to the T-GMs is built after this operation. In this
mode, during failure events and topology reconfiguration, the Alternate BMCA will be run
again and result in a new synchronization tree. This Alternate BMCA operation ensures that
no timing loop will be created without requiring manual intervention or prior analysis of the
network. The convergence time to the new PTP topology depends on the size of the
network, and on the specific configuration of the PTP parameters.
2) Manual network planning: the use of the localPriority attributes defined in this
Recommendation with different values than their default value allows building manually
the synchronization network topology, in a similar way as synchronous digital hierarchy
(SDH) networks are typically operated based on the synchronization status message (SSM).
This option allows a full control on the actions during failure events and topology
reconfiguration, based on the configured local priorities of the system. However, careful
network planning is required prior to the deployment in order to avoid timing loops.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 29

 Annex C

Inclusion of an external phase/time input interface on a PTP clock

(This annex forms an integral part of this Recommendation.)

This annex describes the model for inclusion of a unidirectional, external phase/time input interface
in a T-GM, T-BC-P, or T-TSC-A, so that this external port can participate in the source selection.
The high-level principles are introduced in this annex.
A virtual PTP port and a virtual Erbest is associated to the external phase/time input (e.g., coming
from a PRTC) of the PTP clock, in order to allow this external interface to participate in the PTP
protocol.
The following attributes are associated to the virtual PTP port:
– SF
– clockClass
– clockAccuracy
– offsetScaledLogVariance
– localPriority
– priority1
– priority2
– timeProperties
• currentUtcOffsetValid
• leap61
• leap59
• timeTraceable
• frequencyTraceable
• ptpTimescale
• timeSource
• currentUtcOffset
The signal fail (SF), like localPriority, is a local property of the PTP clock. SF is set to TRUE when
the PTP clock determines the virtual PTP port input (e.g., 1PPS, GNSS) is not useable. When SF is
TRUE the portDS.SF parameter is set to TRUE. The priority1 attribute must be set to 128.
The priority2 attribute default is 128, with configurable range 0-255.
The stepsRemoved attribute must be set to zero in the case a PRTC is connected to the external
phase/time interface.
The grandmasterIdentity assigned to the virtual PTP port is the clockIdentity of the PTP clock itself.
The portNumber assigned to the virtual PTP port is set to a value different from the portNumber
values already assigned to the clock's PTP ports.
The values assigned to the virtual PTP port for other parameters used in the data set comparison
algorithm are for further study.
NOTE 1  The general case of a PTP clock with a phase/time external synchronization input different from
PRTC is for further study.
NOTE 2  If the external phase/time interface contains a time-of-day data channel for transmitting time and
associated information, this information should be considered in deriving the values of the relevant PTP
attributes of the virtual PTP port. The details of the time information to be transmitted are defined in
[ITU-T G.8271].

30 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

 Annex D

TLV for PTP interface rate (optional)

(This annex forms an integral part of this Recommendation.)

This annex is optional but, if implemented, it is necessary for the equipment to conform to
requirements contained herein. When a PTP port in MASTER state that is providing timing service
has a different interface rate than a PTP port in SLAVE state receiving the timing service, delay
asymmetry may occur as described in [ITU-T G.8271] Appendix V 'Delay asymmetry resulting
from interface rate change in PTP-unaware network elements'. If the slave clock is aware of both its
own PTP port interface rate, as well as the master clock PTP port interface rate, then the slave clock
may compensate for such delay asymmetry. The following TLV may be appended to a signalling
message that contains GRANT_UNICAST_TRANSMISSION TLV so that the master clock may
communicate its PTP port interface rate to the slave clock.

Table D.1 – INTERFACE_RATE TLV

Bits Octets TLV
offset
7 6 5 4 3 2 1 0
tlvType 2 0
lengthField 2 2
organizationId 3 4
organizationSubType 3 7
interfaceBitPeriod 8 10
numberBitsBeforeTimestamp 2 18
numberBitsAfterTimestamp 2 20

tlvType (Enum16)
The value of tlvType shall be the ORGANIZATION_EXTENSION value (0x003)
lengthField (Uinteger16)
The value of lengthField shall be 18 bytes.
organizationId (Octet [3])
The value of organizationId shall be the OUI value assigned by ITU-T = 0x0019A7.
organizationSubType (Enum24)
The value of organizationSubType for the INTERFACE_RATE TLV shall be 0x000002.
interfaceBitPeriod (Uinteger64)
The period of 1-bit of the transmitting PTP timestamp interface, excluding line encoding. The value
is encoded as an unsigned integer in units of attoseconds (10–18 s) to accommodate interface bit
periods less than 1 ns.
numberBitsBeforeTimestamp (Uinteger16)
The length of the packet prior to the timestamp point, in bits.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 31

numberBitsAfterTimestamp (Uinteger16)
The length of the packet after the timestamp point, in bits.
By way of example, the following values may be used for 1 GbE interface with Annex D
encapsulation.
– tlvType = 0x003
– lengthField = 18
– organizationId = 0x0019A7.
– organizationSubType = 0x000002
– interfaceBitPeriod = 0x0000,0000, 3B9A, CA00
– numberBitsBeforeTimestamp = (8 bytes pre-amble x 8 bits/byte) = 64
– numberBitsAfterTimestamp = ((86 bytes payload + 4 bytes FCS) x 8 bits/byte) = 720
NOTE 1 – The supported interfaces (and interface speed) for an equipment clock are listed in the relevant
equipment clock specification, such as ITU-T G.8273.4, and not in this profile.
NOTE 2 – The TLV and interfaceBitPeriod format is applicable to single-lane and mutli-lane interfaces.
Table D.2 shows information about various interface speeds and the appropriate interfaceBitPeriod
value.

Table D.2 – Informational interface speeds and type mappings

Interface Speed ns per bit Atto-sec per bit 64-bit atto-sec
Representation
1 1,000,000,000.000 1018 0x0DE0,B6B3,A764,0000
10 M 100.000 100,000,000,000 0x0000,0017,4876,E800
100 M 10.000 10,000,000,000 0x0000,0002,540B,E400
1G 1.000 1,000,000,000 0x0000,0000,3B9A,CA00
10 G 0.100 100,000,000 0x0000,0000,05F5,E100
25G 0.040 40,000,000 0x0000,0000,0262,5A00
40G 0.025 25,000,000 0x0000,0000,017D,7840
100G 0.010 10,000,000 0x0000,0000,0098,9680
1T 0.001 1,000,000 0x0000,0000,000F,4240

32 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

 Annex E

Synchronization uncertain indication (optional)

(This annex forms an integral part of this Recommendation.)

This annex is optional but, if implemented, it is necessary for the equipment to conform to
requirements contained herein. When a PTP clock selects a new parent as a synchronization time
source, the PTP port associated with that new parent is placed in the UNCALIBRATED state. This
PTP port state indicates that the PTP clock is in the process of synchronizing to the time source.
The duration and functionality of this state is implementation specific. During this period, the PTP
clock may have large or fast changes in frequency and phase, and while it is desirable that the
updated parent information be propagated downstream to allow the topology to settle, it may not be
desirable for the downstream PTP clocks to use the timing information. Therefore, communicating
to downstream PTP clocks about the UNCALIBRATED state would be beneficial.
The local synchronizationUncertain boolean, used with Announce messages transmitted from an
egress port is FALSE except under the following conditions for which it shall be TRUE:
– The synchronizationUncertain flag of the Announce message received from the parent
clock is TRUE, or
– The ingress port is in the UNCALIBRATED state, or
– Implementation specific criteria.
When the synchronizationUncertain condition is TRUE then in the transmitted Announce message
the flagField – octet 1, bit 6 is set to 1. Otherwise, when the synchronizationUncertain condition is
FALSE, the bit is set to 0.

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 33

 Appendix I

Considerations on the use of priority2

(This appendix does not form an integral part of this Recommendation.)

The PTP attribute priority2 is configurable in this profile. In some special circumstances, the use of
the priority2 attribute can simplify the network management. This appendix describes two use
cases; other possible cases are for further study.
Case 1
Operators can configure the PTP attribute priority2 to make all of the T-BC-Ps either traceable to
one T-GM, or traceable to two different T-GMs at the same time.

Figure I.1  Use of priority2 with two T-GMs in the network

For example, in Figure I.1, if all other PTP attributes of the two T-GMs are the same, and the two
T-GMs are configured with the same priority2 value, each T-BC-P will select the T-GM with the
shortest path. If the two T-GMs are configured with different priority2 values, all of the T-BC-Ps
will synchronize to the T-GM with the smallest priority2 value.
Case 2
Operators can configure the PTP attribute priority2 to prevent the T-BC-Ps of an upstream network
from synchronizing with the T-BC-Ps of a downstream network when the T-GM is in failure.

Figure I.2  Use of priority2 with T-BCs of different network layers

For example, in Figure I.2, if all other PTP attributes of all of the T-BC-Ps are the same, and the
PTP attribute priority2 of all of T-BC-Ps are configured with the same value, then when the T-GM
is in failure, the T-BC-Ps in the upstream network can synchronize with the T-BC-Ps in the
downstream network, depending on the clockIdentity values of all of the T-BC-Ps. If the T-BC-Ps
in the upstream network are configured with a smaller priority2 value than the T-BC-Ps in the
downstream network then, when the T-GM is in failure, the T-BC-Ps in the downstream network
will synchronize to the T-BC-P s in the upstream network.

34 Rec. ITU-T G.8275.2/Y.1369.2 (06/2016)

 Appendix II

Considerations on a T-TSC-A or T-TSC-P connected to an end application

(This appendix does not form an integral part of this Recommendation.)

The default T-TSC-A and T-TSC-P clockClass (248 for BC and 255 for OC) generally implies that
the T-TSC-A or T-TSC-P will lock to the co-located PRTC (in case of APTS) or to an external PTP
reference when available.
The actual synchronization source ultimately used by the end application depends on the applicable
synchronization needs. This process is out of the scope of this recommendation.
As an example, the decision to use the PTP reference that has been selected by the T-TSC-A or
T-TSC-P (e.g., instead of entering holdover), could depend on the actual clockQuality,
frequencyTraceable flag and timeTraceable flag associated to the T-TSC-A or T-TSC-P input.
Additional aspects as related to performance monitoring of the external reference might also be
considered. This is implementation specific.
As an example, when it is required to meet the network timing requirements as per e.g.,
[ITU-T G.8271], it would be necessary that the external reference has clockClass 6, 7 or 135 and
that the timeTraceable flag is TRUE in order to be used by the End Application. When this
condition is not met, the end application may decide to enter holdover (either on the internal
oscillator or driven by synchronous Ethernet).

Rec. ITU-T G.8275.2/Y.1369.2 (06/2016) 35

 SERIES OF ITU-T RECOMMENDATIONS

Series A Organization of the work of ITU-T

Series D General tariff principles

Series E Overall network operation, telephone service, service operation and human factors
Series F Non-telephone telecommunication services

Series G Transmission systems and media, digital systems and networks

Series H Audiovisual and multimedia systems

Series I Integrated services digital network

Series J Cable networks and transmission of television, sound programme and other multimedia signals

Series K Protection against interference

Series L Environment and ICTs, climate change, e-waste, energy efficiency; construction, installation
and protection of cables and other elements of outside plant
Series M Telecommunication management, including TMN and network maintenance
Series N Maintenance: international sound programme and television transmission circuits

Series O Specifications of measuring equipment

Series P Terminals and subjective and objective assessment methods

Series Q Switching and signalling

Series R Telegraph transmission
Series S Telegraph services terminal equipment
Series T Terminals for telematic services
Series U Telegraph switching

Series V Data communication over the telephone network

Series X Data networks, open system communications and security

Series Y Global information infrastructure, Internet protocol aspects and next-generation networks,
Internet of Things and smart cities
Series Z Languages and general software aspects for telecommunication systems

Printed in Switzerland
Geneva, 2016