draft-stein-tictoc-modules-02.txt		draft-stein-tictoc-modules-03.txt
	TICTOC Tim Frost		TICTOC Tim Frost
	INTERNET-DRAFT Greg Dowd		INTERNET-DRAFT Greg Dowd
	Intended Status: Informational Symmetricom		Intended Status: Informational Symmetricom
	Karen O'Donoghue		Karen O'Donoghue
	US Navy		US Navy
	Architecture for the Transmission of Timing over Packet Networks		Architecture for the Transmission of Timing over Packet Networks
	draft-stein-tictoc-modules-02.txt		draft-stein-tictoc-modules-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware have		applicable patent or other IPR claims of which he or she is aware have
	been or will be disclosed, and any of which he or she becomes aware will		been or will be disclosed, and any of which he or she becomes aware will
	be disclosed, in accordance with Section 6 of BCP 79.		be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other groups		Force (IETF), its areas, and its working groups. Note that other groups
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	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 material		time. It is inappropriate to use Internet-Drafts as reference material
	or to cite them other than as "work in progress."		or to cite them other than as "work in 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/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	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 14, 2009.		This Internet-Draft will expire on May 03, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008)		Copyright (C) The IETF Trust (2008)
	Abstract		Abstract
	This Internet draft proposes an architecture for the transmission of		This Internet draft proposes an architecture for the transmission of
	timing over packet networks. It identifies the major functional		timing over packet networks. It identifies the major functional
	components, and maps the current solutions onto this framework.		components, and maps the current solutions onto this framework.
	skipping to change at page 2, line 22		skipping to change at page 2, line 22
	2.1. Local Oscillator and Frequency Synthesizers 7		2.1. Local Oscillator and Frequency Synthesizers 7
	2.2. Frequency Distribution Protocols 8		2.2. Frequency Distribution Protocols 8
	2.3. Frequency Acquisition Algorithms 8		2.3. Frequency Acquisition Algorithms 8
	2.3.1. Packet Selection and Discard Algorithms 9		2.3.1. Packet Selection and Discard Algorithms 9
	2.3.2. Filtering and Control Servos 9		2.3.2. Filtering and Control Servos 9
	2.3.3. Server Contribution 10		2.3.3. Server Contribution 10
	2.3.4. Reference Algorithm 10		2.3.4. Reference Algorithm 10
	2.4. Frequency Presentation 10		2.4. Frequency Presentation 10
	3. Time Layer 11		3. Time Layer 11
	3.1. Time Distribution Protocols 11		3.1. Time Distribution Protocols 11
	3.2. Ranging 12		3.2. Ranging 13
	3.3. Time Presentation 13		3.3. Time Presentation 13
	4. Generic Modules 14		4. Generic Modules 15
	4.1. Security Mechanisms 14		4.1. Security Mechanisms 15
	4.2. Autodiscovery and Master Clock Selection 14		4.2. Autodiscovery and Master Clock Selection 15
	4.3. Redundancy and Fail-Over Mechanisms 16		4.3. Redundancy and Fail-Over Mechanisms 17
	4.4. OAM, SSM, and Performance Monitoring 16		4.4. OAM, SSM, and Performance Monitoring 17
	4.5. Network Management 16		4.5. Network Management 17
	4.6. Application profiles 16		4.6. Application profiles 17
	5. Network Support 17		5. Network Support 18
	5.1. Path Selection 17		5.1. Path Selection 18
	5.2. Network and Traffic Engineering 17		5.2. Network and Traffic Engineering 18
	5.3. Service Level Specifications and QoS settings 18		5.3. Service Level Specifications and QoS settings 19
	5.4. Routing considerations 18		5.4. Routing considerations 19
	5.5. On-path Support 19		5.5. On-path Support 20
	6. Security Considerations 19		6. Security Considerations 20
	7. IANA Considerations 19		7. IANA Considerations 20
	8. Acknowledgements 19		8. Acknowledgements 20
	INFORMATIVE REFERENCES 20		INFORMATIVE REFERENCES 21
	AUTHORS' ADDRESSES 20		AUTHORS' ADDRESSES 21
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	1. Introduction		1. Introduction
	In this document the term "timing" will be used to refer to recovery of		In this document the term "timing" will be used to refer to recovery of
	frequency and/or time (wall-clock).		frequency and/or time (wall-clock).
	There is an emerging need to distribute highly accurate time and		There is an emerging need to distribute highly accurate time and
	frequency information over IP and over MPLS packet switched networks		frequency information over IP and over MPLS packet switched networks
	(PSNs). A variety of applications require time and/or frequency		(PSNs). A variety of applications require time and/or frequency
	information to a precision which existing protocols cannot supply.		information to a precision which existing protocols cannot supply.
	Several other groups are working on related issues. For example, the NTP		Several other groups are working on related issues. For example, the NTP
	Working Group in IETF is working on an upgrade of the long-standing		Working Group in IETF is working on an upgrade of the long-standing
	Network Time Protocol [RFC1305]. The IEEE has recently revised its		Network Time Protocol [RFC1305]. The IEEE has recently revised its
	Precision Time Protocol [IEEE1588]. The ITU-T has defined Synchronous		Precision Time Protocol (PTP) [IEEE1588]. The ITU-T has defined
	Ethernet, a physical layer technology for transfer of frequency across		Synchronous Ethernet, a physical layer technology for transfer of
	native Ethernet [G.8261, G.8262].		frequency across native Ethernet [G.8261, G.8262].
	However, none of these efforts are sufficient by themselves to create a		However, none of these efforts are sufficient by themselves to create a
	complete and robust time and frequency transfer ecosystem in the IP and		complete and robust time and frequency transfer ecosystem in the IP and
	MPLS network environment. The TICTOC (Timing over IP Connections and		MPLS network environment. The TICTOC (Timing over IP Connections and
	Transmission of Clock) Working Group was created to develop solutions		Transmission of Clock) Working Group was created to develop solutions
	that meet the needs of the various applications for timing over packet		that meet the needs of the various applications for timing over packet
	networks.		networks.
	This draft attempts to define an architecture for a TICTOC system,		This draft attempts to define an architecture for a TICTOC system,
	identifying the various functional components, and considering the		identifying the various functional components, and considering the
	skipping to change at page 7, line 15		skipping to change at page 7, line 15
	2. Frequency Layer		2. Frequency Layer
	There are applications that require an accurate frequency reference, but		There are applications that require an accurate frequency reference, but
	do not require knowledge of absolute time. In addition, it is often		do not require knowledge of absolute time. In addition, it is often
	wise to acquire frequency for applications that require absolute time		wise to acquire frequency for applications that require absolute time
	but do not directly use frequency.		but do not directly use frequency.
	TICTOC is concerned with the network frequency transfer using packet		TICTOC is concerned with the network frequency transfer using packet
	technology. Frequency may be transferred across a network using the		technology. Frequency may be transferred across a network using the
	physical layer, such as through the use of a synchronous network		physical layer, such as through the use of a synchronous network
	interface (for example synchronous Ethernet [G.8262]). The use of the		interface (for example Synchronous Ethernet [G.8262]). The use of the
	physical layer may produce a higher quality frequency reference than		physical layer may produce a higher quality frequency reference than
	achievable using packet based network frequency transfer, but is outside		achievable using packet based network frequency transfer, but is outside
	the scope of this document.		the scope of this document.
	2.1. Local Oscillator and Frequency Synthesizers		2.1. Local Oscillator and Frequency Synthesizers
	TICTOC masters and clients both need local sources of frequency. For		TICTOC masters and clients both need local sources of frequency. For
	masters, this may be provided by high quality Cesium clock with		masters, this may be provided by high quality Cesium clock with
	extremely good long term accuracy, or by an atomic clock with		extremely good long term accuracy, or by an atomic clock with
	somewhat lower accuracy, but which is disciplined by comparison with		somewhat lower accuracy, but which is disciplined by comparison with
	skipping to change at page 8, line 28		skipping to change at page 8, line 28
	information transfer from the master (where the frequency is known)		information transfer from the master (where the frequency is known)
	to the client. In particular, frequency distribution protocols can		to the client. In particular, frequency distribution protocols can
	be broadcast or multicast to many clients, without the master needing		be broadcast or multicast to many clients, without the master needing
	to know the client identities. Frequency distribution protocols may		to know the client identities. Frequency distribution protocols may
	even operate when there is no return path available. Exceptions to		even operate when there is no return path available. Exceptions to
	this rule are control messages sent by the client requesting		this rule are control messages sent by the client requesting
	commencing or termination of the frequency distribution service, or		commencing or termination of the frequency distribution service, or
	changing its parameters (e.g., update rate).		changing its parameters (e.g., update rate).
	Frequency distribution protocols can be broadcast, multicast or		Frequency distribution protocols can be broadcast, multicast or
	unicast. Multicast transmission conserves network bandwidth, while		unicast. Multicast transmission conserves network bandwidth since
	unicast transmission is often more desirable.		timing packets may be distributed to multiple clients or slaves.
			However, unicast transmission is often more desirable, since it
			avoids the multicast replication operation in each switch or router,
			which may add variable delay.
	The TICTOC architecture is modular, and not bound to the frequency		The TICTOC architecture is modular, and not bound to the frequency
	distribution protocol. It is possible to use different frequency		distribution protocol. It is possible to use different frequency
	distribution methods for different applications and environments,		distribution methods for different applications and environments,
	e.g. the use of physical layer frequency distribution protocols such		e.g. the use of physical layer frequency distribution protocols such
	as Synchronous Ethernet.		as Synchronous Ethernet.
	2.3. Frequency Acquisition Algorithms		2.3. Frequency Acquisition Algorithms
	A TICTOC client needs to be able to recover the original timebase (or		A TICTOC client needs to be able to recover the original timebase (or
	frequency reference) of the master or server. In general it achieves		frequency reference) of the master or server. In general it achieves
	this by comparing the arrival rate of packets with the original		this by comparing the arrival time of packets with the original
	sending rate. From this it can determine the relationship between the		sending time. From this it can determine the relationship between the
	local timebase and the master timebase.		local timebase and the master timebase.
	Observed arrival times of frequency distribution protocol packets are		Observed arrival times of frequency distribution protocol packets are
	influenced by two phenomena:		influenced by two phenomena:
	o frequency drift of the local oscillator relative to the master		o frequency drift of the local oscillator relative to the master
	oscillator (typically caused by temperature and voltage		oscillator (typically caused by temperature and voltage
	fluctuations, and by aging phenomena)		fluctuations, and by aging phenomena)
	o variation in delay of timing packets through the packet network		o variation in delay of timing packets through the packet network
	(PDV).		(PDV).
	skipping to change at page 11, line 45		skipping to change at page 11, line 49
	The purpose of the time distribution protocol is to calibrate a		The purpose of the time distribution protocol is to calibrate a
	sequence of phase events generated by the local oscillator or digital		sequence of phase events generated by the local oscillator or digital
	synthesizer, thus converting arbitrary offset phase values into wall-		synthesizer, thus converting arbitrary offset phase values into wall-
	clock values. This is done by sending packets containing timestamps		clock values. This is done by sending packets containing timestamps
	from the master (where the time is known) to the TICTOC client. In		from the master (where the time is known) to the TICTOC client. In
	order for the timestamp to accurately indicate the time that the		order for the timestamp to accurately indicate the time that the
	packet was actually injected into the network (rather than some		packet was actually injected into the network (rather than some
	earlier time when the packet was formed, separated by a stochastic		earlier time when the packet was formed, separated by a stochastic
	time delay from the injection time), the timestamp should be		time delay from the injection time), the timestamp should be
	generated by the networking hardware. When this is not possible, the		generated by the networking hardware. Providing any checksums or
	stochastic delay should be minimized. The IEEE1588 protocol has a		CRCs can be updated on-the-fly, this hardware-generated timestamp may
	follow-up message, to indicate the actual injection time of the		be directly inserted into the packet. Alternatively, a subsequent
	previous packet.		packet can be used to carry the measured injection time, as in the
			PTP follow-up message. Where hardware assistance to measure the
			injection time accurately is not available, the stochastic delay
			should be minimized.
	The timestamp in the time distribution protocol packet indicates the		The timestamp in the time distribution protocol packet indicates the
	time that the master injected this packet into the network. On the		time that the master injected this packet into the network. On the
	other hand, the client receives this same packet after the		other hand, the client receives this same packet after the
	propagation delay, i.e. the time taken to traverse the packet		propagation delay, i.e. the time taken to traverse the packet
	network. Were this time to be accurately known, the timestamp could		network. Were this time to be accurately known, the timestamp could
	be corrected, and the precise time known. Estimation of the		be corrected, and the precise time known. Estimation of the
	traversal time is called ranging, and will be discussed below. The		traversal time is called ranging, and will be discussed below. PTP
	IEEE1588 protocol has an optional mechanism (transparent clocks)		has an optional mechanism (transparent clocks) whereby forwarding
	whereby forwarding delays, and even individual link delays are		delays, and even individual link delays are measured and compensated,
	measured and compensated, thus leading to precise knowledge of the		thus leading to precise knowledge of the traversal delay. However,
	traversal delay. However, this mechanism requires upgrading of all		this mechanism requires upgrading of all intermediate network
	intermediate network elements.		elements.
	Due to the requirement of traversal delay measurement, time		Due to the requirement of traversal delay measurement, time
	distribution protocols are generally bidirectional, that is, they		distribution protocols are generally bidirectional, that is, they
	require a bidirectional channel, require both master and client to		require a bidirectional channel, require both master and client to
	send and receive messages, and usually assume symmetric (or known		send and receive messages, and usually assume symmetric (or known
	asymmetry) propagation times. Unlike frequency distribution, time		asymmetry) propagation times. Unlike frequency distribution, time
	distribution can not be entirely multicast, due to the ranging		distribution can not be entirely multicast, due to the ranging
	requirement.		requirement.
	There are two well-known protocols capable of running over a general-		There are two well-known protocols capable of running over a general-
	purpose packet network, NTP [RFC1305], and IEEE1588 [IEEE1588]. NTP		purpose packet network, NTP [RFC1305], and PTP [IEEE1588]. NTP is
	is the product of the IETF, and is currently undergoing revision to		the product of the IETF, and is currently undergoing revision to
	version 4. IEEE1588 is a product of the IEEE Test and Measurement		version 4. PTP is a product of the IEEE Test and Measurement
	community, and has recently been revised to better accommodate		community, and has recently been revised to better accommodate
	telecommunication applications. The new version has a profiling		telecommunication applications. The new version has a profiling
	mechanism enabling organizations to specify required and prohibited		mechanism enabling organizations to specify required and prohibited
	options, ranges and defaults of attribute values, and optional		options, ranges and defaults of attribute values, and optional
	features, while maintaining interoperability.		features, while maintaining interoperability.
	The protocol used to transfer the reference frequency across the		The protocol used to transfer the reference frequency across the
	network may be the same protocol that is used to transfer time. The		network may be the same protocol that is used to transfer time. The
	overriding design consideration is that frequency and time		overriding design consideration is that frequency and time
	distribution protocols be optimised for their purpose, and not		distribution protocols be optimized for their purpose, and not
	compromised by the need to fulfill a dual role.		compromised by the need to fulfill a dual role.
	The TICTOC architecture itself is not bound to a specific time		The TICTOC architecture itself is not bound to a specific time
	distribution protocol. It is possible to upgrade, or replace this		distribution protocol. It is possible to upgrade, or replace this
	protocol, for example to improved the quality of the transfer, or to		protocol, for example to improved the quality of the transfer, or to
	optimize the transfer for a different network environment, without		optimize the transfer for a different network environment, without
	redesigning the entire TICTOC architecture.		redesigning the entire TICTOC architecture.
	3.2. Ranging		3.2. Ranging
	To transfer time it is necessary to know the time of flight of time		To transfer time it is necessary to know the time of flight of
	of packets from the time server to the client. The accuracy of time		packets from the time server to the client. The accuracy of time at
	at the client can be no better than the accuracy provide by the		the client can be no better than the accuracy provide by the ranging
	ranging mechanism. Some ranging mechanisms require or can exploit		mechanism. Some ranging mechanisms require or can exploit special
	special hardware assistance by intermediate network elements, such as		hardware assistance by intermediate network elements, such as PTP
	IEEE1588 transparent clocks [IEEE1588].		transparent clocks [IEEE1588].
	A typical ranging mechanism functions by exchanging timestamps		A typical ranging mechanism functions by exchanging timestamps
	between master and client. For example, the master sends an initial		between master and client. For example, the master sends an initial
	timestamped packet. When this packet arrives at the client its		timestamped packet. When this packet arrives at the client its
	arrival time (in terms of the local clock) is recorded. After some		arrival time (in terms of the local clock) is recorded. After some
	amount of time the client sends a response packet back to the master,		amount of time the client sends a response packet back to the master,
	containing the initial timestamp (in terms of the master clock), and		containing the initial timestamp (in terms of the master clock), and
	the packet arrival and retransmission times (in terms of the client		the packet arrival and retransmission times (in terms of the client
	clock). When this packet is received by the master a fourth		clock). When this packet is received by the master a fourth
	timestamp is generated (in terms of the master clock). Since the		timestamp is generated (in terms of the master clock). Since the
	skipping to change at page 13, line 33		skipping to change at page 13, line 42
	effect.		effect.
	Various variations on this basic four-timestamp method are possible.		Various variations on this basic four-timestamp method are possible.
	In the three timestamp method the client sends the time difference		In the three timestamp method the client sends the time difference
	(e.g., generated by resetting a timer upon packet arrival) rather		(e.g., generated by resetting a timer upon packet arrival) rather
	than the two timestamps. When symmetry is not a valid assumption,		than the two timestamps. When symmetry is not a valid assumption,
	additional information (e.g., ratio or difference between expected		additional information (e.g., ratio or difference between expected
	propagation delays) can be used to extract the one-way delay.		propagation delays) can be used to extract the one-way delay.
	Ranging accuracy is reduced by deviation from expected asymmetry in		Ranging accuracy is reduced by deviation from expected asymmetry in
	the network. Mechanisms to avoid asymmetry at the network layer (for		the network. Mechanisms to avoid asymmetry at the network layer are
	example using MPLS RSVP-TE paths, or the use of the peer-to-peer		useful (for example using MPLS RSVP-TE paths, or the use of the peer-
	mechanism described in IEEE1588v2 are useful, as is the ability to		to-peer mechanism described in IEEE1588), as is the ability to
	correct asymmetry in the physical connection through the use of		correct asymmetry in the physical connection through the use of
	external calibration.		external calibration.
	3.3. Time Presentation		3.3. Time Presentation
	In general, the output of the time acquisition module needs to be		In general, the output of the time acquisition module needs to be
	reformatted before use. Formatting includes translation between		reformatted before use. Formatting includes translation between
	different representations (e.g., from seconds after a given date to		different representations (e.g., from seconds after a given date to
	date and time), changing time zones, etc. When the time needs to be		date and time), changing time zones, etc. When the time needs to be
	displayed, e.g., on a computer or mobile device, further processing		displayed, e.g., on a computer or mobile device, further processing
	skipping to change at page 15, line 41		skipping to change at page 16, line 41
	configured to use a particular master, a client may be allowed to		configured to use a particular master, a client may be allowed to
	make independent decisions when the master becomes unavailable or		make independent decisions when the master becomes unavailable or
	sends synchronization status messages indicating a fault condition.		sends synchronization status messages indicating a fault condition.
	A second tactic is not to make a hard decision at all, but rather to		A second tactic is not to make a hard decision at all, but rather to
	perform weighted ensemble averaging of frequencies recovered from all		perform weighted ensemble averaging of frequencies recovered from all
	available masters. The weightings, once again, may be based on		available masters. The weightings, once again, may be based on
	claims made by the masters or by monitoring of frequency stability.		claims made by the masters or by monitoring of frequency stability.
	Using either tactic, it is important to ensure that "timing loops"		Using either tactic, it is important to ensure that "timing loops"
	are not formed. A timing loop is an erroneous topology that		are not formed. A timing loop is an erroneous topology that causes
	causeslocking onto frequencies not traceable to a high quality		locking onto frequencies not traceable to a high quality source.
	source. Loops are avoided by ensuring that the frequency distribution		Loops are avoided by ensuring that the frequency distribution paths
	paths form a tree.		form a tree.
	Yet another method is not to decide on a timing distribution tree at		Yet another method is not to decide on a timing distribution tree at
	all, but rather to enable self-organization of independently acting		all, but rather to enable self-organization of independently acting
	intelligent agents. In such cases the meaning of master and client		intelligent agents. In such cases the meaning of master and client
	becomes blurred, as all agents exchange timing information with a		becomes blurred, as all agents exchange timing information with a
	subset neighbors that have been discovered. This method may be		subset neighbors that have been discovered. This method may be
	driven by timing acquisition algorithms that guarantee global		driven by timing acquisition algorithms that guarantee global
	convergence of the timing agents, meaning that over time the average		convergence of the timing agents, meaning that over time the average
	timing error decreases, although a given agent's error may sometimes		timing error decreases, although a given agent's error may sometimes
	increase.		increase.
	skipping to change at page 17, line 24		skipping to change at page 18, line 24
	In infrastructure applications it may be possible for TICTOC devices		In infrastructure applications it may be possible for TICTOC devices
	to seek co-operation from routing elements to optimize the path		to seek co-operation from routing elements to optimize the path
	through the network in order to obtain a better quality of time and		through the network in order to obtain a better quality of time and
	frequency transfer that is possible when the timing distribution		frequency transfer that is possible when the timing distribution
	protocol operates independent of the network layer.		protocol operates independent of the network layer.
	At the simplest level this is use of paths that can support the		At the simplest level this is use of paths that can support the
	required quality of service, and have the lowest congestion impact.		required quality of service, and have the lowest congestion impact.
	However it is also possible for the network layer to be a proactive		However it is also possible for the network layer to be a proactive
	partner in the transfer process. For example paths may be selected		partner in the transfer process. For example paths may be selected
	that are explicitly chosen to be symmetric, or paths may be selected		on the basis of their symmetry, or such that all are capable of
	such that all are capable of supporting physical frequency transfer		supporting physical frequency transfer (for example Synchronous
	(for example synchronous Ethernet), or nodes may be selected such		Ethernet), or nodes may be selected such that they are all capable of
	that they are all capable of supporting transparent clock.		supporting transparent clock.
	In addition to having to deal with degradation of service due to		In addition to having to deal with degradation of service due to
	congestion, TICTOC must not add to the problem. Thus, TICTOC timing		congestion, TICTOC must not add to the problem. Thus, TICTOC timing
	distribution protocols MUST be able to act in a TCP friendly way,		distribution protocols MUST be able to act in a TCP friendly way,
	even at the expense of minor degradation of performance. In such		even at the expense of minor degradation of performance. In such
	cases, it may be required for the master to inform the client of the		cases, it may be required for client to be informed of the change in
	change in operating conditions.		operating conditions.
	5.2. Network and Traffic Engineering		5.2. Network and Traffic Engineering
	Every network element (e.g. router or switch) in a packet network		Every network element (e.g. router or switch) in a packet network
	adds varying amounts of delay to the packet. This variation is		adds varying amounts of delay to the packet. This variation is
	typically correlated to the load on that network element at the time,		typically correlated to the load on that network element at the time,
	and especially to the shared load on the output port.		and especially to the shared load on the output port.
	Therefore, there is some maximum limit on both the traffic load and		Therefore, there is some maximum limit on both the traffic load and
	the number of network elements that a packet timing flow can traverse		the number of network elements that a packet timing flow can traverse
	skipping to change at page 19, line 14		skipping to change at page 20, line 14
	take the same path in each direction. This in itself will not		take the same path in each direction. This in itself will not
	guarantee that the time delay is the same in each direction, but it		guarantee that the time delay is the same in each direction, but it
	should minimize any difference.		should minimize any difference.
	5.5. On-path Support		5.5. On-path Support
	The TICTOC architecture will be commensurate with the public		The TICTOC architecture will be commensurate with the public
	Internet, and the timing distribution protocol chosen will be able to		Internet, and the timing distribution protocol chosen will be able to
	function over general packet switched networks.		function over general packet switched networks.
	In some cases on-path support (for example IEEE1588 transparent		In some cases on-path support (for example PTP transparent clocks)
	clocks) may be needed in order to obtain the required frequency or		may be needed in order to obtain the required frequency or time
	time accuracy. Such on-path support cannot be expected to be		accuracy. Such on-path support cannot be expected to be universally
	universally available over the public Internet, and it is not a goal		available over the public Internet, and it is not a goal of the
	of the TICTOC working group to propose augmentation of basic		TICTOC working group to propose augmentation of basic forwarding
	forwarding elements. However, such on-path support may be provided		elements. However, such on-path support may be provided on service
	on service provider or enterprise networks, and in such cases TICTOC		provider or enterprise networks, and in such cases TICTOC protocols
	protocols should be able to exploit it.		should be able to exploit it.
	In networks with on-path support, it may be that the optimum path for		In networks with on-path support, it may be that the optimum path for
	time transfer is not congruent with the optimum path for data		time transfer is not congruent with the optimum path for data
	transfer. By using special-purpose IP addresses, and making routing		transfer. By using special-purpose IP addresses, and making routing
	aware of the required path characteristics and address attributes, it		aware of the required path characteristics and address attributes, it
	is possible to construct paths within the network that maintain the		is possible to construct paths within the network that maintain the
	required time transfer characteristics.		required time transfer characteristics.
	The TICTOC Working Group will specify the required path		The TICTOC Working Group will specify the required path
	characteristics and work with the ISIS and OSPF Working Groups to		characteristics and work with the ISIS and OSPF Working Groups to
	skipping to change at page 20, line 13		skipping to change at page 21, line 13
	Gabriel Zigelboim, and Laurent Montini for invaluable comments.		Gabriel Zigelboim, and Laurent Montini for invaluable comments.
	INFORMATIVE REFERENCES		INFORMATIVE REFERENCES
	[IEEE1588] IEEE, "Standard for A Precision Clock Synchronization		[IEEE1588] IEEE, "Standard for A Precision Clock Synchronization
	Protocol for Networked Measurement and Control		Protocol for Networked Measurement and Control
	Systems", IEEE1588-2008.		Systems", IEEE1588-2008.
	[G.8261] ITU-T, "Timing and Synchronization Aspects in Packet		[G.8261] ITU-T, "Timing and Synchronization Aspects in Packet
	[G.8262] ITU-T, "Timing characteristics of synchronous ethernet		[G.8262] ITU-T, "Timing characteristics of synchronous Ethernet
	equipment slave clock (EEC)", G.8262, August 2007		equipment slave clock (EEC)", G.8262, August 2007
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)		[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	Specification, Implementation", RFC 1305, March 1992.		Specification, Implementation", RFC 1305, March 1992.
	[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.
	[minTDEV] G. Zampetti and L. Cosart, "Definition of minTDEV",		[minTDEV] G. Zampetti and L. Cosart, "Definition of minTDEV",
	COM15-C363-E, Contribution to ITU-T Study Group 15,		COM15-C363-E, Contribution to ITU-T Study Group 15,
End of changes. 19 change blocks.
	71 lines changed or deleted		77 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/