One document matched: draft-bryant-tictoc-probstat-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1305.xml">
<!ENTITY RFC4553 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4553.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<rfc category="info" docName="draft-bryant-tictoc-probstat-01.txt"
ipr="full3978">
<front>
<title abbrev="TICTOC">TICTOC Problem Statement</title>
<author fullname="Stewart Bryant" initials="S" surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>250 Longwater Ave., Green Park</street>
<city>Reading</city>
<code>RG2 6GB</code>
<country>United Kingdom</country>
</postal>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Yaakov (Jonathan) Stein" initials="Y(J)" surname="Stein">
<organization>RAD Data Communications</organization>
<address>
<postal>
<street>24 Raoul Wallenberg St., Bldg C</street>
<city>Tel Aviv</city>
<code>69719</code>
<country>ISRAEL</country>
</postal>
<phone>+972 3 645-5389</phone>
<email>yaakov_s@rad.com</email>
</address>
</author>
<date day="24" month="September" year="2007" />
<area>Internet</area>
<workgroup>TICTOC</workgroup>
<keyword>timing</keyword>
<keyword>frequency</keyword>
<keyword>NTP</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This Internet draft describes a number of applications that require
accurate time and/or frequency, and elucidates difficulties related to
the transfer of high quality time and frequency across an IP or MPLS
Packet Switched Network. This issue is not addressed by any currently
chartered IETF working group, and we therefore propose the formation of
a new working group to be called Transmitting Timing over IP Connections
and Transfer of Clock (TICTOC).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>There is an emerging need to distribute highly accurate time and
frequency information over IP and over MPLS packet switched networks
(PSNs). In this problem statement we give several examples of
applications that require time and/or frequency information, and explain
why their needs can not be satisfied by time/frequency transfer over
PSNs using existing protocols. We review these existing protocols and
the work being carried out in the IETF and in other forums. Finally, we
list the objectives of a proposed Working Group.</t>
</section>
<section title="Applications">
<section title="Time Service Applications">
<t>There are many applications that need to know the time with greater
precision than provided by available mechanisms, such as the current
version of NTP <xref target="RFC1305"></xref>. These applications span
a range of industries: telecommunications, financial, test and
measurement, government, industrial etc. Preliminary studies indicate
that the availability of high accuracy time as a commodity enables use
of techniques that were previously considered impossible. We can,
therefore, expect that the provision of high quality time through the
network infrastructure will generate a spiral of new innovative
applications that will in turn make greater demands on the quality of
time delivered to the end-user.</t>
<t>The best-known example of an application that requires high quality
time in the telecommunications sector is the need to measure one-way
packet delay. Current implementations of NTP have accuracy of the
order of 10 milliseconds. When NTP is used to characterize packet
delay and packet delay variation, such a time-base cannot resolve any
two party event with a resolution of better than 20 milliseconds.
Contrast this with the characteristics of a 10 Gb/s link, 1 kilometer
long. On such a link, a minimum sized packet takes 50 nanoseconds to
send, and it takes 6 microseconds to traverse the link. The
performance of current NTP implementations is orders of magnitude
worse than the duration of network forwarding events, and clearly
insufficient to characterize them.</t>
<t>Although the measurement of the characteristics of a packet network
is the best-known telecommunications example, there are other
operational needs, notably synchronization at the MAC layer. The cable
industry has recently defined a new intra-PoP time transmission
mechanism for just this purpose (DOCSYS Timing Interface), and WiMAX
is looking for relative time delivery to its transmitter sites.</t>
<t>In the test and measurement and industrial sector there is a desire
to move from special purpose communications infrastructure with
calibrated wiring run back to a centralize controller, to a
distributed system, in which instructions are distributed in advance
to be executed at a predetermined time, and in which measurements are
taken remotely and communicated back to a common point for later
correlation and analysis. Two examples of this tendency are described
below.</t>
<t>In the printing industry there is a need to control operations in
multi-stand printing machines. The paper travels through these
machines at a speed of nearly 100 km/h. At these speeds, co-ordination
error of 1 microsecond between operations taking place at different
positions in the machine produces a 0.03mm color offset, which is
visible to the naked eye and results in an unacceptable degradation in
quality.</t>
<t>In the electrical power industry there is a need to improve the
measurement of power flows in order to monitor and predict usage
patterns. One proposal is to extensively deploy synchro-phasors in the
power network and to correlate their output to determine demand. These
devices need to be able to determine the time of measurement with an
accuracy of 1 microsecond.</t>
<t>More generally, there is growing interest in clock synchronization
in massively parallel sensor networks. Advances in wireless
communications have enabled the development of low power miniature
sensors that collect and disseminate data from their immediate
environment. Although each sensor has limited processing power,
through distributed processing the network becomes capable of
performing various tasks of data fusion, but only assuming a common
time base can be established.</t>
<t>The examples cited above are a small illustration of a trend that
will continue to grow as designers realize that better scaling can be
achieved with action-in-the-future, measure-and-correlate-later
approaches to systems design.</t>
<t>Closer to the core interests and expertise of the IETF there is an
emerging opinion that the availability of time as a commodity may
simplify the protocols that we use in distributed systems.</t>
</section>
<section title="Frequency Service Applications">
<t>There are applications that require time with a greater precision
than can easily be provided using available mechanisms. Cellular
base-stations require a highly accurate frequency reference from which
they derive transmission frequencies and operational timing.
Conventionally GSM and WCDMA base stations obtain this reference
frequency by locking on to the E1/T1 that links them to the base
station controller. With the replacement of TDM links with Packet
Switched Networks (PSNs) such as Ethernet, IP or MPLS, this simple
method of providing a frequency reference is lost, and frequency
information must be made available in some other way.</t>
<t>Why must the frequency reference be so accurate? First and foremost
the requirement is derived from the need for the radio frequencies to
be accurate. Radio spectrum is a limited and valuable commodity that
needs to be used as efficiently as possible. In GSM, transmission
frequencies are allocated to a given cellular base station and its
neighbors in such fashion as to ensure that they do not interfere with
each other. If the radio network designer cannot rely on the accuracy
of these frequencies, the spacing between the frequencies used by
neighboring sites must be increased, with significant economic
consequences.</t>
<t>There is an additional requirement derived from the need for smooth
handover when a mobile station crosses from one cell to another. If
the radio system designer can not guarantee that the preparations
required for handover occur in a few milliseconds, then they must
allow the mobile station to consume frequency resources simultaneously
in both cells in order to avoid service disruption. The preparations
required involve agreement between the mobile and base stations on the
new frequencies and time offsets; these agreements can be accomplished
quickly when the two base stations' frequency references are the same
to a high degree of accuracy.</t>
<t>Another application requiring highly accurate frequency
distribution is TDM pseudowires. The PWE3 WG has produced three
techniques for emulating traditional low-rate (E1, T1, E3, T3) TDM
services over PSNs, namely SAToP <xref target="RFC4553"></xref>,
CESoPSN, and TDMoIP. The major technical barrier to universal
acceptance of TDM pseudowires is the accuracy of its clock
recovery.</t>
<t>TDM network standards for timing accuracy and stability are
extremely demanding. These requirements are not capriciously dictated
by standards bodies, rather they are critical to the proper
functioning of a high-speed TDM network. Consider a TDM receiver
utilizing its own clock when converting the physical signal back into
a bit-stream. If the receive clock runs at precisely the same rate as
the source clock, then the receiver need only determine the optimal
sampling phase. However, with any mismatch of clock rates, no matter
how small, bit slips will eventually occur. For example, if the
receive clock is slower than the source clock by one part per million
(ppm), then the receiver will output 999,999 bits for every 1,000,000
bits sent, thus deleting one bit. Similarly, if the receive clock is
faster than the source clock by one part per billion (ppb), the
receiver will insert a spurious bit every billion bits. One bit slip
every million bits may seem acceptable at first glance, but translates
to a catastrophic two errors per second for a 2 Mb/s E1 signal. ITU-T
recommendations permit a few bit slips per day for a low-rate 64 kb/s
channel, but strive to prohibit bit slips entirely for higher-rate TDM
signals.</t>
<t>In certain cases, such as "toll-bypass" or "carrier's carrier"
links, the endpoints of the TDM PW are full TDM networks, and timing
may (indeed must) be derived from the respective network clocks. Since
each of these clocks is highly accurate, they necessarily agree to
high order. However, TDM PWs are expected to increasingly replace
native TDM links delivering services from core networks towards users,
and here there is no alternative to provision of accurate frequency
information.</t>
<t>In this context there are two types of frequency distribution being
studied. In the first type the frequency reference used by the TDM
source is distributed downstream, as in the native TDM service. In the
"common clock" scenario highly accurate frequency information is
distributed from a central server to both ends of the emulated TDM
link. By placing in the protocol overhead timestamps based on the
common clock, the receiver can accurately recover the TDM source
clock.</t>
<t>While it is true that services designed for PSN (e.g. VoIP)
transport are less dependent on frequency accuracy, there are still
cases where such services need accurate frequency distribution. For
example, when interconnecting tradition telephones via VoIP links,
users expect these links to support legacy services, such as facsimile
and dial-up data modems. The optimal technique for supporting these
services is by provision of relay functions, e.g. T.38 fax-relay and
V.150 modem-relay, that terminate the analog transmissions on both
sides and transfer data content over the PSN. However, provision of
relay services is computationally expensive, often requires expensive
DSP-capable media gateways, and can only support known modem types. In
many deployments old fax machines or proprietary data modems or secure
voice telephones are used, and the modulations and handshake protocols
are not recognized by the relays provided. In such cases the solution
is to carry these transmissions over "clear channel" or Voice Band
Data (VBD), i.e. to send raw samples of the audio in packets over the
PSN.</t>
<t>The problem with clear channel transfer of data over PSNs is that
the end points expect a non-intrusive analog channel between them,
over which they implicitly transfer timing information. The receiver
can thus continually lock onto the transmitter's frequency, and the
transmission can continue for an unlimited period without
interruption. When employing clear channel, the frequency signal seen
by the receiver is influenced by the destination gateway's clock used
to convert the data samples back to analog form. If the source and
destination gateways' clocks do not agree to a high degree of
accuracy, the receiver does not properly lock onto the transmitter's
clock, leading to disruption of the data reception. In typical cases a
modem conversation transferred over clear channel may drop after only
several minutes, and fax reception may be interrupted after several
pages have been received.</t>
</section>
</section>
<section title="Existing Time and Frequency Transfer Mechanisms">
<t>In this section we will discuss existing mechanisms for transfer of
time information, frequency information, or both. It should be noted
that a sufficiently accurate time transfer service may be used to derive
an accurate frequency transfer. Indeed, this is exactly what happens in
a GPS disciplined frequency standard. On the other hand, an accurate
frequency transfer service, while itself unable to transfer absolute
time, is usually used to support and improve the performance of the time
transfer service. Indeed, implementations of NTP or IEEE 1588 clients
can be considered to consist of two phases. First, a local oscillator is
locked to the server's frequency using incoming information from the
incoming packets, and then the local time set based on the server's time
and the propagation latency. By maintaining a local frequency source,
the client requires relatively infrequent updates, and can continue
functioning during short periods of network outage. Moreover, it can be
shown that this method results in significantly better time transfer
accuracy than methods that do not discipline a local clock.</t>
<t>Time transfer mechanisms can be divided into three classes. The first
class consists of mechanisms that use radio frequency transport, while
the second mechanism uses dedicated "wires" (which for our purposes
include optical fibers). The third, which will be our main focus,
exploits a Packet Switched Network for transfer of timing information.
Advantages and disadvantages of these three methods are discussed in the
following subsections.</t>
<section title="Radio-based Timing Transfer Methods">
<t>The transfer of time by radio transmission is one of the oldest
methods available, and is still the most accurate wide area method. In
particular, there are two navigation in wide use that can be used for
time transfer, The LOng RAnge Navigation (LORAN) terrestrial radio
system, and the Global Navigation Satellite System (GNSS). In both
cases the user needs to be able to receive the transmitted signal,
requiring access to a suitable antenna. In certain situations, e.g.
basement communications rooms and urban canyons, the required signal
may not be receivable.</t>
<t>Radio systems have high accuracy, far better than what we will
later see can be achieved by existing PSN technologies. However
coverage is limited; eLORAN for example only covers North America, and
GPS does not have good coverage near the poles.</t>
<t>Although civilian use is sanctioned, the GPS was developed and is
operated by the U.S. Department of Defense as a military system. For
this reason there are political concerns that rules out its use in
certain countries. The European Union is working on an alternative
system called Galileo, which will be run as a commercial enterprise.
In addition, GPS has some well-documented multi-hour outages, and is
considered vulnerable to jamming. One major PTT also reports that they
see a 2% per year failure rate for the antenna/receiver/clock-out
chain.</t>
<t>While a radio-based timing service may be acceptable for some
sites, it is frequently impractical to use on a per equipment basis.
Hence, some form of local timing distribution is usually also
required.</t>
</section>
<section title="Dedicated Wire-based Timing Transfer Methods">
<t>The use of dedicated networks in the wide area does not scale well.
Such services were available in the past, but for reasons of cost and
accuracy have been superseded by GPS based solutions.</t>
<t>In the local area, one new technique is emerging as a mechanism for
time transport, namely DOCSIS Timing Interface / Telecommunications
Timing Interface (DTI/TTI). DTI was designed by DOCSIS for the
distribution of time in a cable head-end in support of media access
control. Time transfer is packet-based over a multi-stage hub and
spoke dedicated network. It uses a single twisted-pair in half-duplex
to eliminate inaccuracies due to the length differences between the
pairs in a multi-pair cable. TTI is a development of DTI designed to
provide synchronization in a telephone local office. Accuracy for DTI
is better than 5 nanoseconds and range is 100 feet for DTI. This
increases to 600 feet for TTI at some reduction in packet rate and
hence time quality.</t>
<t>The DTI/TTI approach is applicable for special applications, but
the need for a dedicated network imposes significant drawbacks for the
general time transfer case.</t>
<t>Synchronous Ethernet is a technique that has recently been proposed
for providing frequency distribution over Ethernet links. Modern
dedicated-media full-duplex Ethernet, in both copper and optical
physical layer variants, transmits continuously. One can thus elect to
derive the physical layer transmitter clock from a high quality
frequency reference, instead of the conventional 100 ppm
crystal-derived transmitter rate. The receiver at the other end of the
link automatically locks onto the physical layer clock of the received
signal, and thus itself gain access to a highly accurate and stable
frequency reference. Then, in TDM fashion, this receiver could lock
the transmission clock of its other ports to this frequency
reference.</t>
<t>The ITU-T is presently working on a specification for synchronous
Ethernet. Apart from some necessary higher layer packet based
configuration and OAM operations, the solution is entirely physical
layer, and has no impact on higher layers.</t>
<t>At first sight it would seem that the only application of
synchronous Ethernet was in frequency transfer (it has no intrinsic
time transfer mechanism). However, the quality of packet-based time
transfer mechanism can be considerably enhanced if used in conjunction
with synchronous Ethernet as a frequency reference.</t>
</section>
<section title="Transfer Using Packet Networks">
<t>When using a PSN to transfer timing, a server sends timing
information in the form of packets to one or multiple clients. When
there are multiple clients, the timing packets may be multicast.
Software in the client recovers the frequency and/or time of the
server based on the packet arrival time and the packet contents.</t>
<t>There are two well-known protocols capable of running over a
general-purpose packet network, NTP <xref target="RFC1305"></xref>,
and IEEE 1588 <xref target="1588"></xref>. NTP is the product of the
IETF, and is currently undergoing revision to version 4. IEEE 1588 (a
product of the IEEE Test and Measurement community) is specified in a
limited first version, and the second version (1588v2)is in the
detailed design stage.</t>
<t>NTP is widely deployed, but existing implementations deliver
accuracy on the order of 10 milliseconds. This accuracy is not
adequate for the applications described above. NTP suffers from the
fact that it was designed to operate over the Internet, and the
routers and switches used in the best effort Internet make no special
concessions to NTP for preservation of time transfer accuracy.
Furthermore, typical update rates are low and can not be significantly
increased due to scalability issues in the server. In addition most
NTP time servers and time receivers have a relatively unsophisticated
implementation that further degrades the final time quality.</t>
<t>IEEE 1588v1 was a time transfer protocol that exclusively used a
fairly crude multicast technique. It is widely anticipated that wide
scale deployment of IEEE1588 will be based on 1588v2. The information
exchange component of IEEE 1588 is a protocol known as Precision Time
Protocol (PTP).</t>
<t>IEEE 1588v2 can be considered to consist of several components:
<list style="numbers">
<t>A configuration and control protocol</t>
<t>A time transfer protocol</t>
<t>A time correction protocol</t>
<t>Physical mapping</t>
</list></t>
<t>The configuration and control protocol is based on the multicast
approach of IEEE 1588v1 (multicast IP with recommended TTL=1, UDP,
IEEE1588 payload with equipment identifier in the payload). The
rationale for this approach was that the equipment needed to be "plug
and play" (no configuration), was required to map to physical media
other than Ethernet, and had to have a very low memory and processor
footprint.</t>
<t>The time transfer protocol is a standard two-way time transfer
approach used in other packet-based approaches. Like all such
approaches it is subject to inaccuracies due to variable store and
forward delays in the packet switches, and due to the assumption of
symmetric propagation delays. The time transfer packets (in both
directions) may be operated in a multicast or unicast mode.</t>
<t>The time correction protocol is used to correct for propagation,
store and forward delays in the packet switches. This again may be
operated multicast or unicast. This mechanism requires some level of
hop-by-hop hardware support. This mechanism may also be considered a
concept in its own right and may be adapted to enhance other packet
time transfer protocols such as NTP.</t>
<t>The base 1588 specification describes how the PTP operates over the
Ethernet/IP/UDP protocol stack. Annexes are planned that describe PTP
operation over pure layer 2 Ethernet, over IP without UDP, over MPLS,
and over a number of specialist media.</t>
<t>The mappings of interest for telecommunications are PTP over
UDP/IP, PTP over MPLS , and perhaps PTP over Ethernet, all in unicast
mode only. Issues of a suitable control management and OAM environment
for these applications are largely in abeyance, as are considerations
about the exact nature of the network environment.</t>
<t>It is also worth noting the existence of a second IEEE effort, IEEE
802.1AS. This group is specifying the protocol and procedures to
ensure synchronization across Bridged and Virtual Bridged Local Area
Networks for time sensitive applications such as audio and video. For
these LAN media the transmission delays are assumed to be fixed and
symmetrical. IEEE 802.1AS specifies the use of IEEE 1588
specifications where applicable in the context of IEEE Standards
802.1D and 802.1Q. Synchronization to an externally provided timing
signal (e.g., a recognized timing standard such as UTC or TAI) is not
part of this standard but is not precluded. IEEE 802.1AS will specify
how stations attached to bridged LANs to meet the respective jitter,
wander, and time synchronization requirements for time-sensitive
applications.</t>
<section title="The Packet Network Environment">
<t>Packet delay variation, propagation asymmetry, and maximum
permissible packet rate all have a significant bearing on the
accuracy with which the client is able to determine absolute time.
Thus the network environment has a large bearing on the quality of
time that can be delivered.</t>
<t>Packet delay variation can to some extent be addressed by traffic
engineering, thus time transfer with a service provider network in
which suitable traffic engineering techniques had been applied might
reasonably be expected to deliver a higher quality time service than
can be achieved between two arbitrary hosts connected to the
Internet. Greater gains can probably be obtained by deploying
equipment that incorporates IEEE 1588 style on-the-fly packet
timestamp correction, or follow-up message mechanisms that report
the packet storage and forward delays to the client. However one can
only be sure that such techniques are available along the entire
path in a well-controlled environment.</t>
<t>The packet rate between the time-server and its client also has a
bearing on the quality of the time transfer, because at a higher
rate the smart filter has a better chance of extracting the "good"
packets. In a controlled environment it is possible to ensure that
there is adequate bandwidth, and that the server is not overloaded.
In such an environment the onus moves from protecting the server
from overload, to ensuring that the server can satisfy the needs of
all of the clients.</t>
</section>
</section>
</section>
<section title="Problems with Existing Solutions">
<t>An obvious candidate for clock distribution is NTP or some upgrade
thereof. While the time resolution provided by NTP is extremely good,
the accuracy attainable by existing NTP implementations does not satisfy
the needs of the most demanding of the applications, mainly due to
update rate and the particular client/server method employed.</t>
<t>The new IEEE 1588v2 protocol also addresses these needs, but has been
largely designed around a well-controlled LAN environment. A 1588 server
in unicast mode needs to save state information for each client, a
solution that does not scale well to deployment sizes envisioned. In
addition, 1588 specifies hardware upgrades in order to perform well in
an IP network.</t>
<t>Synchronous Ethernet only satisfies the need for frequency
distribution, and even then only over one physical Ethernet link at a
time. In order to use synchronous Ethernet in a network, all network
elements must be upgraded to support synchronous operation at the
physical layer. Even when hardware can be upgraded, only frequency is
delivered, and there is still a need to develop a time transfer
protocol.</t>
</section>
<section title="Other Forums Working in this Problem Space">
<t>The NTP WG is the IETF group working on time distribution, but is
presently only documenting NTPv4 and is not working on new algorithms or
protocols. It is expected that many participants of the NTP WG will
participate in the TICTOC effort.</t>
<t>The PWE3 WG has discussed frequency distribution for the TDM PW
application, however it is not chartered to develop protocols for this
purpose. It is expected that participants of the PWE3 WG who were active
in the TDM PW discussions will participate in the TICTOC effort.</t>
<t>The work that is underway outside the IETF is either complementary to
this proposal, or less general than the proposal proposed by the TICTOC
work proposal.</t>
<t>The IEEE 1588 task force is working on a new version of their
protocol that will run over more types of PSNs, and is planning to
conclude its development work in the near future. The protocol to be
specified contains elements that will be of use in an IETF environment,
but is unlikely to be regarded as being a complete, robust solution in
such an environment. If the IEEE 1588 structure is deemed to be a
suitable platform, then the IETF could contribute an Internet profile,
including a complete distributed systems environment suitable for our
purposes. Alternatively, the IETF could perhaps borrow some of the delay
correction mechanisms and incorporate them into a development of a new
version of NTP.</t>
<t>In addition, IEEE 802.1AS is working on Timing and Synchronization
for Time-Sensitive Applications in Bridged Local Area Networks, basing
itself on the IEEE 1588 standard.</t>
<t>ITU-T SG15 Question 13 has produced Recommendation G.8261 "Timing and
synchronization aspects in packet networks" <xref
target="G8261"></xref>. This Recommendation defines requirements for
various scenarios, outlines the functionality of frequency distribution
elements, and provides measurement guidelines. It does not specify
algorithms to be used for attaining the performance needed. It does
define requirements for status synchronization messages, but does not
otherwise define a protocol (although work is in progress). To date the
ITU-T has focused on Ethernet infrastructure, but this is likely to
extend to an MPLS environment. Two new work items, G.paclock and
G.pacmod extend the work, and in particular, G.pacmod intends to
introduce time transfer. This is an area where the IETF, with its
expertise in IP and MPLS networks, may co-operate with the ITU.</t>
</section>
<section title="Security Considerations">
<t>Time and frequency services are a significant element of network
infrastructure, and are critical for certain emerging applications.
Hence time and frequency transfer services MUST be protected from being
compromised. The most significant threat is a false time or frequency
server being accepted instead of a true one, thus enabling a hacker to
bring down critical services.</t>
<t>Any protection mechanism must be designed in such a way that it does
not degrade the quality of the time transfer. Such a mechanism SHOULD
also be relatively lightweight, as client restrictions often dictate a
low processing and memory footprint, and because the server may have
extensive fan-out.</t>
</section>
<section title="Security Considerations">
<t>Timing distribution is highly sensitive to packet delay, and can thus
can deteriorate under congestion conditions. Furthermore the
disciplining of the client's oscillator (the sole component of frequency
transfer, and a critical component of time transfer) is a function that
should not be disrupted. When the service is disrupted the client needs
to go into "holdover" mode, and its accuracy will consequently be
degraded. Depending on the relative quality of the client's clock and
the required quality after disciplining, a relatively high packet rate
may be required.</t>
<t>Timing tranfer packets should always be sent using the highest class
of service, and when possible should be sent over a traffic engineered
path.</t>
<t>When the network goes into congestion it should try to avoid
discarding time transfer packets until the situation is critical. Work
performed by the IETF PWE3 WG on congestion would seem to be applicable
to this problem area.</t>
</section>
<section title="IANA Considerations">
<t>No IANA actions are required as a result of the publication of this
document.</t>
</section>
<section title="Acknowledgements">
<t>The authors wish to thank Laurent Montini for valuable comments.</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="1588">
<front>
<title>1588-2002 Standard for A Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems</title>
<author>
<organization>IEEE</organization>
</author>
</front>
</reference>
<reference anchor="G8261">
<front>
<title>Recommendation G.8261/Y.1361 - Timing and synchronization
aspects in packet networks</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="May" year="2006" />
</front>
</reference>
&RFC1305;
&RFC4553;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 02:39:16 |