TICTOC

Timing over IP Connections and Transfer Of Clock

Mailing list:

General Discussion: https://www1.ietf.org/mailman/listinfo/tictoc
To Subscribe: TICTOC-request@ietf.org
In Body: subscribe your_email_address
Archive: http://www1.ietf.org/mail-archive/web/tictoc



Proposed Charter

Description of Working Group:

The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is concerned with highly accurate time and frequency distribution over native IP and MPLS-enabled IP Packet Switched Networks (PSNs). While this need arises from a variety of sources (see the Problem Statement), the application areas of focus for this WG are:
  1. Network infrastructures with the need for highly accurate time and frequency distribution within well-engineered service provider or enterprise campus networks. On-path support with specialized hardware may be expected to be available at one or more hops on a given path.
  2. Individual hosts and devices on the public Internet requiring functionality or performance not currently available in NTP. On-path support may be utilized if available, but is not expected. This application brings additional requirements beyond improved accuracy, for example, the traceable and authenticated distribution of UTC time, including correct handling of leap seconds.

The NTP Working Group is currently standardizing the fourth version of NTP for time distribution over IP networks. The NTP WG has focused its deliverables largely on standardizing the currently deployed NTPv4, while collecting requirements for future extensions. These requirements will transition to the TICTOC WG for further development. Meeting those requirements may include revision of the protocol to a new version level. However, in all cases backwards compatibility and coexistence with currently deployed NTPv4 is of paramount concern. An applicability statement will describe the use cases for which any extension of NTP is targeted. While application area (2) will be the main focus of NTP extensions, this does not prohibit their use in a closed network environment.

The IEEE Test and Measurement Society is in the final stages of standardizing a second version of IEEE1588 (unofficially known as IEEE1588v2, and expected to be published as IEEE1588-2008). IEEE1588v2 specifically encourages other standards organizations to adapt it to their requirements, and provides guidelines for doing so. TICTOC will create a profile within these guidelines for IEEE1588v2 over IP or MPLS-enabled IP networks, with primary focus on application area (1). An applicability statement will describe the use cases for which the profile is targeted.

Time and Frequency distribution is considered by many to be a complex and often esoteric subject area. The WG will develop a modular framework in order to map out components within the solution space, define terminology, and identify common areas of protocol work that can be capitalized upon.

TICTOC will consider the co-existence of IEEE1588v2 and NTP in the same network. In doing so, TICTOC will first verify that the data model of NTP can be accommodated by IEEE1588v2 protocol operation and document any deficiencies compared to NTP. If there is a need to map the data models, it will produce a specification for how to utilize IEEE 1588 in a localized region as one portion of an NTP-based system.

TICTOC protocols will be applicable to a variety of link layer technologies. To get the highest quality time and frequency transfer one should take advantage of link-based or network-element-based on-path support when available. Examples of link technologies that provide support for frequency transfer are SONET/SDH, TDM, Synchronous Ethernet and DSL with timing reference support. Network element support can be via a boundary clock (where time and frequency are regenerated at the node in a multistage master slave relationship) or a transparent clock (where corrections are applied to time transfer packets as they pass through to compensate for the queuing delay, and for known link delay asymmetry). Transparent clock (queue delay correction) requires routers to identify a time transfer packet, record the queuing delay, and either apply an on the fly correction to the packet, or to generate a follow-up packet with the necessary time correction information. TICTOC will ensure that any transparent clock design is acceptable in an Internet environment. On-path support is not a given, and TICTOC will investigate methods for automatically discovering when this support is available and when it is not.

TICTOC will transfer time and frequency over both IP and MPLS-enabled IP PSNs. One of the major users of TICTOC technology is the service provider community, where MPLS-enabled IP networks are common. If necessary, TICTOC may take advantage of the path control properties of MPLS and the ability to signal modifications to per-packet forwarding behavior.

The security of time transfer, including the authentication of the time reference is an important consideration that must be considered from the beginning.

The ultimate system-level accuracy of time and frequency transfer depends on a number of factors outside the scope of the protocols themselves. Thus, even if it is possible for TICTOC to make a number of improvements at the protocol level to facilitate more accurate time and frequency transfer, it is impossible for the WG to provide system-level accuracy guarantees on its own.

The TICTOC WG will co-ordinate with the PWE3 and NTP WGs in the IETF, as well as IEEE1588, IEEE 802.1AS and ITU-T SG15 Q13. It is also expected that active individuals in the TICTOC WG will propose the formation of an IRTF RG to study more advanced aspects of time and frequency distribution.

First phase Objectives:

Second phase Objectives (requiring re-charter of the WG):

To propose and document algorithms, protocols and mechanisms for transport, frequency acquisition, ranging, and packet selection/discard, master clock selection, path selection, OAM, synchronization status messaging, performance monitoring, security, and network management.

Goals and Milestones:

Dates are for documents exiting WG last call, and entering "Publication Requested" with the shepherding Area Director.
September 08 Problem statement
November 08 Modular Framework documentation
January 09 Requirements analysis for use cases, including gap analysis for NTPv4 and 1588v2
April 09 1588v2 profile, if needed
April 09 NTPv4 extensions, if needed
April 09 Security document(s)
March 09 MIB for IEEE 1588v2 profile and NTPv4 extensions (TICTOC MIB)
March 09 Prioritize second phase deliverables and add milestones or recharter


Internet Drafts

  1. Problem Statement draft-bryant-tictoc-probstat-01.txt
  2. Modularization Draft draft-stein-tictoc-modules-00.txt
  3. RAN Synchronization Requirements draft-zhou-tictoc-ran-sync-req-00.txt