Internet DRAFT - draft-frost-packet-timing-framework
draft-frost-packet-timing-framework
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]
