INTERNET-DRAFT Tim Frost Intended Status: Informational Greg Dowd Symmetricom Dave Tonks Semtech Stewart Bryant Cisco Systems Expires: March 2008 September 2007 Framework for the Distribution of Time and Frequency References across IP and MPLS Networks draft-frost-packet-timing-framework-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a framework for the transmission of precise time and frequency across packet switched networks, in particular IP and MPLS. It examines what is needed over and above the protocols themselves to allow accurate recovery of time and frequency at remote nodes across the packet network. Frost et al. Informational [Page 1] Internet Draft draft-frost-packet-timing-framework-00 September 2007 Table of Contents 1. Introduction.....................................................2 2. Creating a Packet Timing Framework...............................2 3. Framework Elements...............................................3 3.1. Basic time transfer protocol.................................3 3.2. Transport specifications.....................................3 3.3. Application profile..........................................3 3.4. Network engineering guidelines...............................4 3.5. Service level specifications.................................4 3.6. Routing considerations.......................................5 3.7. Redundancy considerations....................................5 3.8. Security considerations......................................5 4. IANA Considerations..............................................6 References..........................................................7 Acknowledgements....................................................7 Authors' Addresses..................................................8 1. Introduction At IETF 68 (March 2007) the TICTOC BOF was held to discuss the 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, and these are well documented in the BOF's problem statement [TICTOC]. 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 [NTPv4]. The IEEE has recently gone to ballot on a revision of the Precision Time Protocol [IEEE1588v2]. The ITU-T has also begun work on Synchronous Ethernet, a physical layer technology for transfer of frequency across native Ethernet [G.8261]. However, as [TICTOC] notes, 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. This draft attempts to document what else needs to be put in place in order to enable the technology to deliver the performance necessary to meet the various application requirements. It is hoped that this will spawn a series of other drafts to address each of the issues noted. 2. Creating a Packet Timing Framework In order to create a suitable ecosystem for the adoption of packet timing methods, the following elements need to be in place: - the basic time transfer protocol (e.g. PTP or NTP) - transport specification over the network layer protocol to be used Frost et al. Expires February 2008 [Page 2] Internet Draft draft-frost-packet-timing-framework-00 September 2007 - application profile, defining the various parameters and optional values to be used for the applications in mind - network engineering guidelines for creating timing-grade network flows - service level specifications for timing-grade connections - routing considerations, especially with regards to sensitivity of time alignment algorithms to the symmetry of the forward and reverse paths - redundancy considerations - security considerations 3. Framework Elements The discussion below assumes the use of PTP version 2 [IEEE1588v2] as the base time transfer protocol. This is not meant to rule out the use of any other protocol (e.g. NTP), but is meant to focus the discussion. Similar requirements may be framed around the use of any other suitable protocol. 3.1. Basic time transfer protocol PTP version 2 has now been defined in [IEEE1588v2]. 3.2. Transport specifications [IEEE1588v2] includes normative appendices that defines the transport of PTP over both UDP/IPv4 and UDP/IPv6, amongst other protocols. [PTP-MPLS] is the first draft of an attempt to define the operation of PTP over an MPLS pseudowire. Further work will be required in the IETF to complete this specification. 3.3. Application profile The purpose of a PTP profile is to allow organizations to specify specific selections of attribute values and optional features of PTP that, when using the same transport protocol, will inter-work and achieve a performance that meets the requirements of a particular application. A PTP profile is a set of required options, prohibited options, and the ranges and defaults of configurable attributes. Frost et al. Expires February 2008 [Page 3] Internet Draft draft-frost-packet-timing-framework-00 September 2007 A "Telecom Profile" is currently under definition by the ITU-T; however, application profiles may be developed by any relevant standards organization. Some potential applications relate to network quality of experience and verification of service level specifications. The IETF is the most appropriate body to construct a relevant profile for these types of applications. 3.4. Network engineering guidelines 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 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: - stringency of the application requirements - stability and environment of the local oscillator at the time/frequency client device - load in the network - topology of the network - physical layer aspects of the network. While the first two are outside the scope of the network planner, the remainder must be considered when planning a time/frequency service. It cannot be expected that such services will perform adequately over any arbitrary network. Guidelines will need to be provided for each application to help the network operator assess whether the network is capable of running the time/frequency service, and to engineer the network accordingly. 3.5. Service level specifications 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. Frost et al. Expires February 2008 [Page 4] Internet Draft draft-frost-packet-timing-framework-00 September 2007 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 time/frequency services. 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. 3.6. 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. 3.7. Redundancy considerations 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. 3.8. Security considerations Time and frequency services are a significant element of network infrastructure, and are critical for certain emerging applications. The ability to disrupt network synchronization could be used as the key to disrupting an entire network, and especially any real-time services carried over the network. Frost et al. Expires February 2008 [Page 5] Internet Draft draft-frost-packet-timing-framework-00 September 2007 Hence it is extremely important that time and frequency transfer services are protected from being compromised. There are several possible threats to time and frequency services: - acceptance of a false time or frequency server This may enable a hacker to bring down critical services. Hence it is particularly important to know where a source of packet timing is coming from, and whether it is genuine. - excessive packet delay variation, such as might be caused by a targeted denial of service attack Timing distribution is highly sensitive to packet delay, and thus can deteriorate under congestion conditions. When a service is disrupted by such means, the client needs to go into "holdover" mode, and its accuracy will consequently be degraded. Work performed by the IETF PWE3 WG on congestion would seem to be applicable to this problem area. 4. IANA Considerations No IANA actions are required as a result of the publication of this this document. Frost et al. Expires February 2008 [Page 6] Internet Draft draft-frost-packet-timing-framework-00 September 2007 INFORMATIVE REFERENCES [NTPv4] J. Burbank et al, "Network Time Protocol Version 4 Protocol And Algorithms Specification", draft-ietf-ntp-ntpv4-proto-07, Work in Progress, May 2007 [PTP-MPLS] R. Cohen, "PTP over MPLS", draft-ronc-ptp-mpls-00, Work in Progress, June 2007 [TICTOC] S. Bryant and Y. Stein, "TICTOC Problem Statement", draft-bryant-tictoc-probstat-00.txt, Work in Progress (Expired), January 2007 (may be obtained from http://www.dspcsp.com/tictoc/draft-bryant-tictoc-probstat-00.txt) [IEEE1588v2] "Draft Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE P1588/D1-R 2007-06-04, Work in Progress, June 2007 [G.8261] "Timing and Synchronization Aspects in Packet Networks", ITU-T Recommendation G.8261, May 2006 [minTDEV] G. Zampetti and L. Cosart, "Definition of minTDEV", COM15-C363-E, Contribution to ITU-T Study Group 15, Question 13, May 2007 ACKNOWLEDGEMENTS Thanks to the authors of the TICTOC problem statement (Stewart Bryant and Yaakov Stein), from which sections of text have been either directly lifted or adapted here. Frost et al. Expires February 2008 [Page 7] Internet Draft draft-frost-packet-timing-framework-00 September 2007 AUTHORS' ADDRESSES Tim Frost, Symmetricom Inc., Tamerton Road, Roborough, Plymouth, PL6 7BQ, United Kingdom. Email: tfrost@symmetricom.com Greg Dowd, Symmetricom Inc., 2300 Orchard Parkway, San Jose, CA 95112, USA. Email: gdowd@symmetricom.com Dave Tonks, Semtech Ltd., 2-3 Park Court, Premier Way, Abbey Park Ind Est, Romsey, SO51 9DN United Kingdom. Email: dtonks@semtech.com Stewart Bryant Cisco Systems, 250, Longwater, Green Park, Reading, RG2 6GB, United Kingdom. EMail: stbryant@cisco.com Frost et al. Expires February 2008 [Page 8] Internet Draft draft-frost-packet-timing-framework-00 September 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Frost et al. Expires February 2008 [Page 9]