<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
 <!ENTITY RFC1305 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1305.xml'>
 <!ENTITY RFC4553 PUBLIC '' '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' ipr='full3978' docName='draft-bryant-tictoc-probstat-02.txt'>

<front>
<title abbrev="TICTOC">TICTOC Problem Statement</title>

<author initials="S" surname="Bryant" fullname="Stewart 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 initials="Y(J)" surname="Stein" fullname="Yaakov (Jonathan) 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="9" month="April" year="2008" />

<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"/>. 
  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"/>, 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"/>, and IEEE 1588 <xref target="1588"/>.
  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"/>. 
  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>
