draft-stein-tictoc-modules-01.txt   draft-stein-tictoc-modules-02.txt 
TICTOC Tim Frost
INTERNET-DRAFT Greg Dowd
Intended Status: Informational Symmetricom
TICTOC Y(J). Stein Karen O'Donoghue
Internet-Draft RAD Data Communications
Intended status: Informational S. Bryant
Expires: October 11, 2008 Cisco Systems
K. O'Donoghue
US Navy US Navy
April 9, 2008 Architecture for the Transmission of Timing over Packet Networks
draft-stein-tictoc-modules-02.txt
TICTOC Modules
draft-stein-tictoc-modules-01.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 applicable patent or other IPR claims of which he or she is aware have
have been or will be disclosed, and any of which he or she becomes been or will be disclosed, and any of which he or she becomes aware will
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 Internet-Drafts are working documents of the Internet Engineering Task
Task Force (IETF), its areas, and its working groups. Note that Force (IETF), its areas, and its working groups. Note that other groups
other groups may also distribute working documents as Internet- may also distribute working documents as Internet-Drafts.
Drafts.
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
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/ietf/1id-abstracts.txt. 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 October 11, 2008. This Internet-Draft will expire on January 14, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008)
Abstract Abstract
This Internet draft proposes the modularization of TICTOC This Internet draft proposes an architecture for the transmission of
(Transmitting Timing over IP Connections and Transfer of Clock) work. timing over packet networks. It identifies the major functional
In particular, it breaks the work down into individual modules components, and maps the current solutions onto this framework.
(deliverables) that need to be developed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction 3
2. Frequency Layer . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. TICTOC Layers 3
2.1. Local Oscillator and Digital Synthesizers . . . . . . . . 5 1.2. Generic TICTOC Client 4
2.2. Frequency Distribution Protocols . . . . . . . . . . . . . 6 1.3. TICTOC Functional Modules 5
2.3. Packet Select/Discard Algorithms . . . . . . . . . . . . . 7 2. Frequency Layer 7
2.4. Frequency Acquisition Algorithms . . . . . . . . . . . . . 8 2.1. Local Oscillator and Frequency Synthesizers 7
2.5. Frequency Presentation . . . . . . . . . . . . . . . . . . 9 2.2. Frequency Distribution Protocols 8
3. Time Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Frequency Acquisition Algorithms 8
3.1. Time Distribution Protocols . . . . . . . . . . . . . . . 9 2.3.1. Packet Selection and Discard Algorithms 9
3.2. Ranging . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2. Filtering and Control Servos 9
3.3. Time Presentation . . . . . . . . . . . . . . . . . . . . 12 2.3.3. Server Contribution 10
4. Other Modules . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.4. Reference Algorithm 10
4.1. Security Mechanisms . . . . . . . . . . . . . . . . . . . 12 2.4. Frequency Presentation 10
4.2. Autodiscovery and Master Clock Selection . . . . . . . . . 13 3. Time Layer 11
4.3. OAM, SSM, and Performance Monitoring . . . . . . . . . . . 14 3.1. Time Distribution Protocols 11
4.4. Path Selection . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Ranging 12
4.5. On-path Support . . . . . . . . . . . . . . . . . . . . . 15 3.3. Time Presentation 13
4.6. Network Management . . . . . . . . . . . . . . . . . . . . 16 4. Generic Modules 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4.1. Security Mechanisms 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4.2. Autodiscovery and Master Clock Selection 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Redundancy and Fail-Over Mechanisms 16
8. Informative References . . . . . . . . . . . . . . . . . . . . 16 4.4. OAM, SSM, and Performance Monitoring 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5. Network Management 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18 4.6. Application profiles 16
[Editor's Note: The present version of this draft contains references 5. Network Support 17
to work to be performed by the TICTOC working group. This language 5.1. Path Selection 17
has been included in order to help with the chartering of this 5.2. Network and Traffic Engineering 17
working group, and will be removed in the next revision.] 5.3. Service Level Specifications and QoS settings 18
5.4. Routing considerations 18
5.5. On-path Support 19
6. Security Considerations 19
7. IANA Considerations 19
8. Acknowledgements 19
INFORMATIVE REFERENCES 20
AUTHORS' ADDRESSES 20
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 In this document the term "timing" will be used to refer to recovery of
of frequency and/or time (wall-clock). frequency and/or time (wall-clock).
There is an emerging need to distribute highly accurate time and
frequency information over IP and over MPLS packet switched networks
(PSNs). A variety of applications require time and/or frequency
information to a precision which existing protocols cannot supply.
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
Network Time Protocol [RFC1305]. The IEEE has recently revised its
Precision Time Protocol [IEEE1588]. The ITU-T has defined Synchronous
Ethernet, a physical layer technology for transfer of frequency across
native Ethernet [G.8261, G.8262].
However, none of these efforts are sufficient by themselves to create a
complete and robust time and frequency transfer ecosystem in the IP and
MPLS network environment. The TICTOC (Timing over IP Connections and
Transmission of Clock) Working Group was created to develop solutions
that meet the needs of the various applications for timing over packet
networks.
This draft attempts to define an architecture for a TICTOC system,
identifying the various functional components, and considering the
support required from the network in order to assist the timing
recovery.
1.1. TICTOC Layers
The most general TICTOC system can be logically decomposed into two The most general TICTOC system can be logically decomposed into two
layers, corresponding to the distribution and presentation of layers, corresponding to the distribution of frequency and time,
frequency and time, respectively, In Figure 1 we depict these layers, respectively, carried over the network by a timing protocol as shown
and the top-level modules in these layers, for a TICTOC client. in Figure 1. Examples of such timing protocols include Network Time
Protocol (NTP) [RFC1305] and Precision Time Protocol (PTP)
[IEEE1588].
Specific TICTOC systems may consist of either or both layers. For Specific TICTOC systems may consist of either or both layers. For
example, if time is required but frequency is available from a example, if time is not required for the application, then only the
physical layer mechanism, then the frequency layer is omitted. On frequency layer may be present.
the other hand, if time is not required for the application, then
only the frequency layer may be present. In some cases there may be additional support from the network to
assist the timing distribution. For example, it may be possible to
use a physical layer technology such as Synchronous Ethernet to
distribute an accurate frequency. In this case, the timing protocol
is only required to distribute time. Other examples of network
support may include specific QoS settings for the timing protocol
flow, and routing constraints to ensure an optimum path.
|-------------------| |-------------------|
| Time distribution | | Time distribution |
|-------------------| |-------------------|
| Frequency distr. | | Frequency distr. |
|-------------------| |-------------------|
| Timing protocol | | Timing Protocol |
|-------------------| |-------------------|
| UDP | | UDP |
|-------------------| |-------------------|
| IP | | IP |
|-------------------| |-------------------|
| Layer 2 | | Layer 2 |
|-------------------| |-------------------|
| Layer 1 | | Layer 1 |
|-------------------| |-------------------|
| ---------- |
| / \ |
-------------| Network |-------------
\ /
\---------/
Figure 1. TICTOC Layers
1.2. Generic TICTOC Client
Figure 2 shows a generic TICTOC client, consisting of separate
frequency and time acquisition modules, and the presentation modules
for each.
Network Network
| |
v v
+------+-------+ +--------------+ +------+-------+ +--------------+
| Frequency | | Frequency | | Frequency | | Frequency |
| Acquisition +------)-------+ Presentation +-----)------ | Acquisition +----->-----+ Presentation +----->-----
| | | | | | | |
+------+-------+ +--------------+ +------+-------+ +--------------+
| |
v v
| |
+------+-------+ +--------------+ +------+-------+ +--------------+
| Time | | Time | | Time | | Time |
| Acquisition +------)-------+ Presentation +-----)------ | Acquisition +----->-----+ Presentation +----->-----
| | | | | | | |
+--------------+ +--------------+ +--------------+ +--------------+
Figure 1. Generic TICTOC client Figure 2. Generic TICTOC client
Referring to Figure 1, the frequency acquisition module is The frequency acquisition module is responsible for recovery of
responsible for recovery of frequency information distributed over a frequency information distributed over a packet switched network
packet switched network (PSN), such as IP or MPLS. This distribution (PSN), such as IP or MPLS. This distribution is accomplished by use
is accomplished by use of a frequency distribution protocol. The of a frequency distribution protocol. The frequency distributed may
frequency distributed may be derived from an international standard, be derived from an international standard, or may be an arbitrary
or may be an arbitrary frequency needed at some remote location. If frequency needed at some remote location. If the value of the
the value of the frequency itself is needed, then the output of this frequency itself is needed, then the output of this module is input
module is input to the frequency presentation module that formats the to the frequency presentation module that formats the frequency
frequency according to application needs. Note that this format may according to application needs. Note that this format may be numeric
be numeric prepared for display, or may take analog form and be used prepared for display, or may take analog form and be used for locking
for locking or disciplining other analog frequencies. When time is or disciplining other analog frequencies. When time is needed, the
needed, the frequency information is sent to the time acquisition frequency information is sent to the time acquisition module.
module.
Even if the frequency itself is not needed, time acquisition almost Even if the frequency itself is not needed, time acquisition almost
always requires a stable frequency reference. This reference may be always requires a stable frequency reference. This reference may be
acquired from the frequency acquisition layer, or may be obtained via acquired from the frequency acquisition layer, or may be obtained via
some other means, such as an accurate local frequency reference, or some other means, such as an accurate local frequency reference, or
from a non-PSN mechanism for frequency distribution (e.g., GPS, from a non-PSN mechanism for frequency distribution (e.g., GPS,
SONET/SDH). SONET/SDH).
From the acquired or otherwise available frequency, we may derive From the acquired or otherwise available frequency, we may derive
arbitrary time (also known as "phase") by mathematical means. If the arbitrary time (also known as "phase") by mathematical means. If the
skipping to change at page 4, line 39 skipping to change at page 5, line 40
certain applications, such as where multiple time-aware agents need certain applications, such as where multiple time-aware agents need
to interact (e.g., systems employing Time Division Multiple Access to interact (e.g., systems employing Time Division Multiple Access
systems). systems).
When the time markings distributed by the time distribution protocol When the time markings distributed by the time distribution protocol
are traceable to an international standard, the TICTOC clients are are traceable to an international standard, the TICTOC clients are
said to have acquired wall-clock time. These wall-clock values are said to have acquired wall-clock time. These wall-clock values are
formatted for use by the intended application by the time formatted for use by the intended application by the time
presentation module. presentation module.
The remainder of this document further subdivides these modules and 1.3. TICTOC Functional Modules
identifies the submodules needed for timing distribution. Submodule
may require one or more protocols, a set of processing algorithms,
and implementations. Descriptions of these protocols, algorithms,
and reference implementations are the TICTOC deliverables.
The remainder of this document further subdivides these modules and
identifies the sub-modules needed for timing distribution. Sub-
modules may require one or more protocols, a set of processing
algorithms, and implementations.
The frequency acquisition module may be subdivided into the following The frequency acquisition module may be subdivided into the following
submodules. Not all need to be present in all implementations. sub-modules. Not all need to be present in all implementations.
Those that need not be developed by TICTOC are marked by an asterisk. o local oscillator
o local oscillator (*) o frequency generator (typically a digital synthesizer)
o digital synthesizer (*) o timestamp generator
o timestamp generation (not required if packets are sent at constant (not required if packets are sent at constant rate)
rate)
o frequency distribution protocol o frequency distribution protocol
o packet selection/discard algorithms
o frequency acquisition algorithms o frequency acquisition algorithms
o disciplining/adaptation/clock adjustment (may include packet selection algorithms, oscillator
disciplining and frequency adjustment techniques)
The time acquisition module may be subdivided into the following The time acquisition module may be subdivided into the following
submodules. Not all need to be present in all implementations. additional sub-modules. Not all need to be present in all
implementations.
o time distribution protocol o time distribution protocol
o ranging o ranging algorithms
o clock adjustment techniques
o timestamp generation (already mentioned) o timestamp generation (already mentioned)
In addition, various generic modules may be needed, for either In addition, various generic modules may be needed, for either
frequency distribution, time distribution, or both. frequency distribution, time distribution, or both.
o security o security
o autodiscovery and master clock selection o autodiscovery and master clock selection
o OAM, synchronization status messaging, and performance monitoring o redundancy and fail-over mechanisms
o path selection and/or self-organization o OAM, synchronization status messaging, and performance
o on-path support monitoring
o network management o network management
o application profiles
Any timing protocols should operate over the general internet without
requiring specific support from the network. However, when operated
over a specific, managed network where support is available, the
accuracy of the time and frequency distribution will be enhanced.
Examples of network support include:
o path selection and/or self-organization
o network and traffic engineering for optimum transport of timing
protocols
o service level specifications and QoS settings
o routing considerations
o on-path support, e.g. PTP boundary or transparent clocks
2. Frequency Layer 2. Frequency Layer
There are applications that require an accurate frequency reference, There are applications that require an accurate frequency reference, but
but do not require knowledge of absolute time. In addition, it is do not require knowledge of absolute time. In addition, it is often
often wise to acquire frequency for applications that require wise to acquire frequency for applications that require absolute time
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 [G8262]). 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 achievable using packet based network frequency transfer, but is outside
outside the scope of this document. the scope of this document.
2.1. Local Oscillator and Digital 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
a better clock (e.g., by GPS). Note that a pure frequency master a better clock (e.g., by GPS).
that does not need to know time can be standalone.
Note that a pure frequency master that does not need to know time can
be standalone.
For clients, the local oscillator is usually a quartz crystal For clients, the local oscillator is usually a quartz crystal
oscillators. Such oscillators may be stable, special cut crystals oscillators. Such oscillators may be stable, special cut crystals
with double oven and temperature compensation, or lowly inexpensive with double oven and temperature compensation, or lowly inexpensive
crystals. In either case the frequency derived from these crystals. In either case the frequency derived from these
oscillators needs to be adjusted by the TICTOC frequency acquisition oscillators needs to be adjusted by the TICTOC frequency acquisition
module. This adjustment can be electronic (e.g., changing the module. This adjustment can be electronic (e.g. changing the control
control voltage of a voltage controlled oscillator). voltage of a voltage controlled oscillator).
However, it is common practice not to directly adjust the physical However, it is common practice not to directly adjust the physical
oscillator, or even to directly use the oscillator's frequency. oscillator, or even to directly use the oscillator's frequency.
Instead, a digital synthesizer fed by the oscillator provides the Instead, a digital synthesizer fed by the oscillator provides the
required output frequency. Changing parameters of the digital required output frequency. Changing parameters of the digital
synthesizer changes the output frequency in the required way. It is synthesizer changes the output frequency in the required way. It is
important for the digital synthesizer not to introduce too much important for the digital synthesizer not to introduce too much
jitter, and for the changing of parameters to be done in such fashion jitter, and for the changing of parameters to be done in such fashion
as to minimize transients. as to minimize transients.
skipping to change at page 7, line 6 skipping to change at page 8, line 31
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, while
unicast transmission is often more desirable. unicast transmission is often more desirable.
Ideally the frequency distribution protocol should be decoupled from The TICTOC architecture is modular, and not bound to the frequency
the algorithm used to derive the local reference frequency, and the distribution protocol. It is possible to use different frequency
packets sent should only contain information that is physically distribution methods for different applications and environments,
meaningful without reference to a particular algorithm. For example, e.g. the use of physical layer frequency distribution protocols such
if the master sends packets at a constant rate as measured by the as Synchronous Ethernet.
frequency reference, then the existence of the packet itself is the
only physically meaningful information, and the packet should contain
nothing but headers required for packet delivery. If the packets are
not sent at a constant rate, they should contain nothing but a
sufficiently precise timestamp. The use of extension mechanisms for
carrying additional information may be considered for specific cases.
The TICTOC Working Group will select a suitable network frequency 2.3. Frequency Acquisition Algorithms
transfer protocol. This may be based on an existing protocol,
although that is not to be considered a requirement.
The basic TICTOC architecture itself should not be strongly bound to A TICTOC client needs to be able to recover the original timebase (or
the frequency distribution protocol. It should be possible to frequency reference) of the master or server. In general it achieves
upgrade or completely replace this protocol (e.g., to improve this by comparing the arrival rate of packets with the original
accuracy), or to optimize the transfer for a different network sending rate. From this it can determine the relationship between the
environment, without redesigning the TICTOC architecture. local timebase and the master timebase.
2.3. Packet Select/Discard Algorithms Observed arrival times of frequency distribution protocol packets are
influenced by two phenomena:
o frequency drift of the local oscillator relative to the master
oscillator (typically caused by temperature and voltage
fluctuations, and by aging phenomena)
o variation in delay of timing packets through the packet network
(PDV).
In the simplest networks all frequency distribution packets received The former behavior needs to be tracked and compensated, while the
are used by the frequency acquisition algorithms to derive latter needs to be filtered out. In order to eliminate the effects
corrections to the local oscillator. A major problem with frequency of PDV, frequency acquisition algorithms perform some sort of
acquisition in complex networks is the elimination of frequency averaging and/or filtering, in an attempt to recover the frequency at
distribution packets that, if used by the acquisition algorithms, which packets were sent. Typically this involves two steps:
would degrade the quality of the recovered frequency. Such packets o packet selection and discard algorithms
are variously called outliers, falsetickers, etc. o filtering and control servos to "lock onto" the sending
frequency
2.3.1. Packet Selection and Discard Algorithms
In the simplest networks all frequency distribution packets
received are used by the frequency acquisition algorithms to
derive corrections to the local oscillator. A major problem with
frequency acquisition in complex networks is the elimination of
frequency distribution packets that, if used by the acquisition
algorithms, would degrade the quality of the recovered frequency.
Such packets are variously called outliers, falsetickers, etc.
There are several reasons for such unreliable packets. First, There are several reasons for such unreliable packets. First,
malfeasants may deliberately inject false packets in order to impair malfeasants may deliberately inject false packets in order to
the TICTOC client's frequency recovery. We will discuss security impair the TICTOC client's frequency recovery. We will discuss
mechanisms below. Second, PDV distributions for complex networks can security mechanisms below. Second, PDV distributions for complex
be long tailed, leading to extremely misleading results. Third, networks can be long tailed, leading to extremely misleading
various network degradations, e.g., congestion and reroute events, results. Third, various network degradations, e.g., congestion
can lead to bizarre information being received. and reroute events, can lead to bizarre information being
received.
Furthermore, even typical packets may have experienced significant Furthermore, even typical packets may have experienced significant
delay variation, making them less suitable for exploitation than the delay variation, making them less suitable for exploitation than
small fraction of packets that may have experienced almost no delay the small fraction of packets that may have experienced almost no
(and thus minimal delay variation). When there is a significant delay (and thus minimal delay variation). When there is a
fraction of packets that experience essentially no delay, it is significant fraction of packets that experience essentially no
reasonable to discard all others (assuming that after this decimation delay, it is reasonable to discard all others (assuming that after
the sampling rate is still sufficiently high). this decimation the sampling rate is still sufficiently high).
2.4. Frequency Acquisition Algorithms 2.3.2. Filtering and Control Servos
Observed arrival times of frequency distribution protocol packets are Since simple averaging would take too long to sufficiently
influenced by two phenomena: time behavior of the local oscillator as eliminate the stochastic components, by which time the frequency
compared to the master oscillator, and network delay behavior (PDV). difference between local oscillator and master oscillator would
The former behavior needs to be tracked, while the latter needs to be have changed, more efficient "control loops" are employed.
filtered out. In order to eliminate the effects of PDV, frequency
acquisition algorithms perform some sort of averaging and/or
filtering, in an attempt to recover the frequency at which packets
were sent. Since simple averaging would take too long to
sufficiently eliminate the stochastic components, by which time the
frequency difference between local oscillator and master oscillator
would have changed, more efficient "control loops" are employed.
Control loops are nonlinear mechanisms, and are thus able to "lock Control loops are nonlinear mechanisms, and are thus able to "lock
onto" frequencies, rather than simply removing stochastic noise. onto" frequencies, rather than simply removing stochastic noise.
Conventional control loops include the Phase Locked Loop (PLLs), the Conventional control loops include the Phase Locked Loop (PLLs),
Frequency Locked Loops (FLL), and combinations of the two. the Frequency Locked Loops (FLL), and combinations of the two.
Delay variation effects can be quite complex and traffic dependent. Delay variation effects can be quite complex and traffic
There are obvious effects such as queuing indeterminacy leading to dependent. There are obvious effects such as queuing indeterminacy
stochastic PDV, and congestion leading to packet loss. There are leading to stochastic PDV, and congestion leading to packet loss.
also more subtle effects, for example multiple plesiochronous flows
(e.g. TDM pseudowires) traversing forwarding elements can cause slow There are also more subtle effects, for example multiple
"beating" effects, generating low frequency wander that is difficult plesiochronous flows (e.g. TDM pseudowires) traversing forwarding
to eliminate. Another example is the batch processing effect elements can cause slow "beating" effects, generating low
introduced by some forwarders in which the first of a series of frequency wander that is difficult to eliminate. Another example
packets experiences greater latency that later packets. is the batch processing effect introduced by some forwarders in
which the first of a series of packets experiences greater latency
that later packets.
Modern algorithms attempt to model the time behavior of local Modern algorithms attempt to model the time behavior of local
oscillator as compared to the master oscillator, and/or the network oscillator as compared to the master oscillator, and/or the
behavior. More complex algorithms may attempt blind separation of network behavior. More complex algorithms may attempt blind
the contribution of the two effects. separation of the contribution of the two effects.
Traditionally the focus on frequency acquisition algorithm design has 2.3.3. Server Contribution
been on the client. However it is possible to mitigate some of the
aforementioned effects by modulating the packet generation rate of
the master. Thus TICTOC algorithm modules may describe the client
and the server components, and may require matching of these
algorithms to achieve optimal performance.
Frequency acquisition algorithms need to be optimized such that Traditionally the focus on frequency acquisition algorithm design
network bandwidth consumed by the frequency distribution protocol is has been on the client. However it is possible to mitigate some
minimized. Furthermore, these algorithms are required to be robust of the aforementioned effects by modulating the packet generation
to network degradations such as packet delay, packet loss, packet rate of the master. Thus TICTOC algorithm modules may describe
delay variation (PDV) and infrequent stepwise changes in network the client and the server components, and may require matching of
traversal latencies (e.g., due to reroute events or network loading these algorithms to achieve optimal performance.
changes).
The TICTOC Working Group may specify a reference algorithm, but the 2.3.4. Reference Algorithm
TICTOC architecture will enable vendors to employ proprietary
algorithms. It will also be possible to upgrade the reference
algorithm in the future.
2.5. Frequency Presentation Current technologies differ in how much of the algorithm is
defined. NTP defines the clock recovery algorithm completely,
while PTP only defines the on-the-wire protocol, leaving the clock
recovery algorithms undefined. Ultimately, multiple algorithms
may be required to suit different network environments and
application requirements.
Next-generation frequency acquisition algorithms need to be
optimized such that network bandwidth consumed by the frequency
distribution protocol is minimized. Furthermore, these algorithms
are required to be robust to network degradations such as packet
delay, packet loss, packet delay variation (PDV) and infrequent
stepwise changes in network traversal latencies (e.g., due to
reroute events or network loading changes).
It may be necessary to specify a reference algorithm for
comparison and validation purposes, but the TICTOC architecture
will enable vendors to employ proprietary algorithms. It will
also be possible to upgrade the reference algorithm in the future.
2.4. Frequency Presentation
In general, the output of the frequency acquisition module needs to In general, the output of the frequency acquisition module needs to
be reformatted before use. In some cases the reference frequency be reformatted before use. In some cases the reference frequency
distributed across the network is different from the frequency needed distributed across the network is different from the frequency needed
by the local application; in such cases a digital synthesizer can be by the local application; in such cases a digital synthesizer can be
employed to convert the acquired frequency to the desired one. employed to convert the acquired frequency to the desired one.
Sometimes it is not frequency itself that is required, but a sequence Sometimes it is not frequency itself that is required, but a sequence
of equally separated times; in such cases the sequence of time of equally separated times; in such cases the sequence of time
"ticks" is generated from the acquired frequency (once again, a "ticks" is generated from the acquired frequency (once again, digital
digital synthesizer is ideal for this). synthesizer is ideal for this).
3. Time Layer 3. Time Layer
In general the time layer is fed accurate frequency from the In general the time layer is fed accurate frequency from the frequency
frequency layer. There are applications that require accurate time, layer. There are applications that require accurate time, but do not
but do not need to acquire frequency over the PSN. For example: need to acquire frequency over the PSN. For example:
o if the update rate is high and the time resolution required is low o if the update rate is high and the time resolution required
is low
o if highly accurate frequency is available locally o if highly accurate frequency is available locally
o if frequency is distributed by means external to the PSN (e.g. o if frequency is distributed by means external to the PSN
GPS, LORAN, WWV) (e.g. GPS, LORAN, WWV)
o if frequency is available by means of the network physical layer o if frequency is available by means of the network physical
(e.g. PoS, SyncE). layer (e.g. PoS, SyncE).
In such cases the frequency input in Figure 1 is provided by the
alternative frequency source, rather than the frequency layer.
The TICTOC two layer decomposition is a conceptual one, and may not In such cases the frequency input in Figure 2 is provided by the
be easily identifiable in all implementations. For example, when alternative frequency source, rather than the frequency layer. The
using a pure PLL frequency acquisition module, true "frequency" is TICTOC two layer decomposition is a conceptual one, and may not be
never derived, only relative phase. Similarly, tracking mechanisms easily identifiable in all implementations. For example, when using a
may simultaneously model frequency and time, reducing convergence pure PLL frequency acquisition module, true "frequency" is never
time by adjusting both simultaneously, rather than first acquiring derived, only relative phase. Similarly, tracking mechanisms may
frequency, and afterwards time. However, even in these cases the simultaneously model frequency and time, reducing convergence time by
decomposition is a useful one. adjusting both simultaneously, rather than first acquiring frequency,
and afterwards time. However, even in these cases the decomposition is
a useful one.
3.1. Time Distribution Protocols 3.1. Time Distribution Protocols
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
skipping to change at page 10, line 37 skipping to change at page 12, line 23
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 IEEE 1588 [1588]. NTP is purpose packet network, NTP [RFC1305], and IEEE1588 [IEEE1588]. NTP
the product of the IETF, and is currently undergoing revision to is the product of the IETF, and is currently undergoing revision to
version 4. IEEE 1588 is a product of the IEEE Test and Measurement version 4. IEEE 1588 is a product of the IEEE Test and Measurement
community. It is presently specified in a limited first version, community, and has recently been revised to better accommodate
while the second version (1588v2) is soon to be a standard. IEEE telecommunication applications. The new version has a profiling
1588v2 has a profiling mechanism enabling organizations to specify mechanism enabling organizations to specify required and prohibited
required and prohibited options, ranges and defaults of attribute options, ranges and defaults of attribute values, and optional
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 optimised 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 Working Group will select a suitable time distribution The TICTOC architecture itself is not bound to a specific time
transfer protocol or protocols. There are three options here: distribution protocol. It is possible to upgrade, or replace this
o a new or alternative version of NTP, to be called NTPv5 protocol, for example to improved the quality of the transfer, or to
o a profile of 1588 optimize the transfer for a different network environment, without
o a completely new protocol. redesigning the entire TICTOC architecture.
The selection will be made by producing a set of specific
requirements for the TICTOC timing distribution protocol, and by a
disinterested evaluation of each of these options in light of these
requirements. The requirements will be based on the applications
listed in the TICTOC problem statement. If neither of the first two
options fulfill the requirements, then the third option will be
chosen. Even if the first two options equally fulfill the
requirements one of them will be chosen as the mandatory protocol,
and the use of the other will be permissible under specific
circumstances.
The TICTOC architecture itself should not be bound to the specific
time distribution protocol. It should be possible to upgrade, or
replace this protocol, for example to improved the quality of the
transfer, or to optimize the transfer for a different network
environment, without 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 time
of packets from the time server to the client. The accuracy of time of packets from the time server to the client. The accuracy of time
at the client can be no better than the accuracy provide by the at the client can be no better than the accuracy provide by the
ranging mechanism. Some ranging mechanisms require or can exploit ranging mechanism. Some ranging mechanisms require or can exploit
special hardware assistance by intermediate network elements, such as special hardware assistance by intermediate network elements, such as
IEEE 1588 transparent clocks [1588] . 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 12, line 32 skipping to change at page 14, line 5
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
is often required, such as identification of day of week, translation is often required, such as identification of day of week, translation
to other calendars (e.g., Hebrew, Islamic, Chinese), conversion to other calendars (e.g., Hebrew, Islamic, Chinese), conversion
between TAI and UTC, and flagging of holidays and special dates. between TAI and UTC, and flagging of holidays and special dates.
4. Other Modules 4. Generic Modules
4.1. Security Mechanisms 4.1. Security Mechanisms
Time and frequency services are a significant element of network Time and frequency services are a significant element of network
infrastructure, and are critical for certain emerging applications. infrastructure, and are critical for certain emerging applications.
Hence time and frequency transfer services MUST be protected from Hence time and frequency transfer services MUST be protected from
being compromised. The most significant threats are false timing being compromised. The most significant threats are false timing
servers distributing purposely misleading timing packets, and man in servers distributing purposely misleading timing packets, and man in
the middle tampering with valid timing packets. Both threats would the middle tampering with valid timing packets. Both threats would
enable a malfeasant to mislead TICTOC clients, and to bring down enable a malfeasant to mislead TICTOC clients, and to bring down
critical services. critical services.
Based on the aforementioned threats, one can conclude that Based on the aforementioned threats, one can conclude that
confidentiality and replay protection are usually not needed (and in confidentiality and replay protection are usually not needed (and in
many cases not possible), but source authentication and integrity many cases not possible), but source authentication and integrity
protection are vital. In general, it is the master that needs to be protection are vital. In general, it is the master that needs to be
authenticated to the server, although in certain cases it may be authenticated to the server, although in certain cases it may be
needed to authenticate the client to the master. Applying IPsec needed to authenticate the client to the master.
Authentication Header (AH) mechanisms to all timing packets is not
feasible, due to the computational resources consumed by public key
cryptography algorithms. Adoption of IPsec would impact time
acquisition accuracy, and would lead to new methods for malfeasants
to disrupt the timing distribution protocols by exhausting resources
and denial of service from TICTOC clients. Furthermore, certificates
used to authenticate packets have lifetimes that must be enforced for
secure use. Certification of time packets themselves can thus lead
to circular dependence and to attacks that invalidate valid time
packets and substitute invalid ones.
NTP implementations provided an authentication protocol called Applying IPsec Authentication Header (AH) mechanisms to all timing
Autokey. Autokey utilizes public key algorithms to encrypt cookies, packets is not feasible, due to the computational resources consumed
symmetric key message digests for integrity, and digital signatures by public key cryptography algorithms. Adoption of IPsec would
for source authentication. impact time acquisition accuracy, and would lead to new methods for
malfeasants to disrupt the timing distribution protocols by
exhausting resources and denial of service from TICTOC clients.
Furthermore, certificates used to authenticate packets have lifetimes
that must be enforced for secure use. Certification of time packets
themselves can thus lead to circular dependence and to attacks that
invalidate valid time packets and substitute invalid ones. NTP
implementations provided an authentication protocol called Autokey.
Autokey utilizes public key algorithms to encrypt cookies, symmetric
key message digests for integrity, and digital signatures for source
authentication.
Any security mechanism must be designed in such a way that it does Any security mechanism must be designed in such a way that it does
not degrade the quality of the time transfer. Such a mechanism not degrade the quality of the time transfer. Such a mechanism
SHOULD also be relatively lightweight, as client restrictions often SHOULD also be relatively lightweight, as client restrictions often
dictate a low processing and memory footprint, and because the server dictate a low processing and memory footprint, and because the server
may have extensive fan-out. The mechanism also SHOULD not require may have extensive fan-out. The mechanism also SHOULD not require
excessive storage of client state in the master, nor significantly excessive storage of client state in the master, nor significantly
increase bandwidth consumption. increase bandwidth consumption.
4.2. Autodiscovery and Master Clock Selection 4.2. Autodiscovery and Master Clock Selection
skipping to change at page 13, line 40 skipping to change at page 15, line 9
The topology of presently deployed synchronization networks is The topology of presently deployed synchronization networks is
universally manually configured. This requires manual or management- universally manually configured. This requires manual or management-
plane configuration of master-client relationships, as well as plane configuration of master-client relationships, as well as
preconfigured fallback behaviors. This strategy is workable for SDH preconfigured fallback behaviors. This strategy is workable for SDH
networks, where there are a relatively small number of network networks, where there are a relatively small number of network
elements that require such configuration, and all elements are elements that require such configuration, and all elements are
controlled by a single entity. In packet switched network scenarios controlled by a single entity. In packet switched network scenarios
there may be a very large number of independent network elements there may be a very large number of independent network elements
requiring timing, making automatic mechanisms important. Such requiring timing, making automatic mechanisms important. Such
autodiscovery, automatic master selection algorithms, and perhaps autodiscovery, automatic master selection algorithms, and perhaps
control plane protocols to support these features, are an important control plane protocols to support these features, are important
TICTOC deliverable. features of the TICTOC architecture.
There are application scenarios where it is desirable for clocks to There are application scenarios where it is desirable for clocks to
advertise their service, and for clients to automatically select a advertise their service, and for clients to automatically select a
clock with the required accuracy and path characteristics. The clock with the required accuracy and path characteristics. The
optimum advertising method may depend on the environment and the optimum advertising method may depend on the environment and the
application. For example a host may be best served by finding a application. For example a host may be best served by finding a
suitable clock (or set of clocks) through a DHCP parameter, whist a suitable clock (or set of clocks) through a DHCP parameter, whist a
provider edge may find it more convenient to discover the available provider edge may find it more convenient to discover the available
clock through BGP. clock through BGP.
The TICTOC Working Group will specify the required clock
characteristics and identify the set of clock and client
characteristics and the application characteristics that influence
the optimum method of clock discovery. It will then specify one or
more methods of clock autodiscovery together with associated
applicability information.
Once a TICTOC client has discovered potential TICTOC masters, it must Once a TICTOC client has discovered potential TICTOC masters, it must
choose how to derive its clock from one or more of them. This choice choose how to derive its clock from one or more of them. This choice
can be aided using two types of information: can be aided using two types of information:
o claims made by the potential masters as to the accuracy of its o claims made by the potential masters as to the accuracy of its
local clock (see OAM and SSM below) local clock (see OAM and SSM below)
o analysis of the stability of frequency recovered from the o analysis of the stability of frequency recovered from the
potential masters. potential masters.
One tactic that a TICTOC client may employ is to individually choose One tactic that a TICTOC client may employ is to individually choose
which master to use based on this information. Even if statically which master to use based on this information. Even if statically
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.
skipping to change at page 14, line 31 skipping to change at page 15, 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 causes are not formed. A timing loop is an erroneous topology that
locking onto frequencies not traceable to a high quality source. causeslocking onto frequencies not traceable to a high quality
Loops are avoided by ensuring that the frequency distribution paths source. Loops are avoided by ensuring that the frequency distribution
form a tree. paths 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.
4.3. OAM, SSM, and Performance Monitoring 4.3. Redundancy and Fail-Over Mechanisms
Since synchronization is a critical function in many network
applications, operators conventionally protect it from single points
of failure. Redundant sources of synchronization are normally
provisioned, connected via diverse paths to prevent loss of
synchronization at the end station.
This is also required in packet synchronization. It may be necessary
to provision alternative paths, or techniques such as fast re-route
to ensure that connection between a time server and client devices is
not lost for too long.
4.4. OAM, SSM, and Performance Monitoring
In order to ensure continuity and connectivity of the path from the In order to ensure continuity and connectivity of the path from the
master to the client, and the reverse path when needed, an master to the client, and the reverse path when needed, an
Operations, Administration, and Maintenance protocol may be needed. Operations, Administration, and Maintenance protocol may be needed.
When the master sends timing distribution packets at a constant rate, When the master sends timing distribution packets at a constant rate,
faults are detected by the client after a few interpacket times; when faults are detected by the client after a few interpacket times; when
the rate is variable, the problem is detected after a few times the the rate is variable, the problem is detected after a few times the
maximum interpacket interval. However, in either case the master may maximum interpacket interval. However, in either case the master may
be unaware of the problem. be unaware of the problem.
Synchronization Status Messages (SSMs) were traditionally used in TDM Synchronization Status Messages (SSMs) were traditionally used in TDM
networks to indicate the accuracy of the source upon which an networks to indicate the accuracy of the source upon which an
incoming TDM link based its timing, and to notify the remote site of incoming TDM link based its timing, and to notify the remote site of
clock failures. Timing distribution protocols generally have similar clock failures. Timing distribution protocols generally have similar
functions. functions.
Performance monitoring is important to ensure the proper operation of Performance monitoring is important to ensure the proper operation of
timing systems, and may be integrated into OAM mechanisms. timing systems, and may be integrated into OAM mechanisms.
4.4. Path Selection 4.5. Network Management
In infrastructure applications it may be possible for TICTOC to seek As for all network infrastructure mechanisms, timing distribution
co-operation from routing elements to optimize the path through the systems SHOULD be managed. This implies provision of management
network in order to obtain a better quality of time and frequency agents in TICTOC masters and clients, and definition of the
transfer that is possible when the timing distribution protocol appropriate MIBs.
operates independent of the network layer.
4.6. Application profiles
PTP defines the concept of "profiles", defining the attributes and
options of the protocol required to support a given application. The
concept is extensible to other timing protocols, to ensure
interoperable components of a timing system.
Profiles are developed by standards organizations or other industry
bodies. For example, a "Telecom Profile" is currently under
definition by the ITU-T. The TICTOC working group will need to
specify the profile for the particular applications under its remit.
5. Network Support
5.1. Path Selection
In infrastructure applications it may be possible for TICTOC devices
to seek co-operation from routing elements to optimize the path
through the network in order to obtain a better quality of time and
frequency transfer that is possible when the timing distribution
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 that are explicitly chosen to be symmetric, or paths may be selected
such that all are capable of supporting physical frequency transfer such that all are capable of supporting physical frequency transfer
(for example synchronous Ethernet), or nodes may be selected such (for example synchronous Ethernet), or nodes may be selected such
that they are all capable of supporting transparent clock. that they are all capable of 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 the master to inform the client of the
change in operating conditions. change in operating conditions.
4.5. On-path Support 5.2. Network and Traffic Engineering
Every network element (e.g. router or switch) in a packet network
adds varying amounts of delay to the packet. This variation is
typically correlated to the load on that network element at the time,
and especially to the shared load on the output port.
Therefore, there is some maximum limit on both the traffic load and
the number of network elements that a packet timing flow can traverse
before being degraded beyond the point at which the recovered time or
frequency is outside of the specification for the given application.
This maximum limit will change depending on:
o stringency of the application requirements
o stability and environment of the local oscillator at the
time/frequency client device
o traffic load in the network
o topology of the network
o physical layer aspects of the network.
When planning a time/frequency distribution service over a managed
network, the network planner must take these considerations into
account. These will influence the appropriate locations for the
time/frequency servers and any on-path support elements that may be
deployed.
Traffic engineering may be used to control the traffic load in the
network on the routes used by the timing flows. This may help to
control the delay variation in the timing flow, and hence improve the
performance of the clock recovered by the client.
5.3. Service Level Specifications and QoS settings
The traditional approach to specifying network performance has been
to define a series of metrics such as packet loss and packet delay
variation. However, these metrics are not good predictors of how a
packet timing scheme is going to perform. For instance, the packet
delay variation metric is too abstract, since it doesn't take into
account the distribution of delays, or the correlation of delays over
a longer interval.
Recent research has examined the application to PDV of new metrics
borrowed from synchronization standards such as TDEV and a modified
version called minTDEV [minTDEV]. The goal is to define a metric
that is both measurable and capable of continuous monitoring. This
can then form the basis of a service level specification for a
network capable of running time/frequency distribution to a given
performance level.
Further, the network operator needs to know how to tune the network
to stay within the specified limit, since no operator is going to
sign up to a service level specification that he has no control over.
Appropriate QoS settings and techniques must be deployed to ensure
the timing packets are forwarded through the routers in the optimum
way.
5.4. Routing considerations
The basic method for calculating a time offset of a remote slave
connected over a packet network makes an assumption that the network
delays in each direction are the same. Any asymmetry between the
forward and reverse directions yields an error in the time offset
estimation.
While there may be various inferences that an algorithm can make
concerning the size of that asymmetry, there are no currently known
techniques for directly calculating its magnitude. Therefore it is
important that the routing is constrained to make the packet flow
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
should minimize any difference.
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 IEEE 1588 transparent In some cases on-path support (for example IEEE 1588 transparent
clock) may be needed in order to obtain the required frequency or clocks) may be needed in order to obtain the required frequency or
time accuracy. Such on-path support cannot be expected to be time accuracy. Such on-path support cannot be expected to be
universally available over the public Internet, and it is not a goal universally available over the public Internet, and it is not a goal
of the TICTOC working group to propose augmentation of basic of the TICTOC working group to propose augmentation of basic
forwarding elements. However, such on-path support may be provided forwarding elements. However, such on-path support may be provided
on service provider or enterprise networks, and in such cases TICTOC on service provider or enterprise networks, and in such cases TICTOC
protocols should be able to exploit it. protocols 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
skipping to change at page 16, line 22 skipping to change at page 19, line 37
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
specify the necessary routing extensions to support these specify the necessary routing extensions to support these
requirements. requirements.
TICTOC traffic may need to traverse NATs and firewalls. TICTOC traffic may need to traverse NATs and firewalls.
4.6. Network Management 6. Security Considerations
As for all network infrastructure mechanisms, timing distribution
systems SHOULD be managed. This implies provision of management
agents in TICTOC masters and clients, and definition of the
appropriate MIBs.
5. Security Considerations
This document proposes modularization of the work of a proposed
Working Group, and thus does not, in itself, raise security concerns.
Security aspects of TICTOC have been addressed above. Security aspects of TICTOC have been addressed above.
6. IANA Considerations 7. IANA Considerations
No IANA actions are required as a result of the publication of this No IANA actions are required as a result of the publication of this
document. document.
7. Acknowledgements 8. Acknowledgements
The authors wish to thank Alon Geva, Gabriel Zigelboim, and Laurent The authors wish to thank Yaakov Stein and Stewart Bryant for their
Montini for invaluable comments. contributions in the development of this document, and also Alon Geva,
Gabriel Zigelboim, and Laurent Montini for invaluable comments.
8. Informative References INFORMATIVE REFERENCES
[1588] IEEE, "1588-2002 Standard for A Precision Clock [IEEE1588] IEEE, "Standard for A Precision Clock Synchronization
Synchronization Protocol for Networked Measurement and Protocol for Networked Measurement and Control
Control Systems". Systems", IEEE1588-2008.
[G8262] ITU-T, "G.8262 - Timing characteristics of synchronous [G.8261] ITU-T, "Timing and Synchronization Aspects in Packet
ethernet equipment slave clock (EEC)".
[G.8262] ITU-T, "Timing characteristics of synchronous ethernet
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.
Authors' Addresses [minTDEV] G. Zampetti and L. Cosart, "Definition of minTDEV",
COM15-C363-E, Contribution to ITU-T Study Group 15,
Yaakov (Jonathan) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Phone: +972 3 645-5389 AUTHORS' ADDRESSES
Email: yaakov_s@rad.com
Stewart Bryant Tim Frost,
Cisco Systems Symmetricom Inc.,
250 Longwater Ave., Green Park Tamerton Road,
Reading RG2 6GB Roborough,
United Kingdom Plymouth, PL6 7BQ,
United Kingdom.
Email: tfrost@symmetricom.com
Email: stbryant@cisco.com Greg Dowd,
Symmetricom Inc.,
2300 Orchard Parkway,
San Jose,
CA 95112,
USA.
Email: gdowd@symmetricom.com
Karen O'Donoghue Karen O'Donoghue
US Navy US Navy
Code B35, NSWCDD, 17320 Dahlgren Rd. Code B35, NSWCDD,
Dahlgren, VA 22448 17320 Dahlgren Rd.
Dahlgren,
VA 22448,
USA.
Email: karen.odonoghue@navy.mil Email: karen.odonoghue@navy.mil
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors retain
retain all their rights. all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in this
this document or the extent to which any license under such rights document or the extent to which any license under such rights might or
might or might not be available; nor does it represent that it has might not be available; nor does it represent that it has made any
made any independent effort to identify any such rights. Information independent effort to identify any such rights. Information on the
on the procedures with respect to rights in RFC documents can be procedures with respect to rights in RFC documents can be found in BCP
found in BCP 78 and BCP 79. 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an attempt
attempt made to obtain a general license or permission for the use of made to obtain a general license or permission for the use of such
such proprietary rights by implementers or users of this proprietary rights by implementers or users of this specification can be
specification can be obtained from the IETF on-line IPR repository at obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary rights
rights that may cover technology that may be required to implement that may cover technology that may be required to implement this
this standard. Please address the information to the IETF at standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the Internet Society.
Administrative Support Activity (IASA).
 End of changes. 90 change blocks. 
339 lines changed or deleted 519 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/