draft-ietf-tictoc-ptp-enterprise-profile-19.txt   draft-ietf-tictoc-ptp-enterprise-profile-20.txt 
TICTOC Working Group D. Arnold TICTOC Working Group D.A. Arnold
Internet-Draft Meinberg-USA Internet-Draft Meinberg-USA
Intended status: Standards Track H. Gerstung Intended status: Standards Track H.G. Gerstung
Expires: December 18, 2021 Meinberg Expires: 25 February 2022 Meinberg
June 16, 2021 24 August 2021
Enterprise Profile for the Precision Time Protocol With Mixed Multicast Enterprise Profile for the Precision Time Protocol With Mixed Multicast
and Unicast Messages and Unicast Messages
draft-ietf-tictoc-ptp-enterprise-profile-19 draft-ietf-tictoc-ptp-enterprise-profile-20
Abstract Abstract
This document describes a profile for the use of the Precision Time This document describes a profile for the use of the Precision Time
Protocol in an IPV4 or IPv6 Enterprise information system Protocol in an IPV4 or IPv6 Enterprise information system
environment. The profile uses the End to End Delay Measurement environment. The profile uses the End to End Delay Measurement
Mechanism, allows both multicast and unicast Delay Request and Delay Mechanism, allows both multicast and unicast Delay Request and Delay
Response Messages. Response Messages.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2021. This Internet-Draft will expire on 25 February 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Technical Terms . . . . . . . . . . . . . . . . . . . . . . . 3 3. Technical Terms . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
5. Network Technology . . . . . . . . . . . . . . . . . . . . . 6 5. Network Technology . . . . . . . . . . . . . . . . . . . . . 7
6. Time Transfer and Delay Measurement . . . . . . . . . . . . . 7 6. Time Transfer and Delay Measurement . . . . . . . . . . . . . 7
7. Default Message Rates . . . . . . . . . . . . . . . . . . . . 8 7. Default Message Rates . . . . . . . . . . . . . . . . . . . . 9
8. Requirements for Master Clocks . . . . . . . . . . . . . . . 8 8. Requirements for Master Clocks . . . . . . . . . . . . . . . 9
9. Requirements for Slave Clocks . . . . . . . . . . . . . . . . 8 9. Requirements for Slave Clocks . . . . . . . . . . . . . . . . 9
10. Requirements for Transparent Clocks . . . . . . . . . . . . . 9 10. Requirements for Transparent Clocks . . . . . . . . . . . . . 10
11. Requirements for Boundary Clocks . . . . . . . . . . . . . . 9 11. Requirements for Boundary Clocks . . . . . . . . . . . . . . 10
12. Management and Signaling Messages . . . . . . . . . . . . . . 9 12. Management and Signaling Messages . . . . . . . . . . . . . . 10
13. Forbidden PTP Options . . . . . . . . . . . . . . . . . . . . 10 13. Forbidden PTP Options . . . . . . . . . . . . . . . . . . . . 10
14. Interoperation with IEEE 1588 Default Profile . . . . . . . . 10 14. Interoperation with IEEE 1588 Default Profile . . . . . . . . 10
15. Profile Identification . . . . . . . . . . . . . . . . . . . 10 15. Profile Identification . . . . . . . . . . . . . . . . . . . 11
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
18. Security Considerations . . . . . . . . . . . . . . . . . . . 11 18. Security Considerations . . . . . . . . . . . . . . . . . . . 11
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
19.1. Normative References . . . . . . . . . . . . . . . . . . 11 19.1. Normative References . . . . . . . . . . . . . . . . . . 12
19.2. Informative References . . . . . . . . . . . . . . . . . 12 19.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Precision Time Protocol ("PTP"), standardized in IEEE 1588, has The Precision Time Protocol ("PTP"), standardized in IEEE 1588, has
been designed in its first version (IEEE 1588-2002) with the goal to been designed in its first version (IEEE 1588-2002) with the goal to
minimize configuration on the participating nodes. Network minimize configuration on the participating nodes. Network
communication was based solely on multicast messages, which unlike communication was based solely on multicast messages, which unlike
NTP did not require that a receiving node ("slave clock") in NTP did not require that a receiving node ("slave clock") in
IEEE 1588-2008 [IEEE1588] needs to know the identity of the time IEEE 1588-2019 [IEEE1588] needs to know the identity of the time
sources in the network (the Master Clocks). sources in the network (the Master Clocks). This document describes
clock roles and port states using the terms master and slave in order
to correspond to the terms used in IEEE 1588, on which this document
is based. There is an active project in the IEEE to select
alternative terms. When this project is completed, then master and
slave will be replaced with the new alternative terms in an update to
this document.
The "Best Master Clock Algorithm" (IEEE 1588-2008 [IEEE1588] The "Best Master Clock Algorithm" (IEEE 1588-2019 [IEEE1588]
Subclause 9.3), a mechanism that all participating PTP nodes must Subclause 9.3), a mechanism that all participating PTP nodes must
follow, set up strict rules for all members of a PTP domain to follow, set up strict rules for all members of a PTP domain to
determine which node shall be the active sending time source (Master determine which node shall be the active sending time source (Master
Clock). Although the multicast communication model has advantages in Clock). Although the multicast communication model has advantages in
smaller networks, it complicated the application of PTP in larger smaller networks, it complicated the application of PTP in larger
networks, for example in environments like IP based telecommunication networks, for example in environments like IP based telecommunication
networks or financial data centers. It is considered inefficient networks or financial data centers. It is considered inefficient
that, even if the content of a message applies only to one receiver, that, even if the content of a message applies only to one receiver,
it is forwarded by the underlying network (IP) to all nodes, it is forwarded by the underlying network (IP) to all nodes,
requiring them to spend network bandwidth and other resources, such requiring them to spend network bandwidth and other resources, such
as CPU cycles, to drop the message. as CPU cycles, to drop the message.
The second revision of the standard (IEEE 1588-2008) is the current The third edition of the standard (IEEE 1588-2019) defines PTPv2.1
version (also known as PTPv2) and introduced the possibility to use and includes the possibility to use unicast communication between the
unicast communication between the PTP nodes in order to overcome the PTP nodes in order to overcome the limitation of using multicast
limitation of using multicast messages for the bi-directional messages for the bi-directional information exchange between PTP
information exchange between PTP nodes. The unicast approach avoided nodes. The unicast approach avoided that, in PTP domains with a lot
that, in PTP domains with a lot of nodes, devices had to throw away of nodes, devices had to throw away more than 99% of the received
more than 99% of the received multicast messages because they carried multicast messages because they carried information for some other
information for some other node. PTPv2 also introduced PTP profiles node. PTPv2.1 also includes PTP profiles (IEEE 1588-2019 [IEEE1588]
(IEEE 1588-2008 [IEEE1588] subclause 19.3). This construct allows subclause 20.3). This construct allows organizations to specify
organizations to specify selections of attribute values and optional selections of attribute values and optional features, simplifying the
features, simplifying the configuration of PTP nodes for a specific configuration of PTP nodes for a specific application. Instead of
application. Instead of having to go through all possible parameters having to go through all possible parameters and configuration
and configuration options and individually set them up, selecting a options and individually set them up, selecting a profile on a PTP
profile on a PTP node will set all the parameters that are specified node will set all the parameters that are specified in the profile to
in the profile to a defined value. If a PTP profile definition a defined value. If a PTP profile definition allows multiple values
allows multiple values for a parameter, selection of the profile will for a parameter, selection of the profile will set the profile-
set the profile-specific default value for this parameter. specific default value for this parameter. Parameters not allowing
Parameters not allowing multiple values are set to the value defined multiple values are set to the value defined in the PTP profile.
in the PTP profile. Many PTP features and functions are optional, Many PTP features and functions are optional, and a profile should
and a profile should also define which optional features of PTP are also define which optional features of PTP are required, permitted,
required, permitted, or prohibited. It is possible to extend the PTP or prohibited. It is possible to extend the PTP standard with a PTP
standard with a PTP profile by using the TLV mechanism of PTP (see profile by using the TLV mechanism of PTP (see IEEE 1588-2019
IEEE 1588-2008 [IEEE1588] subclause 13.4), defining an optional Best [IEEE1588] subclause 13.4), defining an optional Best Master Clock
Master Clock Algorithm and a few other ways. PTP has its own Algorithm and a few other ways. PTP has its own management protocol
management protocol (defined in IEEE 1588-2008 [IEEE1588] subclause (defined in IEEE 1588-2019 [IEEE1588] subclause 15.2) but allows a
15.2) but allows a PTP profile specify an alternative management PTP profile specify an alternative management mechanism, for example
mechanism, for example SNMP. NETCONF.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Technical Terms 3. Technical Terms
o Acceptable Master Table: A PTP Slave Clock may maintain a list of * Acceptable Master Table: A PTP Slave Clock may maintain a list of
masters which it is willing to synchronize to. masters which it is willing to synchronize to.
o Alternate Master: A PTP Master Clock, which is not the Best * Alternate Master: A PTP Master Clock, which is not the Best
Master, may act as a master with the Alternate Master flag set on Master, may act as a master with the Alternate Master flag set on
the messages it sends. the messages it sends.
o Announce message: Contains the Master Clock properties of a Master * Announce message: Contains the Master Clock properties of a Master
Clock. Used to determine the Best Master. Clock. Used to determine the Best Master.
o Best Master: A clock with a port in the master state, operating * Best Master: A clock with a port in the master state, operating
consistently with the Best Master Clock Algorithm. consistently with the Best Master Clock Algorithm.
o Best Master Clock Algorithm: A method for determining which state * Best Master Clock Algorithm: A method for determining which state
a port of a PTP clock should be in. The algorithm works by a port of a PTP clock should be in. The algorithm works by
identifying which of several PTP Master capable clocks is the best identifying which of several PTP Master capable clocks is the best
master. Clocks have priority to become the acting Grandmaster, master. Clocks have priority to become the acting Grandmaster,
based on the properties each Master Clock sends in its Announce based on the properties each Master Clock sends in its Announce
Message. Message.
o Boundary Clock: A device with more than one PTP port. Generally * Boundary Clock: A device with more than one PTP port. Generally
boundary Clocks will have one port in slave state to receive boundary Clocks will have one port in slave state to receive
timing and then other ports in master state to re-distribute the timing and then other ports in master state to re-distribute the
timing. timing.
o Clock Identity: In IEEE 1588-2008 this is a 64-bit number assigned * Clock Identity: In IEEE 1588-2019 this is a 64-bit number assigned
to each PTP clock which must be unique. Often it is derived from to each PTP clock which must be unique. Often it is derived from
the Ethernet MAC address, since there is already an international the Ethernet MAC address, since there is already an international
infrastructure for assigning unique numbers to each device infrastructure for assigning unique numbers to each device
manufactured. manufactured.
o Domain: Every PTP message contains a domain number. Domains are * Domain: Every PTP message contains a domain number. Domains are
treated as separate PTP systems in the network. Clocks, however, treated as separate PTP systems in the network. Clocks, however,
can combine the timing information derived from multiple domains. can combine the timing information derived from multiple domains.
o End to End Delay Measurement Mechanism: A network delay * End to End Delay Measurement Mechanism: A network delay
measurement mechanism in PTP facilitated by an exchange of measurement mechanism in PTP facilitated by an exchange of
messages between a Master Clock and Slave Clock. messages between a Master Clock and Slave Clock.
o Grandmaster: the primary Master Clock within a domain of a PTP * Grandmaster: the primary Master Clock within a domain of a PTP
system system
o IEEE 1588: The timing and synchronization standard which defines * IEEE 1588: The timing and synchronization standard which defines
PTP, and describes the node, system, and communication properties PTP, and describes the node, system, and communication properties
necessary to support PTP. necessary to support PTP.
o Master Clock: a clock with at least one port in the master state. * Master Clock: a clock with at least one port in the master state.
o NTP: Network Time Protocol, defined by RFC 5905, see RFC 5905 * NTP: Network Time Protocol, defined by RFC 5905, see RFC 5905
[RFC5905] [RFC5905]
o Ordinary Clock: A clock that has a single Precision Time Protocol * Ordinary Clock: A clock that has a single Precision Time Protocol
(PTP) port in a domain and maintains the timescale used in the (PTP) port in a domain and maintains the timescale used in the
domain. It may serve as a Master Clock, or be a slave clock. domain. It may serve as a Master Clock, or be a slave clock.
o Peer to Peer Delay Measurement Mechanism: A network delay * Peer to Peer Delay Measurement Mechanism: A network delay
measurement mechanism in PTP facilitated by an exchange of measurement mechanism in PTP facilitated by an exchange of
messages between adjacent devices in a network. messages between adjacent devices in a network.
o Preferred Master: A device intended to act primarily as the * Preferred Master: A device intended to act primarily as the
Grandmaster of a PTP system, or as a back up to a Grandmaster. Grandmaster of a PTP system, or as a back up to a Grandmaster.
o PTP: The Precision Time Protocol, the timing and synchronization * PTP: The Precision Time Protocol, the timing and synchronization
protocol defined by IEEE 1588. protocol defined by IEEE 1588.
o PTP port: An interface of a PTP clock with the network. Note that * PTP port: An interface of a PTP clock with the network. Note that
there may be multiple PTP ports running on one physical interface, there may be multiple PTP ports running on one physical interface,
for example, a unicast slave which talks to several Grandmaster for example, a unicast slave which talks to several Grandmaster
clocks in parallel. clocks in parallel.
o PTPv2: Refers specifically to the second version of PTP defined by * PTPv2: Refers specifically to the second version of PTP defined by
IEEE 1588-2008. IEEE 1588-2019.
o Rogue Master: A clock with a port in the master state, even though * Rogue Master: A clock with a port in the master state, even though
it should not be in the master state according to the Best Master it should not be in the master state according to the Best Master
Clock Algorithm, and does not set the alternate master flag. Clock Algorithm, and does not set the alternate master flag.
o Slave clock: a clock with at least one port in the slave state, * Slave clock: a clock with at least one port in the slave state,
and no ports in the master state. and no ports in the master state.
o Slave Only Clock: An Ordinary Clock which cannot become a Master * Slave Only Clock: An Ordinary Clock which cannot become a Master
Clock. Clock.
o TLV: Type Length Value, a mechanism for extending messages in * TLV: Type Length Value, a mechanism for extending messages in
networked communications. networked communications.
o Transparent Clock. A device that measures the time taken for a * Transparent Clock. A device that measures the time taken for a
PTP event message to transit the device and then updates the PTP event message to transit the device and then updates the
message with a correction for this transit time. message with a correction for this transit time.
o Unicast Discovery: A mechanism for PTP slaves to establish a * Unicast Discovery: A mechanism for PTP slaves to establish a
unicast communication with PTP masters using a configures table of unicast communication with PTP masters using a configures table of
master IP addresses and Unicast Message Negotiation. master IP addresses and Unicast Message Negotiation.
o Unicast Negotiation: A mechanism in PTP for Slave Clocks to * Unicast Negotiation: A mechanism in PTP for Slave Clocks to
negotiate unicast Sync, announce and Delay Request Message Rates negotiate unicast Sync, announce and Delay Request Message Rates
from a Master Clock. from a Master Clock.
4. Problem Statement 4. Problem Statement
This document describes a version of PTP intended to work in large This document describes a version of PTP intended to work in large
enterprise networks. Such networks are deployed, for example, in enterprise networks. Such networks are deployed, for example, in
financial corporations. It is becoming increasingly common in such financial corporations. It is becoming increasingly common in such
networks to perform distributed time tagged measurements, such as networks to perform distributed time tagged measurements, such as
one-way packet latencies and cumulative delays on software systems one-way packet latencies and cumulative delays on software systems
skipping to change at page 9, line 10 skipping to change at page 9, line 45
Slave clocks MUST be able to operate properly in a network which Slave clocks MUST be able to operate properly in a network which
contains multiple Masters in multiple domains. Slaves SHOULD make contains multiple Masters in multiple domains. Slaves SHOULD make
use of information from the all Masters in their clock control use of information from the all Masters in their clock control
subsystems. Slave Clocks MUST be able to operate properly in the subsystems. Slave Clocks MUST be able to operate properly in the
presence of a Rogue Master. Slaves SHOULD NOT Synchronize to a presence of a Rogue Master. Slaves SHOULD NOT Synchronize to a
Master which is not the Best Master in its domain. Slaves will Master which is not the Best Master in its domain. Slaves will
continue to recognize a Best Master for the duration of the Announce continue to recognize a Best Master for the duration of the Announce
Time Out Interval. Slaves MAY use an Acceptable Master Table. If a Time Out Interval. Slaves MAY use an Acceptable Master Table. If a
Master is not an Acceptable Master, then the Slave MUST NOT Master is not an Acceptable Master, then the Slave MUST NOT
synchronize to it. Note that IEEE 1588-2008 requires slave clocks to synchronize to it. Note that IEEE 1588-2019 requires slave clocks to
support both two-step or one-step Master clocks. See IEEE 1588 support both two-step or one-step Master clocks. See IEEE 1588
[IEEE1588], subClause 11.2. [IEEE1588], subClause 11.2.
Since Announce messages are sent as multicast messages slaves can Since Announce messages are sent as multicast messages slaves can
obtain the IP addresses of a master from the Announce messages. Note obtain the IP addresses of a master from the Announce messages. Note
that the IP source addresses of Sync and Follow-up messages may have that the IP source addresses of Sync and Follow-up messages may have
been replaced by the source addresses of a Transparent Clock, so, been replaced by the source addresses of a Transparent Clock, so,
slaves MUST send Delay Request messages to the IP address in the slaves MUST send Delay Request messages to the IP address in the
Announce message. Sync and Follow-up messages can be correlated with Announce message. Sync and Follow-up messages can be correlated with
the Announce message using the clock ID, which is never altered by the Announce message using the clock ID, which is never altered by
skipping to change at page 11, line 36 skipping to change at page 12, line 17
obtained using standard management mechanisms which include security, obtained using standard management mechanisms which include security,
for example NETCONF NETCONF [RFC6241]. for example NETCONF NETCONF [RFC6241].
General security considerations of time protocols are discussed in General security considerations of time protocols are discussed in
RFC 7384 [RFC7384]. RFC 7384 [RFC7384].
19. References 19. References
19.1. Normative References 19.1. Normative References
[IEEE1588] [IEEE1588] Institute of Electrical and Electronics Engineers, "IEEE
Institute of Electrical and Electronics Engineers, "IEEE std. 1588-2019, "IEEE Standard for a Precision Clock
std. 1588-2008, "IEEE Standard for a Precision Clock
Synchronization for Networked Measurement and Control Synchronization for Networked Measurement and Control
Systems."", 7 2008, <https://www.ieee.org>. Systems."", November 2019, <https://www.ieee.org>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 12, line 19 skipping to change at page 12, line 44
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
19.2. Informative References 19.2. Informative References
[G8271] International Telecommunication Union, "ITU-T G.8271/ [G8271] International Telecommunication Union, "ITU-T G.8271/
Y.1366, "Time and Phase Synchronization Aspects of Packet Y.1366, "Time and Phase Synchronization Aspects of Packet
Networks"", 2 2012, <https://www.itu.int>. Networks"", February 2012, <https://www.itu.int>.
[ISPCS] Arnold, D., "Plugfest Report", 10 2017, [ISPCS] Arnold, D.A., "Plugfest Report", October 2017,
<https://www.ispcs.org>. <https://www.ispcs.org>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
skipping to change at page 12, line 43 skipping to change at page 13, line 19
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
Authors' Addresses Authors' Addresses
Doug Arnold Doug Arnold
Meinberg-USA Meinberg-USA
3 Concord Rd 3 Concord Rd
Shrewsbury, Massachusetts 01545 Shrewsbury, Massachusetts 01545
USA United States of America
Email: doug.arnold@meinberg-usa.com Email: doug.arnold@meinberg-usa.com
Heiko Gerstung Heiko Gerstung
Meinberg Meinberg
Lange Wand 9 Lange Wand 9
Bad Pyrmont 31812 31812 Bad Pyrmont
Germany Germany
Email: heiko.gerstung@meinberg.de Email: heiko.gerstung@meinberg.de
 End of changes. 47 change blocks. 
97 lines changed or deleted 102 lines changed or added

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