Service synchronisation for Television And Related devices -- STAR

Service synchronisation for Television And Related devices -- STAR BBC Research and Development

BBC R & D North Lab Dock House MediaCityUK Salford M50 2LH UK +44 303 040 9510 michael.sparks@bbc.co.uk

General Internet Engineering Task Force template Service synchronisation for Television And Related devices (STAR) is a suite of application level protocols to enable network connected devices to correlate events on a broadcast system with events outside that broadcast system. It is a generic suite of protocols, that enables playback of content retrieved from over a network such that it is synchronised to a broadcast source. It also enables correlation of non-broadcast events (such as conversations) to broadcast events. Key features of STAR include: 1) The broadcast system does not require modification 2) It is designed to work with restricted clients limited to stream connections - such as web browsers 3) It is content agnostic. This specification describes the research implementation as it stands today, and is published as a starting point for further discussion.

The original specification of xml2rfc format is in RFC 2629.

Broadcast is a well understood single to many push medium, with modern television broadcast systems being digital broadcast systems. In the USA, the system is ATSC, in Europe DVB is common, with DVB-T, DVB-C and DVB-S widely deployed. Whilst such digital systems have variations, they fundamentally form a lossy data channel from a broadcaster to an audience at a fixed bit rate. This is generally then received by a display which is a shared resource, broadly controlled by the occupants of a single room. Thus what is displayed or played back on the shared display must be of interest to all users of that device (or well known arguments ensue). Digital broadcasts carry a variety of non audio/video data including subtitles, audio description (also called narrative subtitles for the blind), interactive applications, as well as information bundles similar to web pages. Each addition to the broadcast uses up the scarce resource. More data can be squeezed in at the expense (primarily) of picture quality. Each change presents diminishing returns for the broadcaster, despite benefits to the audience, due to the nature of broadcast being a single shared push channel. Furthermore, in order to "fake" a pull approach for data, information on a data channel - such as electronic programme guide (EPG) information - is has to be repeatedly pushed in order to allow clients timely access to data. This data carousel (as it is termed) squeezes the transmission channel even further. Unlike broadcast clients, network clients control their local communications channel, leading to clients pulling services from servers. Being pull based, they are by their nature elective and therefore extremely good for personalised experiences. They can tend to suffer efficiency concerns for very large concurrent audiences, in particular servicing large audiences efficiently without content injection concerns is still hard. Work has previously been done have investigating how to marry the broadcast and IP world. However in many cases they have sought to change the inherent nature of either broadcast from it's shared receiver audio or video nature, or to change network delivery to take control away from the receiver. That is to try and change the network delivery from a pull medium to a push medium. Service Synchronisation for Television and Related Devices (STAR) is predicated on the principle of using the broadcast data channel for push aspects of a service in a form useful for the majority of an audience, and using pull-based network delivery for personalisation. These personalisations need to be synchronised relative to the programme being broadcast, and presented to the user at appropriate times. To do this we expose key information about the broadcast data channel over the network, along with defining a means of synchronising with the broadcast data channel, and also a standard play out data format which can be used by a generic client to play out content synchronised to the broadcast. STAR is also assumes that whilst custom clients are possible, clients are most likely to be implemented in restriction environments such as browsers or virtual machines residing in browsers. In practical terms this means that whilst it could operate on top of many transports, it is designed to primarily operate on top of either TCP or HTTP. Thus STAR comprises a small suite of application level protocols that seeks to work with each medium appropriately, forming initial research results in this area. This specification describes the research implementation as it stands today, and is published as a starting point for further discussion. In particular while each protocol could be specified separately, but describing them together retains important context.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."

This specification uses a number of terms to refer to the roles played by participants in, and objects of, a STAR system. An audio/visual transmission over radio or similar system that also includes a time and data signal - such as digital broadcasting or analogue broadcast with a teletext, etc. data channel. A broadcast using a digital broadcast standard such as Digital Video Broadcasting (DVB), or Advanced Television Systems Committee (ATSC). Digital broadcasts typically contain audio, video, subtitles, applications, and metadata regarding the broadcasts - in terms of content and transport. A standard receiver for a given broadcast system. The time specified in a broadcast signal, as recieved by a broadcast reciever. A broadcast receiver that stores metadata from a given broadcast service. It acts as a server on the network available to be queried by a client. (ie it bridges the push of broadcast and the pull from a network client) Data file that is used to schedule playback of events relative to given times based on event type A server that a client can retrieve play out scripts from as well as additional content. A network connected device capable of playing out 1 or more form of synchronised content. Performs synchronisation with the broadcast bridge, retrieves content from the content server for play out. The actual system clock of the client device. Assumed to be poor quality and unchangeable. A corrected software clock based synchronisation with the broadcast bridge. Does not have a defined accuracy level. A TCP socket listening on the broadcast bridge for a client to connect to. Provides a basic "NOW" time service for client application clocks to synchronised against. Connection is closed by the server. A TCP socket listening on the broadcast bridge for a client to connect to. Provides a basic "NOW" time service for client application clocks to synchronised against. Does this after receiving data from the client. All data sent by the client is echoed back to the client. Connection is closed by the server. A TCP socket listening on the broadcast bridge for a client to connect to. Provides a basic "NOW" time service for client application clocks to synchronised against. Does this after receiving data from the client. All data sent by the client is echoed back to the client. Connection is closed by the client.

STAR uses the same notational conventions and generic grammar as HTTP/1.1 as defined in RFC 2616. For the purposes of this document:

JSONRESPONSE is required to be a valid JSON object. JSON is defined in RFC 4627.

| | | | | | r | | B | | STAR ADDITIONAL SERVICES SERVER | | | | o | | r | | ^ ^ | | | | a | | i | +----|----------------------|-------+ | | | d | | d | | | | | | c | | g | +----|----------------------|-------+ | | | a | | e <-----> V V | | | | s | | | | STAR CLIENT | | | | t | | <-----> | | | +-----+ +-----+ +-----------------------------------+ | | | +------------------------------------------------------------+ ]]> STAR consists of 4 main subsystems: A broadcast system, including a broadcast system and a broadcast client A broadcast bridge A STAR client A STAR additional services server The STAR client protocol is specifically designed to allow clients to be implemented inside a web browser or similarly restricted environment (eg flash or java plugins). Tighter synchronisation accuracy could be achieved by mandating a less restricted environment, but to do so would restrict STAR's applicability & implementability needlessly. Communications in a STAR system includes: Broadcast within the broadcast system The broadcast bridge's reception and analysis of the broadcast Time synchronisation between the STAR client and the broadcast bridge Programme information services provided by the broadcast bridge to the STAR client Synchronised data services from the STAR additional services server provided to the STAR client. These fall into two categories: Play out scripts Additional data sources The rest of this section follows the communication in the system.

The broadcast system is a digital television service. Such broadcast systems have the following core characteristics: An audio and video (maybe) service per channel A time service giving the current time. For example the time and date (TDT) table in DVB suffices here. TDT data is typically broadcast once per second, and represents the time "now". A programme service describing what programme is on "now". In DVB the event information table information contains a "now and next" service. The now and next service data is sent regularly, but is additionally updated when the broadcast programme changes. Some analogue television services also contain this information, but for the purposes of discussion this document assumes a digital television service. This protocol assumes that the existing broadcast service and broadcast client (eg a TV) are left unmodified. If a service on a non-broadcast client is being played out simultaneously with the broadcast service, then this service needs to be synchronised to the time as received by a broadcast receiver.

The broadcast bridge bridges the "push" of the broadcast world, and the "pull" of the IP based world. In particular, it is a server that contains a broadcast client receiver, and makes available a time service to synchronise against, and now/next programme services over IP for network based clients. The broadcast bridge uses the time signal to synchronise a local server clock. In particular a DVB based broadcast bridge can retrieve TDT packets, and use their regularity to set a local clock time and rate of advance. The broadcast bridge also receives the now and next data services, and keeps track of what programmes are being broadcast. This information is then made available over IP. Additionally, the broadcast time at which the now and next information changes is monitored. For the purposes of STAR, this change time is denoted to be "time zero" for the given programme. It is worth noting that whether this is actually time zero depends upon the configuration of the broadcast service. Furthermore the accuracy of time zero also depends upon the configuration of the broadcast service. It is also possible for the broadcast service to include a special marker including the time the programme actually started via the related content table. Additionally, there may be other means to determine the start of the programme. The broadcast bridge is responsible for obtaining this time, and making this available to clients.

The broadcast bridge makes available a time service for the STAR client to synchronise against.

| . | | | S | | B | | | | | y | | r | |--------+ | | | s | | i | | | | | | t | | d <-----> TIME | . | | | e | | g | | SYNC | . | | | | m | | e | | | | | | | +-----+ +-----+ +-----------------------------------+ | | RF IP STAR CLIENT | | | +------------------------------------------------------------+ ]]> This has the following characteristics: The client can request the current time from the broadcast bridge. The client can request the current time from the broadcast bridge with a payload which the broadcast bridge includes in its response. The time services are available over both TCP and HTTP The current time service can be used to derive a broad view of time - that is the current time as seen by a broadcast receiver. This can be accurate within a delta proportional to the network round trip time. The echoing time service can be used to calculate an approximation of the network round trip time. This may be useful in circumstances where the network round trip time is likely to be too large relative to the additional service intended to be synchronised against the broadcast service. The reason for using TCP and HTTP and not UDP are as follows: A tool - dvbdate - exists that provides a means of configuring an NTP server, which can then be used for synchronising time over UDP. Restricted clients - such as browsers or plugins - were considered desirable. UDP is not available to browser based components TCP is commonly available from browser plugins HTTP is natively available to browser based clients Thus UDP has not been viewed as appropriate.

IP based programme services available are provided by the broadcast bridge to enable a client to determine which programme is currently being broadcast. This can be correlated with other IP based services to locate appropriate data on for playback synchronous to the broadcast service. Prerequisites for this to work: The programme services must include the actual start time of a programme as broadcast. This may be queried over TCP or HTTP, for the same reasons as the time services. The broadcast bridge also provides facilities for: Identifying what channels the bridge covers, by name and service id Summary information across all channels Detailed information on the channel's current state, based on channel or serviceid

PROG | | | | <----> | | SYNC | | | | S | | B | | | | | | y | | r | |--------+ | | | s | | i | . . | | | t | | d | . . | | | e | | g | . | | | | m | | e | . | | | | +-----+ +-----+ +-----------------------------------+ | | RF IP STAR CLIENT | | | +------------------------------------------------------------+ ]]>

The STAR additional services server provides 2 core services: Play out scripts, which describe what events to play out when Data storage for data to playback from playout scripts. Play out scripts are not required to be limited to playback of data from the data storage. In all cases it is expected that these scripts and data are to be retrieved over HTTP.

A client may have many output means, which can be considered to include text, links, audio, video, and event send messages to a serial port for controlling (for example) arduino based devices, synchronous to the broadcast. Three possible alternatives to a play out script delivered over HTTP are as follows: To repeatedly poll the server with a "what do I do now message". For services with low levels of service, this may be appropriate, but for nationwide services, this is not a scalable approach, and was discounted on that basis. To open a connection to the server, and wait for event data to be sent over the connection. Whilst this limits connection set up and tear down, this could for popular events require a server handle millions of connections held open for long periods of time and data delivered instantaneously to all the clients concurrently. This was not deemed scalable. The client opens an XMPP connection, and receiving data over that connection from an XMPP group. This is a promising approach, but raises the implementation bar to that of implementing an XMPP client. It also requires the client to remain connected. In all 3 cases, unlike the downloaded file approach, these approaches preclude pre-caching data for playback. For this reason, a play out file was considered more appropriate.

Playout scripts are files consisting of a list of events. This file is UTF8 encoded, and contains a JSON object. Events denote times into the programme, the type of the event, and an opaque data blob relating to the event. The interpretation of the blob depends on the type. 3 types are considered critical: Plain text Base 64 encoded data. URLs

Due to the fact that additional data sources may be linked to by an URL may be audio, video, text, web pages, and more. If the client does not understand how to interpret the URL, it should pass the interpretation over to a web browser.

shows all the subsystems and their interactions.

B | | | | | | | | r | | r | | Content | Play out | Additional | | | | o | | o | | Server | Scripts | data sources | | | | a | | a | | ^ | ^ | ^ | | | | d | | d | +-----|---------|-----------|-------+ | | | c | | c | | | | | | | a | | a | +-----|---------|-----------V-------+ | | | s | | s | | V | V | Output Dev 1 | | | | t | | t <-----> PROG | |--------------| | | | | | | | SYNC | | Output Dev 2 | | | | S | | B | | | Play out |--------------| | | | y | | r | |--------+ | Output Dev 3 | | | | s | | i | | | Core |--------------| | | | t | | d <-----> TIME | | ... | | | | e | | g | | SYNC | |--------------| | | | m | | e | | | | Output Dev N | | | +-----+ +-----+ +-----------------------------------+ | | STAR CLIENT | | | +------------------------------------------------------------+ ]]>

Clock synchronisation is a complex topic, and this specification takes a necessarily simplistic view for the following reasons: Expected clients include javascript within a browser. This means sync will happen over HTTP. The many layers involved limit the effectiveness of aiming for extremely tight sync. STAR time synchronisation is therefore primarily concerned with synchronising browser events, and simplicity aids implementation. For some applications, accuracy of within a second or so is acceptable. For others, accuracy down to 40ms is desirable. Going beyond this would appear to require a UDP based service.

The client connects to the broadcast time server port on the broadcast bridge. The client does not send any data. The server's response is a sequence of octets, that are terminated by the server closing the connection. The sequence of octets sent forms a TIMESTAMP as defined above. That time-stamp is a string representation of a floating point value. That float represents the number of seconds since the beginning of the Unix epoch - ie the number of seconds since 00:00:00 UTC on 1 January 1970. The time obtained is a broadcast time as defined above. This defines the broadcast view of time (BVT) according to a broadcast receiver at a given instant. These are received by the client at a given local clock (LC) times from the client clock. In order to gain a broad view of time, the client needs to get two such timestamps - BVT1 and BVT2. These correspond to local clock times LC1 and LC2. The further these sets of timestamps, the better. Using these times, the client can define a local application clock using BVT1, BVT2, LC1, and LC2. For brevity this is defined here in python:

The accuracy of this broad view of time application clock depends on the network latency between the client and the broadcast bridge. For some applications, this delay will be acceptable. For many applications it will be desirable to attempt to eliminate the network delta.

The client initialises a client application clock which is a BroadViewClock as defined in 2.1 above. The client connects to the echo broadcast time server port on the broadcast bridge. Upon connecting the client sends time request of the following form:

That is it send an octet stream which is a string representation of a float, representing a timestamp of the number of seconds since the start of the unix epoch, followed by a CRLF sequence. The server response is as follows:

The server then terminates the connection. BLOBRESPONSE as defined here is whatever data the client sends the server. Whilst the client MUST send data in the form defined as TIMEREQUEST, the server must be lenient and respond with whatever was sent as blob response. Using the BroadViewClock, the client can build on BroadViewClock to create a new application clock which removes the network delta as follows:

At this point the client then has a network corrected local clock locked to the same clock as broadcast, within a reasonable tolerance.

PROG | | | | <----> | | SYNC | | | | S | | B | | | | | | y | | r | |--------+ | | | s | | i | | . | | | t | | d | . | | | e | | g | . | | | m | | e | | | +-----+ +-----+ STAR CLIENT | | RF IP | | | +------------------------------------------------------------+ ]]> Programme Services are provided on a request/response basis. The client connects to the broadcast bridge programme port and sends a REQUEST matching the following:

Note that the command is terminated by a blank line. The server sends a RESPONSE as follows:

The response is terminated by closing the connection. If the status is ERROR, the client should handle the error gracefully. COMMANDTAG is always relative to the command the client sent to the server. Commands the broadcast bridge MUST implement: time echotime summary Commands the broadcast bridge SHOULD implement: services channels channel service Note: The server is expected to lower case all commands and arguments on the way into the server.

This provides an alternative interface to the timing subsystem, and can be used in much the same way. It has a higher parsing overhead, and hence speed penalty.

None

The response is a JSON object with 3 name value pairs: time - Number of seconds since the Unix Epoch. The timezone is defined to be UTC. elemental - 9 element array representation of the same time, consisting of: year - integer representing the full year month - integer in range 1..12 day of month - integer day of the month hour - integer minute - integer seconds - integer weekday - integer in range 0..6, where monday is 0. day of year - counting from 1 daylight savings flag 0 means no daylight savings adjustment has taken place 1 means time is adjusted for daylight savings textual - Again, the same time as a human readable time/date. This should be treated as human readable and machine opaque.

This provides an alternative interface to the timing subsystem, and can be used in much the same way. It has a higher parsing overhead, and hence speed penalty.

TIMESTAMP - as defined above

The response is a JSON object with 4 name value pairs: time - Number of seconds since the Unix Epoch. The timezone is defined to be UTC. elemental - 9 element array representation of time as defined before in section 4.1.2 textual - Same time as a human readable time/date. As in 4.1.2 this is defined as machine opaque and human readable. echo - Contains whatever the client sent as TIMESTAMP

Provides a quick lookup mechanism of channel name, programme and start time.

None

The response is a JSON object with as many name value pairs as channels the broadcast bridge can receive. Each pair has the same format: channelname - which may be either: the human readable name of the channel from the broadcasting system The symbolic service id for the channel on this broadcast system. A value is an array consisting of 2 values First value is TIMESTAMP when programme started Second value is Programme name This format means that the summary contains duplication of information. The reason for this is to enable clients to be simpler to implement.

This command returns the list of services available on the bridge. The reason for this is to accommodate automated lookups based upon service ids used in the broadcast system rather than based on channel name.

None

The response is a JSON object which is an array of integers, each one representing the service ids which may be queried.

This command returns the list of channels available on the bridge. This uses the names of the channels as used by the broadcast system.

None

The response is a JSON object which is an array of strings, where each string is a channel name available on the bridge.

This command returns all the information the broadcast bridge has on a particular channel at that instant. This provides a bridged version of the current "now and next" information for the channel. In particular, the dates and time information are provided "as is" from the broadcast system.

*OCTET - String that represents a channel name

Contains a JSON object with 2 name value pairs: channel - value is a string with the channel name info - value is another JSON object with 3 name value pairs: changed - value is a floating point value which is the number of seconds since the Unix Epoch. Represents when the now and next information changed. NOW - now/next JSON object (see below) where the "when" value is "NOW" NEXT - now/next JSON object (see below) where the "when" value is "NEXT" A now/next JSON object is a JSON object with 8 name value pairs: name - string with the name of the programme the now/next object refers to description - a string containing a human readable description of the programme. startdate - an array of integers, representing [year, month, day] starttime - an array of integers, representing [hours, minutes, seconds] duration - an array of integers, representing [hours, minutes, seconds] when - a string which is either "NOW" or "NEXT" service - an integer which is the broadcast service id transportstream - an integer which is the broadcast service id

This command returns all the information the broadcast bridge has on a particular channel, identified by broadcast system service id at that instant.

*OCTET - String that represents a service number

The response format is the same as the command "channel"

This provides a basic web based API to access the same commands as the TCP command format. The broadcast bridge presents itself on the following form of URL:

http://example.com/bridge?command=&args= ]]> The response type for URLs of the format above is application/json, and the format/structure matches the TCP version precisely. CMD is any command from the TCP version which does not take any arguments. CMDA is any command from the TCP version which takes at least one argument. The argument it takes is passed through in args.

After synchronising a clock, and after retrieving programme start times, the STAR client (which may be a javascript based client inside a web page) can then choose to retrieve a play out script from the STAR additional services server. How this happens precisely is left as an exercise to an implementer. One approach that is feasible is as follows: A broadcaster publishes a schedule online with programme names, times and a unique id. Using the broadcast bridge, the STAR client identifies the current programme, allowing the identification of the unique id. The STAR client can then request from a web service the specific play out script for that programme. There are clearly other feasible approaches, and STAR is not prescriptive about any particular approach. That play out script MAY be delivered over HTTP.

The MIME type of play out script is application/json.

The STAR play out script is a UTF8 encoded contains a JSON encoded object. The JSON object: is an array of events Each event is an array consisting of 3 values: The first value is a float representing a timestamp - see 7.3 The second is an event type - see 7.4 The third is event data - see 7.5

Timestamps are defined to be relative to time zero of the programme as defined above.

Event type is defined as follows

ie An optional (encoding tag and semicolon) preceding a base type.

A base type may be: a standard MIME Type An application's custom type. As defined above an application's custom type is defined in terms of DOMAINNAME followed by a "/" followed by any text. It is up to the entity that owns the domain DOMAINNAME to publish and manage that namespace.

The encoding tag defines how to interpret the encoding of the event data: "INLINE" - means to treat the event data as raw data of the type given (eg textual) "BASE64" - means that the event data inline is the data of the given datatype, but is base64 encoded. (This allows for example a small audio/wav file to be represented inline. This is expected to be a rare necessity but potentially useful) "URL" - means to treat the event data as an URL to download and interpret at the given time. Given the encoding tag is optional, if the encoding tag is not supplied, then the following rules are used to determine the encoding: If the datatype tag is the MIME type "text/plain" then the encoding tag is inline Otherwise the encoding tag is assumed to be URL (This allows for example a small audio/wav file to be represented inline. This is expected to be a rare necessity but potentially useful)

The actual event data interpretation is just a string. If the data encoding is an URL: Then the STAR client accesses the resource indicated by the URL and uses that resource as the event data. If the data encoding is BASE64: Then the STAR client decodes the BASE64 encoded data, and uses that as the event data Otherwise the data encoding is INLINE: This means the STAR client just treats the raw data as the event data. The data is then interpreted according to local rules for the given MIME type.

Given the following (tidied) example:

Time 0 is interpreted as as text/plain - which may be displayed on a screen, or spoken. Time 0.5 is interpreted as an URL to download and then treat as an audio/wav file. Time 1.0 is interpreted an inline embedded ".ico" file, which is base 64 encoded in the data field. Time 1.5 is interpreted as an URL to download and then treat according to the rules defined by the entity owning "example.com" as the datatype "example.com/game". Time 2.0 is interpreted as an URL to download and then treat according to the rules defined by the entity owning "example.com" as the datatype "example.com/serial". For example, this could mean to take whatever data is sent back and to send that to the serial port, controlling an arduino controlled robot.

Future expansion of datatype tags is provided through the standard IANA MIME types, and also by the custom datatype tag formats which may be managed by the owner of a domain name.

This memo includes no request to IANA. This document describes an experimental protocol. It re-uses the existing IANA namespace for defining datatype tags, and additionally defines a mechanism for users of the protocol to define their own namespace for defining datatype tags, and maintaining this within their organisation. As a result this protocol has no IANA considerations.

All drafts are required to have a security considerations section. See RFC 3552 for a guide. This section is meant to inform application developers, information providers, and users of the security limitations in STAR as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks. It is not warranted to be exhaustive.

The server enables the maintainer of the broadcast bridge to identify what programmes particular IPs are using. If the maintainer of the broadcast bridge or additional services server store cookies, then they are potentially able to identify particular individuals. Since the event file format is defined to automatically download URLS in the file, if the client does this at the same time as the moment in the programme occurs, then the maintainer of the broadcast bridge is able to track which users are watching how much of what programme through the broadcast bridge log data. The client is not required to download the URLs at that instant, and may download the content beforehand, which mitigates this risk.

JSON format data is directly interpretable in a number of languages, including actionscript, javascript, and python. If the creator of the client fails to use a parser, this opens the client up to well known attacks. Similarly, assuming BASE64 encoded data is BASE64 encoded without any conversion errors would open up the client to well known attacks.

It is possible for a badly crafted file to cause a denial of service attack on the additional services store. For example, if all the timestamps were "0", this would mean "interpret all these events as being at time 0". This could cause a very large number of concurrent requests against the additional services store, albeit by accident. Hijacking of a site and replacement of the play out script with a malicious play out script could result in a similar effect.

This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for RFC 822. Also, this specification is inspired by HTTP to be content agnostic and extensible, and additionally by the semantic web approach of allowing namespaces interpretation to be owned by a group. The time synchronisation approach is based very loosely on a simplification of the core ideas of a number of time synchronisation protocols.

&RFC2119; &RFC2629; &RFC3552;

This becomes an Appendix.