Tag Archives: Introduction

Introduction to Precision Time Protocol (IEEE 1588)

PTP Goals

PTP was originally defined in the IEEE 1588-2002 standard, officially entitled “Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems” and published in 2002. In 2008, IEEE 1588-2008 was released as a revised standard; also known as PTP Version 2 [PTPv2], it improves accuracy, precision and robustness but is not backward compatible with the original 2002 version.

IEEE 1588 was designed to fill a niche that neither NTP nor GPS could fulfill by solving two problems:

Local systems needing clock accuracy in the sub-microsecond range
Systems needing synchronisation in areas that cannot afford the cost of a GPS receiver at each node, or that cannot receive GPS signals (consider an underground or windowless datacenter)

The origins of IEEE 1588 development come from test and measurement (instrumentation and data acquisition), industrial automation or power generation, and received strong support from the automation industry leading to the adoption of the IEEE 1588-2002 standard by the Industrial Electro-technical Commission [IEC] as IEEE/IEC 61588-2004.

Specific application domains and targets had driven first release of IEEE 1588 work. Applications (e.g. data acquisition, military instrumentation, industrial robots and high-speed printers) and their targets, had sufficient shared objective to define common criteria:

Achievable sub-microsecond accuracy (if required).
Operation over control localised areas, such as local area network [LAN], with no intent to cover Internet or wide area networks, but supporting a PTP system.
Administration-free operation allowing “plug-and-play” deployment of IEEE 1588 clocks
Designed for minimal resource requirement in devices supporting PTP (clock filtering or averaging might not be necessary).

Currently one of the main industries using PTP is the High-Frequency Trading [HFT], and financial sector, to ensure highly accurate timing and synchronisation for their market feeds and trading servers.

When reading the spec

Just to note, that as an IEEE spec, 1588 can be far more difficult to read than IETF/RFC documents. A key thing to note in this particular spec is that IEEE 1588 also specifies “the node, system, and communications properties necessary to support PTP” and proposes models of devices, called “clocks” that support the protocol and aim to help and enhance the transfer of packet-based timing references. In IEEE 1588 terms, a PTP system is a set of IEEE 1588 clocks with specialised functions to support the protocol, PTP.

For instance, specifications of an IEEE 1588 clock include some material, such as a port, that is not part of the protocol itself. However, the messages sent and received by each port of an IEEE 1588 clock and the resulting behaviour of that clock is part of the protocol. Nonetheless, the standard does not define any performance objective for transport network device or clock.

To simplify – a PTP clock is a device that runs the PTP protocol, and has one or more network interfaces

Facebook

Twitter

Stumbleupon

Securing simple telemetry submission with HTTP Header Enrichment

Leave a reply

As part of an ongoing side project involving my newly acquired Arduino, I’ve been thinking about datalogging, and specifically network based data logging – the goal being to have all the sensor data available for analysis, graphing, etc. I’ve decided to do this on my own server to get familiar with RRD, and PHP again rather then using a Web-based service like Xively.

Also given that Google values a thermostat company, Nest, at $3.2bn the temperature and other sensor data is clearly valuable in someone’s mind 🙂

As I sketched up a very simple GET submission of the data to a PHP page, it occurred to me that I didn’t want just anybody to be able to submit sensor data. So the question is ‘How can I allow a very simple datalogger to send in data, but block all others?’. For me one possible approach is HTTP Header Enrichment.

HTTP Header Enrichment is most commonly used by mobile operators to add interesting custom fields to HTTP Header requests, usually at the GGSN or just after in the Services Gateway. The typical application is to add the MSISDN or IMSI to HTTP requests going to internal self-service portals so that sign-in is not required from a mobile device.

Typical format used for this is X-something. This is not a formal requirement, as RFC2616 basically allows most things to be used in the headers, but was borrowed from RFC2047 Section 5 (since deprecated). This is a convention, not a requirement but it is one that I will use here.

Basically the approach is to have the server side code check for the custom header, and its value and if it matches what the client sends, then log the data. If not, then return HTTP 404 – Page Not Found.

<?php
$auth_key="my_shared_secret";

if($auth_key == $_SERVER['HTTP_X_AUTH_KEY']){

// Code to handle sensor data

}
else {
   error_log("Auth Key Incorrect. Received value was $_SERVER['HTTP_X_AUTH_KEY']\n");
   header('HTTP/1.0 404 Not Found');
   exit;
}
>

$_SERVER is an array containing information such as headers, paths, and script locations. The entries in this array are created by the web server. There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here. HTTP_ is also added automatically as a prefix, and the hyphens (-) are replaced with underscores (_).

So on the client (arduino side) the code segment looks like:

   client.print("GET /path/file.php?t=");
   client.print(t1);
   client.print("&v=");
   client.print(v1);
   client.println(" HTTP/1.1");
   client.println("User-agent: Arduino Uno");
   client.println("Host: flat-planet.net");
   client.println("X-AUTH-KEY: my_shared_secret");
   client.println("Accept: text/html"); 
   client.println();

so we are sending X-AUTH-KEY and that is available to the server as HTTP_X_AUTH_KEY. As long as they match, all will work fine, and remember that X-AUTH-KEY can be anything, just ensure that it is meaningful for you.