rfc9760v2.txt		rfc9760.txt
	skipping to change at line 233 ¶		skipping to change at line 233 ¶
	Rogue timeTransmitter: A clock that has a PTP Port in the		Rogue timeTransmitter: A clock that has a PTP Port in the
	timeTransmitter state -- even though it should not be in the		timeTransmitter state -- even though it should not be in the
	timeTransmitter state according to the Best TimeTransmitter Clock		timeTransmitter state according to the Best TimeTransmitter Clock
	Algorithm -- and that does not set the Alternate timeTransmitter		Algorithm -- and that does not set the Alternate timeTransmitter
	flag.		flag.
	TimeReceiver Clock: A clock with at least one PTP Port in the		TimeReceiver Clock: A clock with at least one PTP Port in the
	timeReceiver state and no PTP Ports in the timeTransmitter state.		timeReceiver state and no PTP Ports in the timeTransmitter state.
	TimeReceiver only clock: An Ordinary Clock that cannot become a		TimeReceiver Only Clock: An Ordinary Clock that cannot become a
	timeTransmitter Clock.		timeTransmitter Clock.
	TimeTransmitter Clock: A clock with at least one PTP Port in the		TimeTransmitter Clock: A clock with at least one PTP Port in the
	timeTransmitter state.		timeTransmitter state.
	TLV: Type Length Value -- a mechanism for extending messages in		TLV: Type Length Value -- a mechanism for extending messages in
	networked communications.		networked communications.
	Transparent Clock: A device that measures the time taken for a PTP		Transparent Clock: A device that measures the time taken for a PTP
	event message to transit the device and then updates the message		event message to transit the device and then updates the message
	with a correction for this transit time.		with a correction for this transit time.
	Unicast Discovery: A mechanism for PTP timeReceivers to establish a		Unicast discovery: A mechanism for PTP timeReceivers to establish a
	unicast communication with PTP timeTransmitters using a configured		unicast communication with PTP timeTransmitters using a configured
	table of timeTransmitter IP addresses and unicast message		table of timeTransmitter IP addresses and unicast message
	negotiation.		negotiation.
	Unicast message negotiation: A mechanism in PTP for timeReceiver		Unicast message negotiation: A mechanism in PTP for timeReceiver
	Clocks to negotiate unicast Sync, Announce, and Delay Request		Clocks to negotiate unicast Sync, Announce, and Delay Request
	message transmission rates from timeTransmitters.		message transmission rates from timeTransmitters.
	4. Problem Statement		4. Problem Statement
	This document describes how PTP can be applied to work in large		This document describes how PTP can be applied to work in large
	enterprise networks. See ISPCS [RFC2026] for information on IETF		enterprise networks. Such large networks are deployed, for example,
	applicability statements. Such large networks are deployed, for		in financial corporations. It is becoming increasingly common in
	example, in financial corporations. It is becoming increasingly		such networks to perform distributed time-tagged measurements, such
	common in such networks to perform distributed time-tagged		as one-way packet latencies and cumulative delays on software systems
	measurements, such as one-way packet latencies and cumulative delays		spread across multiple computers. Furthermore, there is often a
	on software systems spread across multiple computers. Furthermore,		desire to check the age of information time-tagged by a different
	there is often a desire to check the age of information time-tagged		machine. To perform these measurements, it is necessary to deliver a
	by a different machine. To perform these measurements, it is		common precise time to multiple devices on a network. Accuracy
	necessary to deliver a common precise time to multiple devices on a		currently required in the financial industry ranges from 100
	network. Accuracy currently required in the financial industry		microseconds to 1 nanosecond to the Grandmaster. This PTP Profile
	ranges from 100 microseconds to 1 nanosecond to the Grandmaster.		does not specify timing performance requirements, but such
	This PTP Profile does not specify timing performance requirements,		requirements explain why the needs cannot always be met by NTP as
	but such requirements explain why the needs cannot always be met by		commonly implemented. Such accuracy cannot usually be achieved with
	NTP as commonly implemented. Such accuracy cannot usually be		NTP, without adding non-standard customizations such as on-path
	achieved with NTP, without adding non-standard customizations such as		support, similar to what is done in PTP with Transparent Clocks and
	on-path support, similar to what is done in PTP with Transparent		Boundary Clocks. Such PTP support is commonly available in switches
	Clocks and Boundary Clocks. Such PTP support is commonly available		and routers, and many such devices have already been deployed in
	in switches and routers, and many such devices have already been		networks. Because PTP has a complex range of features and options,
	deployed in networks. Because PTP has a complex range of features		it is necessary to create a PTP Profile for enterprise networks to
	and options, it is necessary to create a PTP Profile for enterprise		achieve interoperability among equipment manufactured by different
	networks to achieve interoperability among equipment manufactured by		vendors.
	different vendors.
	Although enterprise networks can be large, it is becoming		Although enterprise networks can be large, it is becoming
	increasingly common to deploy multicast protocols, even across		increasingly common to deploy multicast protocols, even across
	multiple subnets. For this reason, it is desirable to make use of		multiple subnets. For this reason, it is desirable to make use of
	multicast whenever the information going to many destinations is the		multicast whenever the information going to many destinations is the
	same. It is also advantageous to send information that is only		same. It is also advantageous to send information that is only
	relevant to one device as a unicast message. The latter can be		relevant to one device as a unicast message. The latter can be
	essential as the number of PTP timeReceivers becomes hundreds or		essential as the number of PTP timeReceivers becomes hundreds or
	thousands.		thousands.
	skipping to change at line 314 ¶		skipping to change at line 313 ¶
	IPv6 instances in the same network node MUST operate in different PTP		IPv6 instances in the same network node MUST operate in different PTP
	domains. PTP clocks that communicate using IPv4 can transfer time to		domains. PTP clocks that communicate using IPv4 can transfer time to
	PTP clocks using IPv6, or the reverse, if and only if there is a		PTP clocks using IPv6, or the reverse, if and only if there is a
	network node that simultaneously communicates with both PTP domains		network node that simultaneously communicates with both PTP domains
	in the different IP versions.		in the different IP versions.
	The PTP system MAY include switches and routers. These devices MAY		The PTP system MAY include switches and routers. These devices MAY
	be Transparent Clocks, Boundary Clocks, or neither, in any		be Transparent Clocks, Boundary Clocks, or neither, in any
	combination. PTP clocks MAY be Preferred timeTransmitters, Ordinary		combination. PTP clocks MAY be Preferred timeTransmitters, Ordinary
	Clocks, or Boundary Clocks. The Ordinary Clocks may be timeReceiver		Clocks, or Boundary Clocks. The Ordinary Clocks may be timeReceiver
	only clocks or may be timeTransmitter capable.		Only Clocks or may be timeTransmitter capable.
	Note that PTP Ports will need to keep track of the Clock ID of		Note that PTP Ports will need to keep track of the Clock ID of
	received messages and not just the IP or Layer 2 addresses in any		received messages and not just the IP or Layer 2 addresses in any
	network that includes Transparent Clocks or that might include them		network that includes Transparent Clocks or that might include them
	in the future. This is important, since Transparent Clocks might		in the future. This is important, since Transparent Clocks might
	treat PTP messages that are altered at the PTP application layer as		treat PTP messages that are altered at the PTP application layer as
	new IP packets and new Layer 2 frames when the PTP messages are		new IP packets and new Layer 2 frames when the PTP messages are
	retransmitted. In IPv4 networks, some clocks might be hidden behind		retransmitted. In IPv4 networks, some clocks might be hidden behind
	a NAT, which hides their IP addresses from the rest of the network.		a NAT, which hides their IP addresses from the rest of the network.
	Note also that the use of NATs may place limitations on the topology		Note also that the use of NATs may place limitations on the topology
	skipping to change at line 369 ¶		skipping to change at line 368 ¶
	are explained in [IEEE1588-2019], Annex D, Section D.3. These		are explained in [IEEE1588-2019], Annex D, Section D.3. These
	addresses are allotted by IANA; see the "IPv6 Multicast Address Space		addresses are allotted by IANA; see the "IPv6 Multicast Address Space
	Registry" [IPv6Registry].		Registry" [IPv6Registry].
	Delay Request messages MAY be sent as either multicast or unicast PTP		Delay Request messages MAY be sent as either multicast or unicast PTP
	event messages. TimeTransmitter Clocks MUST respond to multicast		event messages. TimeTransmitter Clocks MUST respond to multicast
	Delay Request messages with multicast Delay Response PTP general		Delay Request messages with multicast Delay Response PTP general
	messages. TimeTransmitter Clocks MUST respond to unicast Delay		messages. TimeTransmitter Clocks MUST respond to unicast Delay
	Request PTP event messages with unicast Delay Response PTP general		Request PTP event messages with unicast Delay Response PTP general
	messages. This allows for the use of Ordinary Clocks that do not		messages. This allows for the use of Ordinary Clocks that do not
	support the Enterprise Profile, if they are timeReceiver only clocks.		support the Enterprise Profile, if they are timeReceiver Only Clocks.
	Clocks SHOULD include support for multiple domains. The purpose is		Clocks SHOULD include support for multiple domains. The purpose is
	to support multiple simultaneous timeTransmitters for redundancy.		to support multiple simultaneous timeTransmitters for redundancy.
	Leaf devices (non-forwarding devices) can use timing information from		Leaf devices (non-forwarding devices) can use timing information from
	multiple timeTransmitters by combining information from multiple		multiple timeTransmitters by combining information from multiple
	instantiations of a PTP stack, each operating in a different PTP		instantiations of a PTP stack, each operating in a different PTP
	domain. To check for faulty timeTransmitter Clocks, redundant		domain. To check for faulty timeTransmitter Clocks, redundant
	sources of timing can be evaluated as an ensemble and/or compared		sources of timing can be evaluated as an ensemble and/or compared
	individually. The use of multiple simultaneous timeTransmitters will		individually. The use of multiple simultaneous timeTransmitters will
	help mitigate faulty timeTransmitters reporting as healthy, network		help mitigate faulty timeTransmitters reporting as healthy, network
	skipping to change at line 631 ¶		skipping to change at line 630 ¶
	[IPv6Registry]		[IPv6Registry]
	IANA, "IPv6 Multicast Address Space Registry",		IANA, "IPv6 Multicast Address Space Registry",
	<https://iana.org/assignments/ipv6-multicast-addresses>.		<https://iana.org/assignments/ipv6-multicast-addresses>.
	[ISPCS] Arnold, D. and K. Harris, "Plugfest", Proceedings of the		[ISPCS] Arnold, D. and K. Harris, "Plugfest", Proceedings of the
	IEEE International Symposium on Precision Clock		IEEE International Symposium on Precision Clock
	Synchronization for Measurement, Control, and		Synchronization for Measurement, Control, and
	Communication (ISPCS), August 2017,		Communication (ISPCS), August 2017,
	<https://2017.ispcs.org/plugfest>.		<https://2017.ispcs.org/plugfest>.
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
	<https://www.rfc-editor.org/info/rfc2026>.
	[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,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
End of changes. 6 change blocks.
	30 lines changed or deleted		25 lines changed or added
This html diff was produced by rfcdiff 1.48.