draft-ietf-tictoc-1588v2-yang-08.txt   draft-ietf-tictoc-1588v2-yang-09.txt 
Internet Working Group Y. Jiang, Ed. Internet Working Group Y. Jiang, Ed.
Huawei Huawei
Internet-Draft X. Liu Internet-Draft X. Liu
Independent Independent
Intended status: Standards Track J. Xu Intended status: Standards Track J. Xu
Huawei Huawei
R. Cummings, Ed. R. Cummings, Ed.
National Instruments National Instruments
Expires: January 2019 July 2, 2018 Expires: January 2019 July 24, 2018
YANG Data Model for IEEE 1588-2008 YANG Data Model for IEEE 1588-2008
draft-ietf-tictoc-1588v2-yang-08 draft-ietf-tictoc-1588v2-yang-09
Abstract Abstract
This document defines a YANG data model for the configuration of This document defines a YANG data model for the configuration of
IEEE 1588-2008 devices and clocks, and also retrieval of the IEEE 1588-2008 devices and clocks, and also retrieval of the
configuration information, data set and running states of IEEE configuration information, data set and running states of IEEE
1588-2008 clocks. 1588-2008 clocks. The YANG module in this document conforms to the
Network Management Datastore Architecture (NMDA).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 44 skipping to change at page 1, line 45
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 2, 2019. This Internet-Draft will expire on January 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 33
1.1. Conventions used in this document ....................... 4 1.1. Conventions used in this document ....................... 4
1.2. Terminology ............................................. 4 1.2. Terminology ............................................. 4
2. IEEE 1588-2008 YANG Model hierarchy ........................ 5 2. IEEE 1588-2008 YANG Model hierarchy ........................ 5
2.1. Interpretations from IEEE 1588 Working Group ............ 8 2.1. Interpretations from IEEE 1588 Working Group ............ 8
2.2. Configuration and state ................................. 8 2.2. Configuration and state ................................. 8
3. IEEE 1588-2008 YANG Module ................................. 9 3. IEEE 1588-2008 YANG Module ................................. 9
4. Security Considerations ................................... 22 4. Security Considerations ................................... 22
5. IANA Considerations ....................................... 23 5. IANA Considerations ....................................... 23
6. References ................................................ 23 6. References ................................................ 23
6.1. Normative References ................................... 23 6.1. Normative References ................................... 23
6.2. Informative References ................................. 23 6.2. Informative References ................................. 24
7. Acknowledgments ........................................... 24 7. Acknowledgments ........................................... 25
Appendix A Transferring YANG Work to IEEE 1588 WG ............. 25 Appendix A Transferring YANG Work to IEEE 1588 WG ............. 26
A.1. Assumptions for the Transfer ........................... 26 A.1. Assumptions for the Transfer ........................... 27
A.2. Intellectual Property Considerations ................... 26 A.2. Intellectual Property Considerations ................... 27
A.3. Namespace and Module Name .............................. 27 A.3. Namespace and Module Name .............................. 28
A.4. IEEE 1588 YANG Modules in ASCII Format ................. 28 A.4. IEEE 1588 YANG Modules in ASCII Format ................. 29
1. Introduction 1. Introduction
As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
supported in the carrier networks, industrial networks, automotive supported in the carrier networks, industrial networks, automotive
networks, and many other applications. It can provide high networks, and many other applications. It can provide high
precision time synchronization as fine as nano-seconds. The precision time synchronization as fine as nano-seconds. The
protocol depends on a Precision Time Protocol (PTP) engine to protocol depends on a Precision Time Protocol (PTP) engine to
decide its own state automatically, and a PTP transportation layer decide its own state automatically, and a PTP transportation layer
to carry the PTP timing and various quality messages. The to carry the PTP timing and various quality messages. The
skipping to change at page 3, line 19 skipping to change at page 3, line 24
Network Management Protocol (SNMP), furthermore, configuration of Network Management Protocol (SNMP), furthermore, configuration of
PTP data sets is not considered in [RFC8173]. PTP data sets is not considered in [RFC8173].
Some service providers and applications require that the management Some service providers and applications require that the management
of the IEEE 1588-2008 synchronization network be flexible and more of the IEEE 1588-2008 synchronization network be flexible and more
Internet-based (typically overlaid on their transport networks). Internet-based (typically overlaid on their transport networks).
Software Defined Network (SDN) is another driving factor, which Software Defined Network (SDN) is another driving factor, which
demands an improved configuration capability of synchronization demands an improved configuration capability of synchronization
networks. networks.
YANG [RFC6020] is a data modeling language used to model YANG [RFC7950] is a data modeling language used to model
configuration and state data manipulated by network management configuration and state data manipulated by network management
protocols like the Network Configuration Protocol (NETCONF) protocols like the Network Configuration Protocol (NETCONF)
[RFC6241]. A small set of built-in data types are defined in [RFC6241]. A small set of built-in data types are defined in
[RFC6020], and a collection of common data types are further [RFC7950], and a collection of common data types are further
defined in [RFC6991]. Advantages of YANG include Internet based defined in [RFC6991]. Advantages of YANG include Internet based
configuration capability, validation, rollback and so on. All of configuration capability, validation, rollback and so on. All of
these characteristics make it attractive to become another these characteristics make it attractive to become another
candidate modeling language for IEEE 1588-2008. candidate modeling language for IEEE 1588-2008.
This document defines a YANG [RFC6020] data model for the This document defines a YANG data model for the configuration of
configuration of IEEE 1588-2008 devices and clocks, and retrieval IEEE 1588-2008 devices and clocks, and retrieval of the state data
of the state data of IEEE 1588-2008 clocks. The data model is based of IEEE 1588-2008 clocks. The data model is based on the PTP data
on the PTP data sets as specified in [IEEE1588]. The technology sets as specified in [IEEE1588]. The technology specific IEEE 1588-
specific IEEE 1588-2008 information, e.g., those specifically 2008 information, e.g., those specifically implemented by a bridge,
implemented by a bridge, a router or a telecom profile, is out of a router or a telecom profile, is out of scope of this document.
scope of this document.
The YANG module in this document conforms to the Network Management
Datastore Architecture (NMDA) [RFC8342].
When used in practice, network products in support of When used in practice, network products in support of
synchronization typically conform to one or more IEEE 1588-2008 synchronization typically conform to one or more IEEE 1588-2008
profiles. Each profile specifies how IEEE 1588-2008 is used in a profiles. Each profile specifies how IEEE 1588-2008 is used in a
given industry (e.g. telecom, automotive) and application. A given industry (e.g. telecom, automotive) and application. A
profile can require features that are optional in IEEE 1588-2008, profile can require features that are optional in IEEE 1588-2008,
and it can specify new features that use IEEE 1588-2008 as a and it can specify new features that use IEEE 1588-2008 as a
foundation. foundation.
It is expected that the IEEE 1588-2008 YANG module be used as It is expected that the IEEE 1588-2008 YANG module be used as
skipping to change at page 4, line 25 skipping to change at page 4, line 32
as its foundation. Then the profile's YANG module SHOULD use YANG as its foundation. Then the profile's YANG module SHOULD use YANG
"augment" to add any profile-specific enhancements. "augment" to add any profile-specific enhancements.
o A product that conforms to a profile standard can also create o A product that conforms to a profile standard can also create
its own YANG module. The product's YANG module SHOULD "import" the its own YANG module. The product's YANG module SHOULD "import" the
profile's module, and then use YANG "augment" to add any product- profile's module, and then use YANG "augment" to add any product-
specific enhancements. specific enhancements.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
this document are to be interpreted as described in [RFC2119]. "MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.
1.2. Terminology 1.2. Terminology
Most terminologies used in this document are extracted from Most terminologies used in this document are extracted from
[IEEE1588]. [IEEE1588].
BC Boundary Clock, see Section 3.1.3 of [IEEE1588] BC Boundary Clock, see Section 3.1.3 of [IEEE1588]
DS Data Set DS Data Set
E2E End-to-End E2E End-to-End
EUI Extended Unique Identifier EUI Extended Unique Identifier
GPS Global Positioning System GPS Global Positioning System
IANA Internet Assigned Numbers Authority IANA Internet Assigned Numbers Authority
IP Internet Protocol IP Internet Protocol
NIST National Institute of Standards and Technology NIST National Institute of Standards and Technology
NTP Network Time Protocol NTP Network Time Protocol
OC Ordinary Clock, see Section 3.1.22 of [IEEE1588] OC Ordinary Clock, see Section 3.1.22 of [IEEE1588]
P2P Peer-to-Peer P2P Peer-to-Peer
PTP Precision Time Protocol PTP Precision Time Protocol
TAI International Atomic Time TAI International Atomic Time
TC Transparent Clock, see Section 3.1.46 of [IEEE1588] TC Transparent Clock, see Section 3.1.46 of [IEEE1588]
skipping to change at page 5, line 17 skipping to change at page 5, line 25
PTP Precision Time Protocol PTP Precision Time Protocol
TAI International Atomic Time TAI International Atomic Time
TC Transparent Clock, see Section 3.1.46 of [IEEE1588] TC Transparent Clock, see Section 3.1.46 of [IEEE1588]
UTC Coordinated Universal Time UTC Coordinated Universal Time
PTP data set PTP data set
Structured attributes of clocks (an OC, BC or TC) used for Structured attributes of clocks (an OC, BC or TC) used for
PTP protocol decisions and for providing values for PTP PTP protocol decisions and for providing values for PTP
message fields, see Section 8 of [IEEE1588]. message fields, see Section 8 of [IEEE1588].
PTP instance PTP instance
A PTP implementation in the device (i.e., an OC or BC) A PTP implementation in the device (i.e., an OC or BC)
represented by a specific PTP data set. represented by a specific PTP data set.
2. IEEE 1588-2008 YANG Model hierarchy 2. IEEE 1588-2008 YANG Model hierarchy
This section describes the hierarchy of an IEEE 1588-2008 YANG This section describes the hierarchy of an IEEE 1588-2008 YANG
module. Query and configuration of device wide or port specific module. Query and configuration of device wide or port specific
configuration information and clock data set are described for this configuration information and clock data set are described for this
version. version.
Query and configuration of clock information include: Query and configuration of clock information include:
skipping to change at page 6, line 5 skipping to change at page 6, line 13
default-ds. default-ds.
- Port-specific data set attributes, including: port-ds and - Port-specific data set attributes, including: port-ds and
transparent-clock-port-ds. transparent-clock-port-ds.
The readers are assumed to be familiar with IEEE 1588-2008. As all The readers are assumed to be familiar with IEEE 1588-2008. As all
PTP terminologies and PTP data set attributes are described in PTP terminologies and PTP data set attributes are described in
details in IEEE 1588-2008 [IEEE1588], this document only outlines details in IEEE 1588-2008 [IEEE1588], this document only outlines
each of them in the YANG module. each of them in the YANG module.
A simplified graphical representation of the data model is A simplified YANG tree diagram [RFC8340] representing the data
typically used by YANG modules as described in [RFC8040]. This model is typically used by YANG modules. This document uses the
document uses the same representation and the meaning of the same tree diagram syntax as described in [RFC8340].
symbols in these diagrams is as follows:
o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration
data (read-write) and "ro" state data (read-only). For IEEE 1588-
2008, most data nodes are marked "rw" (see 2.2).
o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list or leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are
also marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
o Arrow ("->") stands for a reference to a particular leaf
instance in the tree.
module: ietf-ptp module: ietf-ptp
+--rw ptp +--rw ptp
+--rw instance-list* [instance-number] +--rw instance-list* [instance-number]
| +--rw instance-number uint32 | +--rw instance-number uint32
| +--rw default-ds | +--rw default-ds
| | +--rw two-step-flag? boolean | | +--rw two-step-flag? boolean
| | +--ro clock-identity? clock-identity-type | | +--ro clock-identity? clock-identity-type
| | +--rw number-ports? uint16 | | +--rw number-ports? uint16
| | +--rw clock-quality | | +--rw clock-quality
skipping to change at page 7, line 4 skipping to change at page 6, line 41
| | +--rw domain-number? uint8 | | +--rw domain-number? uint8
| | +--rw slave-only? boolean | | +--rw slave-only? boolean
| +--rw current-ds | +--rw current-ds
| | +--rw steps-removed? uint16 | | +--rw steps-removed? uint16
| | +--rw offset-from-master? time-interval-type | | +--rw offset-from-master? time-interval-type
| | +--rw mean-path-delay? time-interval-type | | +--rw mean-path-delay? time-interval-type
| +--rw parent-ds | +--rw parent-ds
| | +--rw parent-port-identity | | +--rw parent-port-identity
| | | +--rw clock-identity? clock-identity-type | | | +--rw clock-identity? clock-identity-type
| | | +--rw port-number? uint16 | | | +--rw port-number? uint16
| | +--rw parent-stats? boolean | | +--rw parent-stats? boolean
| | +--rw observed-parent-offset-scaled-log-variance? uint16 | | +--rw observed-parent-offset-scaled-log-variance? uint16
| | +--rw observed-parent-clock-phase-change-rate? int32 | | +--rw observed-parent-clock-phase-change-rate? int32
| | +--rw grandmaster-identity? binary | | +--rw grandmaster-identity? clock-identity-type
| | +--rw grandmaster-clock-quality | | +--rw grandmaster-clock-quality
| | | +--rw clock-class? uint8 | | | +--rw clock-class? uint8
| | | +--rw clock-accuracy? uint8 | | | +--rw clock-accuracy? uint8
| | | +--rw offset-scaled-log-variance? uint16 | | | +--rw offset-scaled-log-variance? uint16
| | +--rw grandmaster-priority1? uint8 | | +--rw grandmaster-priority1? uint8
| | +--rw grandmaster-priority2? uint8 | | +--rw grandmaster-priority2? uint8
| +--rw time-properties-ds | +--rw time-properties-ds
| | +--rw current-utc-offset-valid? boolean | | +--rw current-utc-offset-valid? boolean
| | +--rw current-utc-offset? int16 | | +--rw current-utc-offset? int16
| | +--rw leap59? boolean | | +--rw leap59? boolean
skipping to change at page 8, line 14 skipping to change at page 8, line 14
2.1. Interpretations from IEEE 1588 Working Group 2.1. Interpretations from IEEE 1588 Working Group
The preceding model and the associated YANG module have some subtle The preceding model and the associated YANG module have some subtle
differences from the data set specifications of IEEE Std 1588-2008. differences from the data set specifications of IEEE Std 1588-2008.
These differences are based on interpretation from the IEEE 1588 These differences are based on interpretation from the IEEE 1588
Working Group, and are intended to provide compatibility with Working Group, and are intended to provide compatibility with
future revisions of the IEEE 1588 standard. future revisions of the IEEE 1588 standard.
In IEEE Std 1588-2008, a physical product can implement multiple In IEEE Std 1588-2008, a physical product can implement multiple
PTP clocks (i.e. ordinary, boundary, or transparent clock). As PTP clocks (i.e., ordinary, boundary, or transparent clock). As
specified in 1588-2008 subclause 7.1, each of the multiple clocks specified in 1588-2008 subclause 7.1, each of the multiple clocks
operates in an independent domain. However, the organization of operates in an independent domain. However, the organization of
multiple PTP domains was not clear in the data sets of IEEE Std multiple PTP domains was not clear in the data sets of IEEE Std
1588-2008. This document introduces the concept of PTP instance as 1588-2008. This document introduces the concept of PTP instance as
described in the new revision of IEEE 1588. The instance concept is described in the new revision of IEEE 1588. The instance concept is
used exclusively to allow for optional support of multiple domains. used exclusively to allow for optional support of multiple domains.
The instance number has no usage within PTP messages. The instance number has no usage within PTP messages.
Based on statements in IEEE 1588-2008 subclauses 8.3.1 and 10.1, Based on statements in IEEE 1588-2008 subclauses 8.3.1 and 10.1,
most transparent clock products have interpreted the transparent most transparent clock products have interpreted the transparent
skipping to change at page 9, line 11 skipping to change at page 9, line 11
case, an implementation MAY choose to return a warning upon writing case, an implementation MAY choose to return a warning upon writing
to a read-only member, or use the deviation mechanism to develop a to a read-only member, or use the deviation mechanism to develop a
new deviation model as described in Section 7.20.3 of [RFC7950]. new deviation model as described in Section 7.20.3 of [RFC7950].
3. IEEE 1588-2008 YANG Module 3. IEEE 1588-2008 YANG Module
This module imports typedef "interface-ref" from [RFC8343]. Most This module imports typedef "interface-ref" from [RFC8343]. Most
attributes are based on the information model defined in [IEEE1588], attributes are based on the information model defined in [IEEE1588],
but their names are adapted to the YANG style of naming. but their names are adapted to the YANG style of naming.
<CODE BEGINS> file "ietf-ptp@2018-07-02.yang" <CODE BEGINS> file "ietf-ptp@2018-07-24.yang"
//Note to RFC Editor: update the date to date of publication
module ietf-ptp { module ietf-ptp {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ptp"; namespace "urn:ietf:params:xml:ns:yang:ietf-ptp";
prefix "ptp"; prefix "ptp";
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
reference
"RFC8343: A YANG Data Model for Interface Management";
} }
organization "IETF TICTOC Working Group"; organization "IETF TICTOC Working Group";
contact contact
"WG Web: http://tools.ietf.org/wg/tictoc/ "WG Web: http://tools.ietf.org/wg/tictoc/
WG List: <mailto:tictoc@ietf.org> WG List: <mailto:tictoc@ietf.org>
WG Chair: Karen O'Donoghue
<mailto:odonoghue@isoc.org>
WG Chair: Yaakov Stein
<mailto: Yaakov_s@rad.com>
Editor: Yuanlong Jiang Editor: Yuanlong Jiang
<mailto:jiangyuanlong@huawei.com> <mailto:jiangyuanlong@huawei.com>
Editor: Rodney Cummings Editor: Rodney Cummings
<mailto:rodney.cummings@ni.com>"; <mailto:rodney.cummings@ni.com>";
description description
"This YANG module defines a data model for the configuration "This YANG module defines a data model for the configuration
of IEEE 1588-2008 clocks, and also for retrieval of the state of IEEE 1588-2008 clocks, and also for retrieval of the state
data of IEEE 1588-2008 clocks."; data of IEEE 1588-2008 clocks.";
revision "2018-07-02" { revision "2018-07-24" {
description "Version 8.0"; //Note to RFC Editor: update the date to date of publication
reference "draft-ietf-tictoc-1588v2-yang"; description "Initial version";
reference "RFC XXXX: YANG Data Model for IEEE 1588-2008";
//Note to RFC Editor: update RFC XXXX to the actual RFC number
} }
typedef delay-mechanism-enumeration { typedef delay-mechanism-enumeration {
type enumeration { type enumeration {
enum e2e { enum e2e {
value 1; value 1;
description description
"The port uses the delay request-response mechanism."; "The port uses the delay request-response mechanism.";
} }
enum p2p { enum p2p {
skipping to change at page 12, line 47 skipping to change at page 13, line 4
} }
container ptp { container ptp {
description description
"The PTP struct containing all attributes of PTP data set, "The PTP struct containing all attributes of PTP data set,
other optional PTP attributes can be augmented as well."; other optional PTP attributes can be augmented as well.";
list instance-list { list instance-list {
key "instance-number"; key "instance-number";
description description
"List of one or more PTP data sets in the device (see IEEE "List of one or more PTP data sets in the device (see IEEE
Std 1588-2008 subclause 6.3). Std 1588-2008 subclause 6.3).
Each PTP data set represents a distinct instance of Each PTP data set represents a distinct instance of
PTP implementation in the device (i.e. distinct PTP implementation in the device (i.e., distinct
Ordinary Clock or Boundary Clock)."; Ordinary Clock or Boundary Clock).";
leaf instance-number { leaf instance-number {
type uint32; type uint32;
description description
"The instance number of the current PTP instance. "The instance number of the current PTP instance.
This instance number is used for management purposes This instance number is used for management purposes
only. This instance number does not represent the PTP only. This instance number does not represent the PTP
domain number, and is not used in PTP messages."; domain number, and is not used in PTP messages.";
} }
container default-ds { container default-ds {
description description
"The default data set of the clock (see IEEE Std "The default data set of the clock (see IEEE Std
1588-2008 subclause 8.2.1)."; 1588-2008 subclause 8.2.1).";
leaf two-step-flag { leaf two-step-flag {
type boolean; type boolean;
description description
"When set, the clock is a two-step clock; otherwise, "When set to true, the clock is a two-step clock;
the clock is a one-step clock."; otherwise,the clock is a one-step clock.";
} }
leaf clock-identity { leaf clock-identity {
type clock-identity-type; type clock-identity-type;
config false; config false;
description description
"The clockIdentity of the local clock"; "The clockIdentity of the local clock";
} }
leaf number-ports { leaf number-ports {
skipping to change at page 14, line 26 skipping to change at page 14, line 26
leaf domain-number { leaf domain-number {
type uint8; type uint8;
description description
"The domain number of the current syntonization "The domain number of the current syntonization
domain."; domain.";
} }
leaf slave-only { leaf slave-only {
type boolean; type boolean;
description description
"When set, the clock is a slave-only clock."; "When set to true, the clock is a slave-only clock.";
} }
} }
container current-ds { container current-ds {
description description
"The current data set of the clock (see IEEE Std "The current data set of the clock (see IEEE Std
1588-2008 subclause 8.2.2)."; 1588-2008 subclause 8.2.2).";
leaf steps-removed { leaf steps-removed {
skipping to change at page 15, line 43 skipping to change at page 15, line 43
type uint16; type uint16;
description description
"Port number"; "Port number";
} }
} }
leaf parent-stats { leaf parent-stats {
type boolean; type boolean;
default false; default false;
description description
"When set, the values of "When set to true, the values of
observedParentOffsetScaledLogVariance and observedParentOffsetScaledLogVariance and
observedParentClockPhaseChangeRate of parentDS observedParentClockPhaseChangeRate of parentDS
have been measured and are valid."; have been measured and are valid.";
} }
leaf observed-parent-offset-scaled-log-variance { leaf observed-parent-offset-scaled-log-variance {
type uint16; type uint16;
default 65535; default 65535;
description description
"An estimate of the parent clock's PTP variance "An estimate of the parent clock's PTP variance
skipping to change at page 16, line 18 skipping to change at page 16, line 19
} }
leaf observed-parent-clock-phase-change-rate { leaf observed-parent-clock-phase-change-rate {
type int32; type int32;
description description
"An estimate of the parent clock's phase change rate "An estimate of the parent clock's phase change rate
as observed by the slave clock."; as observed by the slave clock.";
} }
leaf grandmaster-identity { leaf grandmaster-identity {
type binary { type clock-identity-type;
length "8";
}
description description
"The clockIdentity attribute of the grandmaster clock."; "The clockIdentity attribute of the grandmaster clock.";
} }
container grandmaster-clock-quality { container grandmaster-clock-quality {
description description
"The clockQuality of the grandmaster clock."; "The clockQuality of the grandmaster clock.";
uses clock-quality-grouping; uses clock-quality-grouping;
} }
skipping to change at page 17, line 6 skipping to change at page 17, line 5
} }
container time-properties-ds { container time-properties-ds {
description description
"The timeProperties data set of the clock (see "The timeProperties data set of the clock (see
IEEE Std 1588-2008 subclause 8.2.4)."; IEEE Std 1588-2008 subclause 8.2.4).";
leaf current-utc-offset-valid { leaf current-utc-offset-valid {
type boolean; type boolean;
description description
"When set, the current UTC offset is valid."; "When set to true, the current UTC offset is valid.";
} }
leaf current-utc-offset { leaf current-utc-offset {
when "../current-utc-offset-valid='true'";
type int16; type int16;
description description
"The offset between TAI and UTC when the epoch of the "The offset between TAI and UTC when the epoch of the
PTP system is the PTP epoch, i.e., when ptp-timescale PTP system is the PTP epoch in units of seconds, i.e.,
is TRUE; otherwise, the value has no meaning."; when ptp-timescale is TRUE; otherwise, the value has
no meaning.";
} }
leaf leap59 { leaf leap59 {
type boolean; type boolean;
description description
"When set, the last minute of the current UTC day "When set to true, the last minute of the current UTC
contains 59 seconds."; day contains 59 seconds.";
} }
leaf leap61 { leaf leap61 {
type boolean; type boolean;
description description
"When set, the last minute of the current UTC day "When set to true, the last minute of the current UTC
contains 61 seconds."; day contains 61 seconds.";
} }
leaf time-traceable { leaf time-traceable {
type boolean; type boolean;
description description
"When set, the timescale and the currentUtcOffset are "When set to true, the timescale and the
traceable to a primary reference."; currentUtcOffset are traceable to a primary
reference.";
} }
leaf frequency-traceable { leaf frequency-traceable {
type boolean; type boolean;
description description
"When set, the frequency determining the timescale "When set to true, the frequency determining the
is traceable to a primary reference."; timescale is traceable to a primary reference.";
} }
leaf ptp-timescale { leaf ptp-timescale {
type boolean; type boolean;
description description
"When set, the clock timescale of the grandmaster "When set to true, the clock timescale of the
clock is PTP; otherwise, the timescale is ARB grandmaster clock is PTP; otherwise, the timescale is
ARB
(arbitrary)."; (arbitrary).";
} }
leaf time-source { leaf time-source {
type uint8; type uint8;
description description
"The source of time used by the grandmaster clock."; "The source of time used by the grandmaster clock.";
} }
} }
list port-ds-list { list port-ds-list {
skipping to change at page 18, line 20 skipping to change at page 18, line 23
"The source of time used by the grandmaster clock."; "The source of time used by the grandmaster clock.";
} }
} }
list port-ds-list { list port-ds-list {
key "port-number"; key "port-number";
description description
"List of port data sets of the clock (see IEEE Std "List of port data sets of the clock (see IEEE Std
1588-2008 subclause 8.2.5)."; 1588-2008 subclause 8.2.5).";
leaf port-number{ leaf port-number {
type uint16; type uint16;
description description
"Port number. "Port number.
The data sets (i.e. information model) of IEEE Std The data sets (i.e., information model) of IEEE Std
1588-2008 specify a member portDS.portIdentity, which 1588-2008 specify a member portDS.portIdentity, which
uses a typed struct with members clockIdentity and uses a typed struct with members clockIdentity and
portNumber. portNumber.
In this YANG data model, portIdentity is not modeled In this YANG data model, portIdentity is not modeled
in the port-ds-list, however, its members are provided in the port-ds-list, however, its members are provided
as follows: as follows:
portIdentity.portNumber is provided as this port- portIdentity.portNumber is provided as this port-
number leaf in port-ds-list; and number leaf in port-ds-list; and
portIdentity.clockIdentity is provided as the clock- portIdentity.clockIdentity is provided as the clock-
identity leaf in default-ds of the instance identity leaf in default-ds of the instance
(i.e. ../../default-ds/clock-identity)."; (i.e., ../../default-ds/clock-identity).";
} }
leaf port-state { leaf port-state {
type port-state-enumeration; type port-state-enumeration;
default "initializing"; default "initializing";
description description
"Current state associated with the port."; "Current state associated with the port.";
} }
leaf underlying-interface { leaf underlying-interface {
skipping to change at page 21, line 4 skipping to change at page 21, line 8
description description
"The number of PTP ports on the transparent clock."; "The number of PTP ports on the transparent clock.";
} }
leaf delay-mechanism { leaf delay-mechanism {
type delay-mechanism-enumeration; type delay-mechanism-enumeration;
description description
"The propagation delay measuring option "The propagation delay measuring option
used by the transparent clock."; used by the transparent clock.";
} }
leaf primary-domain { leaf primary-domain {
type uint8; type uint8;
default 0; default 0;
description description
"The domainNumber of the primary syntonization domain."; "The domainNumber of the primary syntonization domain (see
IEEE Std 1588-2008 subclause 10.1).";
} }
} }
list transparent-clock-port-ds-list { list transparent-clock-port-ds-list {
key "port-number"; key "port-number";
description description
"List of transparentClockPort data sets of the transparent "List of transparentClockPort data sets of the transparent
clock (see IEEE Std 1588-2008 subclause 8.3.3)."; clock (see IEEE Std 1588-2008 subclause 8.3.3).";
leaf port-number { leaf port-number {
type uint16; type uint16;
description description
"Port number. "Port number.
skipping to change at page 21, line 21 skipping to change at page 21, line 28
list transparent-clock-port-ds-list { list transparent-clock-port-ds-list {
key "port-number"; key "port-number";
description description
"List of transparentClockPort data sets of the transparent "List of transparentClockPort data sets of the transparent
clock (see IEEE Std 1588-2008 subclause 8.3.3)."; clock (see IEEE Std 1588-2008 subclause 8.3.3).";
leaf port-number { leaf port-number {
type uint16; type uint16;
description description
"Port number. "Port number.
The data sets (i.e. information model) of IEEE Std The data sets (i.e., information model) of IEEE Std
1588-2008 specify a member 1588-2008 specify a member
transparentClockPortDS.portIdentity, which uses a typed transparentClockPortDS.portIdentity, which uses a typed
struct with members clockIdentity and portNumber. struct with members clockIdentity and portNumber.
In this YANG data model, portIdentity is not modeled in In this YANG data model, portIdentity is not modeled in
the transparent-clock-port-ds-list, however, its the transparent-clock-port-ds-list, however, its
members are provided as follows: members are provided as follows:
portIdentity.portNumber is provided as this leaf member portIdentity.portNumber is provided as this leaf member
in transparent-clock-port-ds-list; and in transparent-clock-port-ds-list; and
portIdentity.clockIdentity is provided as the clock- portIdentity.clockIdentity is provided as the clock-
skipping to change at page 22, line 5 skipping to change at page 22, line 11
description description
"The logarithm to the base 2 of the "The logarithm to the base 2 of the
minPdelayReqInterval (minimum permitted mean time minPdelayReqInterval (minimum permitted mean time
interval between successive Pdelay_Req messages)."; interval between successive Pdelay_Req messages).";
} }
leaf faulty-flag { leaf faulty-flag {
type boolean; type boolean;
default false; default false;
description description
"When set, the port is faulty."; "When set to true, the port is faulty.";
} }
leaf peer-mean-path-delay { leaf peer-mean-path-delay {
type time-interval-type; type time-interval-type;
default 0; default 0;
description description
"An estimate of the current one-way propagation delay "An estimate of the current one-way propagation delay
on the link when the delayMechanism is P2P; otherwise, on the link when the delayMechanism is P2P; otherwise,
it is zero."; it is zero.";
} }
skipping to change at page 22, line 33 skipping to change at page 22, line 39
4. Security Considerations 4. Security Considerations
YANG modules are designed to be accessed via the NETCONF protocol YANG modules are designed to be accessed via the NETCONF protocol
[RFC6241], thus security considerations in [RFC6241] apply here. [RFC6241], thus security considerations in [RFC6241] apply here.
Security measures such as using the NETCONF over SSH [RFC6242] and Security measures such as using the NETCONF over SSH [RFC6242] and
restricting its use with access control [RFC8341] can further restricting its use with access control [RFC8341] can further
improve its security, avoid injection attacks and misuse of the improve its security, avoid injection attacks and misuse of the
protocol. Furthermore, general security considerations of time protocol. Furthermore, general security considerations of time
protocols are discussed in [RFC7384]. protocols are discussed in [RFC7384].
Most data nodes defined in this YANG module are writable, and an All subtrees and most data nodes defined in this YANG module are
inappropriate use of them may adversely impact a synchronization writable:
network. For example, loss of synchronization on a clock, accuracy
degradation on a set of clocks, or even break down of a whole /ptp/instance-list specifies an instance (i.e., PTP data sets) for
synchronization network. an OC or BC.
/ptp/transparent-clock-default-ds specifies a default data set for
a TC.
/ptp/transparent-clock-port-ds-list specifies a list of port data
sets for a TC.
An inappropriate use of them may adversely impact a PTP
synchronization network. For example, loss of synchronization on a
clock, accuracy degradation on a set of clocks, or even break down
of a whole synchronization network.
5. IANA Considerations 5. IANA Considerations
This document registers a URI in the IETF XML registry, and the This document registers the following URI in the "IETF XML
following registration is requested to be made: registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-ptp URI: urn:ietf:params:xml:ns:yang:ietf-ptp
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace
This document registers a YANG module in the YANG Module Names: This document registers the following YANG module in the "YANG
name: ietf-ptp namespace: urn:ietf:params:xml:ns:yang:ietf-ptp Module Names" registry [RFC6020]:
Name: ietf-ptp
Namespace: urn:ietf:params:xml:ns:yang:ietf-ptp
Prefix: ptp
Reference: RFC XXXX
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997 Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688,
January 2004,
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF) ", RFC 6020, Network Configuration Protocol (NETCONF) ", RFC 6020,
October 2010 October 2010
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
July 2013 July 2013
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC
7950, August 2016 7950, August 2016
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017
[RFC8341] Bierman, A. and Bjorklund, M., "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 8341, March
2018
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, March 2018
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, March 2018 Management", RFC 8343, March 2018
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock [IEEE1588] IEEE, "IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", IEEE Std 1588-2008, July 2008 Control Systems", IEEE Std 1588-2008, July 2008
6.2. Informative References 6.2. Informative References
[IEEE8021AS] IEEE, "Timing and Synchronizations for Time-Sensitive [IEEE8021AS] IEEE, "Timing and Synchronizations for Time-Sensitive
Applications in Bridged Local Area Networks", IEEE Applications in Bridged Local Area Networks", IEEE
802.1AS-2001, 2011 802.1AS-2001, 2011
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January Information Models and Data Models", RFC 3444, January
2003 2003
[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge
MIB WG to IEEE 802.1 WG", RFC 4663, September 2006 MIB WG to IEEE 802.1 WG", RFC 4663, September 2006
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 8341, March
2018
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, October 2014 Packet Switched Networks", RFC 7384, October 2014
[RFC8040] Bierman, A., Bjorklund, M., and Watsen, K., "RESTCONF [RFC8340] Bjorklund, M., and Berger, L., "YANG Tree Diagrams", RFC
protocol", RFC 8040, January 2017 8340, March 2018
[RFC8173] Shankarkumar, V., Montini, L., Frost, T., and Dowd, G., [RFC8173] Shankarkumar, V., Montini, L., Frost, T., and Dowd, G.,
"Precision Time Protocol Version 2 (PTPv2) Management "Precision Time Protocol Version 2 (PTPv2) Management
Information Base", RFC 8173, June 2017 Information Base", RFC 8173, June 2017
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Joe Gwinn, Mahesh Jethanandani, Tal The authors would like to thank Tom Petch, Mahesh Jethanandani, Tal
Mizrahi, Opher Ronen, Liang Geng, Alex Campbell, Tom Petch, John Mizrahi, Opher Ronen, Liang Geng, Alex Campbell, Joe Gwinn, John
Fletcher and Dave Thaler for their valuable reviews and suggestions, Fletcher, William Zhao and Dave Thaler for their valuable reviews
and thank Benoit Claise and Radek Krejci for their validation of and suggestions, thank Benoit Claise and Radek Krejci for their
the YANG module. validation of the YANG module, and thank Jingfei Lv and Zitao Wang
for their discussions on IEEE 1588 and YANG respectively.
Appendix A Transferring YANG Work to IEEE 1588 WG Appendix A Transferring YANG Work to IEEE 1588 WG
This Appendix is informational. This Appendix is informational.
This appendix describes a future plan to transition responsibility This appendix describes a future plan to transition responsibility
for IEEE 1588 YANG modules from the IETF TICTOC Working Group (WG) for IEEE 1588 YANG modules from the IETF TICTOC Working Group (WG)
to the IEEE 1588 WG, which develops the time synchronization to the IEEE 1588 WG, which develops the time synchronization
technology that the YANG modules are designed to manage. technology that the YANG modules are designed to manage.
This appendix is forward-looking with regard to future This appendix is forward-looking with regard to future
standardization roadmaps in IETF and IEEE. Since those roadmaps standardization roadmaps in IETF and IEEE. Since those roadmaps
cannot be predicted with significant accuracy, this appendix is cannot be predicted with significant accuracy, this appendix is
informational, and it does not specify imperatives or normative informational, and it does not specify imperatives or normative
specifications of any kind. specifications of any kind.
The IEEE 1588-2008 YANG module of this standard represents a The IEEE 1588-2008 YANG module of this standard represents a
cooperation between IETF (for YANG) and IEEE (for 1588). For the cooperation between IETF (for YANG) and IEEE (for 1588). For the
initial standardization of IEEE-1588 YANG modules, the information initial standardization of IEEE-1588 YANG modules, the information
model is relatively clear (i.e. IEEE 1588 data sets), but expertise model is relatively clear (i.e., IEEE 1588 data sets), but
in YANG is required, making IETF an appropriate location for the expertise in YANG is required, making IETF an appropriate location
standards. The TICTOC WG has expertise with IEEE 1588, making it for the standards. The TICTOC WG has expertise with IEEE 1588,
the appropriate location within IETF. making it the appropriate location within IETF.
The IEEE 1588 WG anticipates future changes to its standard on an The IEEE 1588 WG anticipates future changes to its standard on an
ongoing basis. As IEEE 1588 WG members gain practical expertise ongoing basis. As IEEE 1588 WG members gain practical expertise
with YANG, the IEEE 1588 WG will become more appropriate for with YANG, the IEEE 1588 WG will become more appropriate for
standardization of its YANG modules. As the IEEE 1588 standard is standardization of its YANG modules. As the IEEE 1588 standard is
revised and/or amended, IEEE 1588 members can more effectively revised and/or amended, IEEE 1588 members can more effectively
synchronize the revision of this YANG module with future versions synchronize the revision of this YANG module with future versions
of the IEEE 1588 standard. of the IEEE 1588 standard.
This appendix is meant to establish some clear expectations between This appendix is meant to establish some clear expectations between
skipping to change at page 27, line 19 skipping to change at page 28, line 19
When work on the first IEEE YANG module begins in the IEEE 1588 WG, When work on the first IEEE YANG module begins in the IEEE 1588 WG,
that work derives from the last IETF YANG module of this RFC, that work derives from the last IETF YANG module of this RFC,
requiring a transfer of that work from the IETF to the IEEE. In requiring a transfer of that work from the IETF to the IEEE. In
order to avoid having the transfer of that work be dependent on the order to avoid having the transfer of that work be dependent on the
availability of this RFC's authors at the time of its publication, availability of this RFC's authors at the time of its publication,
the IEEE Standards Association department of Risk Management and the IEEE Standards Association department of Risk Management and
Licensing provided the appropriate forms and mechanisms for this Licensing provided the appropriate forms and mechanisms for this
document's authors to assign a non-exclusive license for IEEE to document's authors to assign a non-exclusive license for IEEE to
create derivative works from this document. Those IEEE forms and create derivative works from this document. Those IEEE forms and
mechanisms will be updated as needed during the development of this mechanisms will be updated as needed during the development of this
document (Note: update it to the actual RFC if published) and any document (Note: i.e., RFC XXXX, update it to the actual RFC if
future IETF YANG modules for IEEE 1588. This will help to make the published) and any future IETF YANG modules for IEEE 1588. This
future transfer of work from IETF to IEEE occur as smoothly as will help to make the future transfer of work from IETF to IEEE
possible. occur as smoothly as possible.
As stated in the initial "Status of this Memo", the YANG module in As stated in the initial "Status of this Memo", the YANG module in
this document conforms to the provisions of BCP 78. The IETF will this document conforms to the provisions of BCP 78. The IETF will
retain all the rights granted at the time of publication in the retain all the rights granted at the time of publication in the
published RFCs. published RFCs.
A.3. Namespace and Module Name A.3. Namespace and Module Name
As specified in Section 5 "IANA Considerations", the YANG module in As specified in Section 5 "IANA Considerations", the YANG module in
this document uses IETF as the root of its URN namespace and YANG this document uses IETF as the root of its URN namespace and YANG
skipping to change at page 28, line 13 skipping to change at page 29, line 13
urn:ieee:Std:1588:yang:ieee1588-ptp urn:ieee:Std:1588:yang:ieee1588-ptp
where "ieee1588-ptp" is the registered YANG module name in the IEEE. where "ieee1588-ptp" is the registered YANG module name in the IEEE.
Under the assumptions of section A.1, the first IEEE 1588 YANG Under the assumptions of section A.1, the first IEEE 1588 YANG
module prefix can be the same as the last IETF 1588 YANG module module prefix can be the same as the last IETF 1588 YANG module
prefix (i.e. "ptp"), since the nodes within both YANG modules are prefix (i.e. "ptp"), since the nodes within both YANG modules are
compatible. compatible.
The result of these name changes are that for complete The result of these name changes are that for complete
compatibility, a server (i.e. IEEE 1588 node) can choose to compatibility, a server (i.e., IEEE 1588 node) can choose to
implement a YANG module for the last IETF 1588 YANG module (with implement a YANG module for the last IETF 1588 YANG module (with
IETF root) as well as the first IEEE 1588 YANG module (with IEEE IETF root) as well as the first IEEE 1588 YANG module (with IEEE
root). Since the content of the YANG module transferred are the root). Since the content of the YANG module transferred are the
same, the server implementation is effectively common for both. same, the server implementation is effectively common for both.
From a client's perspective, a client of the last IETF 1588 YANG From a client's perspective, a client of the last IETF 1588 YANG
module (or earlier) looks for the IETF-rooted module name; and a module (or earlier) looks for the IETF-rooted module name; and a
client of the first IEEE 1588 YANG module (or later) looks for the client of the first IEEE 1588 YANG module (or later) looks for the
IEEE-rooted module name. IEEE-rooted module name.
 End of changes. 61 change blocks. 
132 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/