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/