| Audio/Video Transport Core Maintenance | A.M. Williams |
| Internet-Draft | Audinate |
| Intended status: Standards Track | R. van Brandenburg |
| Expires: August 29, 2012 | TNO |
| K. Gross | |
| AVA Networks | |
| February 28, 2012 |
RTP Clock Source Signalling
draft-williams-avtcore-clksrc-00
NTP timestamps are used by several RTP protocols for synchronisation and statistical measurement. This memo specificies SDP signalling identifying NTP timestamp clock sources and SDP signalling identifying the media clock sources in a multimedia session.
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 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 29, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
RTP protocols use NTP format timestamps to facilitate media stream synchronisation and for providing estimates of round trip time (RTT) and other statistical parameters.
Information about media clock timing exchanged in NTP format timestamps may come from a clock which is synchronised to a global time reference, but this cannot be assumed nor is there a standardised mechanism available to indicate that timestamps are derived from a common reference clock. Therefore, RTP implementations typically assume that NTP timestamps are taken using unsynchronised clocks and must compensate for absolute time differences and rate differences. Without a shared reference clock, RTP can time align flows from the same source at a given receiver using relative timing, however tight synchronisation between two or more different receivers (possibly with different network paths) or between two or more senders is not possible.
High performance AV systems often use a reference media clock distributed to all devices in the system. The reference media clock is often distinct from the the reference clock used to provide timestamps. A reference media clock may be provided along with a audio or video signal interface, or via a dedicated clock signal (e.g. genlock or audio word clock. If sending and receiving media clocks are known to be synchronised to a common reference clock, performance can improved by minimising buffering and avoiding rate conversion.
This specification defines SDP signalling of timestamp clock sources and media reference clock sources.
Timestamp clock source and reference media clock signalling benefit applications requiring synchronised media capture or playout and low latency operation.
Exmaples include, but are not limited to:
The definitions of streams, sources and levels of information in SDP descriptions follow the definitions found in Source-Specific Media Attributes in the Session Description Protocol (SDP) [RFC5576].
The NTP timestamps used by RTP are taking by reading a local clock at the sender or receiver. This local clock may be synchronised to another clock (time source) by some means or it may be unsynchronised. A variety of methods are available to synchronise local clocks to a reference time source, including network time protocols (e.g. NTP [RFC5905]) and radio clocks like GPS [XXX].
The following sections describe and define SDP signalling indicating whether and how the local timestamping clock in an RTP sender/receiver is synchronised to a reference clock.
Two or more local clocks that are sufficiently synchronised will produce timestamps for a given event which are effectively identical for the purposes of RTP. A local clock in one RTP sender/receiver can be considered equivalent to a local clock in another RTP sender/receiver providing they are sufficiently synchronised such that timestamps produced by one clock are indistinguishable from timestamps produced by the other. The timestamps produced by equivalent local clocks in two or more RTP senders/receivers receivers can be directly compared.
One or more local clocks are equivalent if they are synchronised to a single master clock via a network time protocol (e.g. XXX NTP, 802.1AS, IEEE1588v2).
One or more local clocks are equivalent if they are synchronised to any member of a set of master clocks provided that the set of master clocks are synchronised.
One or more local clocks are equivalent if they are synchronised to a clock master providing a global time reference (e.g. XXX GPS, Gallileo). Some network time protocols (e.g. XXX PTP) may allow master clocks to explicitly indicate that they are "traceable" back to a global time reference.
A single NTP server is identified by identified by hostname (or IP address) and an optional port number. If the port number is not indicated, it is assumed to be the standard NTP port (123) XXX.
Two or more NTP servers may be listed to indicate that they are interchangeable. RTP senders/receivers can use any of the listed NTP servers to govern a local clock that is equivalent to a local clock slaved to a difference server.
XXX Question: Does NTP carry traceability information? Or is this implicit somehow in the stratum? Apparently there are some bits in the leap seconds functionality which talk about "tracking"..
The IEEE1588 Precision Time Protocol (PTP) family of clock synchronisation protocols provide a shared reference clock in an network - typically a LAN. IEEE1588 provides sub-microsecond synchronisation between devices on a LAN and typically locks within seconds at startup. With support from Ethernet switches, IEEE1588 protocols can achieve nanosecond timing accuracy in LANs. Network interface chips and cards supporting hardware time-stamping of timing critical protocol messages are also available.
When using IEEE1588 clock synchronisation, networked AV systems can achieve sub 1 microsecond time alignment accuracy when rendering AV signals and can support latencies less than 1ms through a gigabit LAN.
Three flavours of IEEE1588 are in use today:
Each IEEE1588 clock is identified by a globally unique EUI-64 called a "ClockIdentity". A slave clock using one of the IEEE1588 family of network time protocols acquires the ClockIdentity/EUI-64 of the grandmaster clock that is the ultimate source of timing information. A master clock which is itself slaved to another master clock passes the grand master clock identity through to its slaves.
Several instances of the IEEE1588v1/v2 protocol may operate independently on a single network, forming distinct PTP network protocol domains each of which may have a different master clock. As the IEEE1588 standards have developed, the definition of PTP domains has changed. IEEE1588v1 identifies protocol subdomains by a textual name and IEEE1588v2 identifies protocol domains using a numeric domain number. 802.1AS is a Layer2 profile of IEEE1588v2 supporting a single numeric clock domain (0). This specification assumes that an IEEE1588 clock master for multiple domains will provide the same timing information to all domains or that each clock domain has a different master. In other words, this specification assumes that a timing domain can be uniquely identified using the ClockIdentity of the grandmaster clock alone.
The PTP family of protocols employ a distributed election protocol called the "Best Master Clock Algorithm (BMCA) to determine the active clock master. The clock master choices available to BMCA can be restricted or favourably biased by setting stratum values, preffered master clock bits, or other parameters to influence the election process. In some systems it may be desirable to limit the number of possible PTP clock masters to avoid re-signalling timestamp clock sources when the clock master changes.
Global reference clocks provide a source of tracable time, typically via a hardware radio receiver interface. Examples include GPS and Gallileo. Apart from the name of the reference clock system, no further identification is required.
At the time of writing, it is common for RTP senders/receivers not to synchronise their local timestamp clock to a master. An unsynchronised clock such as a quartz oscillator is identified as a "local" reference clock.
In some systems, all RTP senders/receivers may use a timetsamp clock synchronised to a reference clock that is not provided by one of the methods listed above. Examples may include the reference time information provided by digital television or cellular services. These sources are identified as "private" reference clocks. All RTP senders/receivers in a session using a private reference clock are assumed to have a mechanism outside this specification confirming that their local timestamp clocks are equivalent.
A timestamp clock source may be labelled "traceable" if it is known to be sourced from a global time reference such as TAI or UTC XXX. Providing adjustments are made for differing time bases, timestamps taken using a clocks synchronised to a traceable time source can be directly compared even if the clocks are synchronised to different servers or via different mechanisms. Any traceable timestamp clock source can be considered equivalent to another traceable timestamp clock source and the timestamps may be directly compared.
Since any NTP or PTP server providing traceable time can be considered equivalent, it is not necessary to identify traceable time servers by protocol address.
Network time protocols periodically exchange timestamped messages between servers and clients. Assuming RTP sender/receiver clocks are based on commonly available quartz crystal hardware, tight synchronisation requires frequent exchange of synchronisation messages.
Unfortunately, in some implementations, it is not possible to control the frequency of synchronisation messages nor is it possible to discover when the last sychronisation message occured. In order to provide a measure of confidence that the timestamp clock is sufficiently synchronised, an optional timestamp may be included in the SDP clock source signalling. In addition, the frequency of synchronisation message may also optionally be provided.
The optional timestamp and synchronisation frequency parameters provide an indication of synchronisation quality to the receiver of those parameters. If the synchronisation confidence timestamp is far from the timestamp clock at the receiver of the parameters, it can be assumed that synchronisation has not occured recently or the timestamp reference clock source is wrongly configured or cannot be contacted. In this case, the receiver can take action to prevent unsynchronised playout or may fall back to assuming that the timestamp clocks are not synchronised.
Synchronisation frequency is expressed as an 8-bit excess-127 field which is the base 2 logarithm of the frequency in HZ. The synchronisation frequencies represented by this field range from 2^-127 Hz to 2^+128 Hz. The field value of 127 corresponds to an update frequency of 1 Hz.
Specification of the timestamp reference clock source may at all levels of an SDP description (see level definitions [definitions] earlier in this document for more information).
Timestamp clock source signalling included at session-level provides default parameters for all RTP sessions and sources in the session description. More specific signalling included at the media-level overrides default session-level signalling. Further, source-level signalling overrides timestamp clock source signalling at the enclosing media-level and session-level.
If timestamp clock source signalling is included anywhere in an SDP description, it must be properly defined for all levels in the description. This may simply be achieved by providing default signalling at the session level.
Timestamp reference clock parameters may be repeated at a given level (i.e. for a session or source) to provide information about additional servers or clock sources. If the attribute is repeated at a given level, all clocks described at that level are assumed to be equivalent. Traceable clock sources MUST NOT be mixed with clock sources having explicit addresses for a given source or session. Unless synchronisation confidence information is available for each of the reference clocks listed at a given level, it SHOULD only be included with the first reference clock source attribute at that level.
Note that clock source parameters may change from time to time, for example, as a result of a PTP clock master election. The SIP XXX protocol supports re-signalling of updated SDP information, however other protocols may require additional notification mechanisms.
timestamp-refclk = "a=ts-refclk:" clksrc SP [sync-confidence] CRLF
clksrc = ntp / ptp / gps / gal / local / private
ntp = "ntp=" ntp-server-addr
ntp-server-addr = host [ ":" port ]
ntp-server-addr =/ "traceable" )
ptp = "ptp=" ptp-version ":" ptp-gmid
ptp-version = "IEEE1588-2002"
ptp-version =/ "IEEE1588-2008"
ptp-version =/ "IEEE802.1AS-2011"
ptp-gmid = EUI64
ptp-gmid =/ "traceable"
gps = "gps"
gal = "gal"
local = "local"
private = "private" [ ":" "traceable" ]
sync-confidence = sync-timestamp [SP sync-frequency]
sync-timestamp = sync-date SP sync-time SP sync-UTCoffset
sync-date = 4DIGIT "-" 2DIGIT "-" 2DIGIT
; yyyy-mm-dd (e.g., 1982-12-02)
sync-time = 2DIGIT ":" 2DIGIT ":" 2DIGIT "." 3DIGIT
; 00:00:00.000 - 23:59:59.999
sync-UTCoffset = ( "+" / "-" ) 2DIGIT ":" 2DIGIT
; +HH:MM or -HH:MM
sync-frequency = 2HEXDIG
; If N is the field value, HZ=2^(N-127)
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
domainlabel = alphanum
=/ alphanum *( alphanum / "-" ) alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*DIGIT
EUI-64 = 7(HEXDIG "-") 2HEXDIG
Figure 2 shows an example SDP description with a timestamp reference clock source defined at the session-level.
v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly a=ts-refclk:ntp=traceable m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000
Figure 3 shows an example SDP description with timestamp reference clock definitions at the media-level overriding the session-level defaults. Note that the synchronisation confidence timestamp appears on the first attribute at the media-level only.
v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly a=ts-refclk:local m=audio 49170 RTP/AVP 0 a=ts-refclk:ntp=203.0.113.10 2011-02-19 21:03:20.345+01:00 a=ts-refclk:ntp=198.51.100.22 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
Figure 4 shows an example SDP description with a timestamp reference clock definition at the source-level overriding the session-level default.
v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly a=ts-refclk:local m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
RTP implementation is simplified by using a clock reference with a timescale which does not include leap seconds. IEEE 1588, GPS and other TAI (Inernational Atomic Time) references do not include leap seconds. NTP time, operating system clocks and other UTC (Coordinated Universal Time) references include leap seconds (though the ITU is studying a proposal which could eventually eliminate leap seconds from UTC).
Leap seconds are potentially scheduled at the end of the last day of December and June each year. NTP inserts a leap second at the beginning of the last second of the day. This results in the clock freezing for one second immediately prior to the last second of the affected day. Most system clocks insert the leap second at the end of the last second. This results in repetition of the last second of the day. Generating or using timestamps during the entire last second of a day on which a leap second has been scheduled should therefore be avoided. Note that the period to be avoided has a real-time duration of two seconds.
It is also important that all participants correctly implement leap seconds and have a working communications channel to receive notification of leap second scheduling. Without prior knowledge of leap second schedule, NTP servers and clients may be offset by exactly one second with respect to their UTC reference. This potential discrepancy begins when a leap second occurs and ends when all participants receive a time update from a server or peer (which, depending on the operating system and/or implementation, could be anywhere from a few minutes to a week). Such a long-lived discrepancy can be particularly disruptive to RTP operation.
Apart from the long-lived discrepancy due to dependence on both timing (e.g. NTP) updates and leap seconds scheduling updates, there is also the potential for a short-lived timing discontinuity having an effect on RTP playout timing (even though leap seconds are quite rare).
If a timescale with leap seconds is used for RTP:
A timestamp clock source (ie media clock is locked to a reference clock like NTP, GPS, etc) Reference clock source..
An RTP session.. This should be an SSRC within an RTP session. Include IP address and port.
An IEEE 1722 stream, identified by a Stream ID.
The SDP attribute "ts-clksrc" defined by this document is registered with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"):
Attribute name: ts-refclk
Long form: Timestamp reference clock source
Type of name: att-field
Type of attribute: session, media and source level
Subject to charset: no
Purpose: See sections 1-4 of this document
Reference: This document
Values: see this document and registrations below
The attribute has an extensible parameter field and therefore a registry for these parameters is required. This document creates an IANA registry called the Timestamp Reference Clock Source Parameters Registry. It contains the six parameters defined in Figure 1: "ntp", "ptp", "gps", "gal", "local", "private".
| [1] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [2] | Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. |
| [3] | Lennox, J., Ott, J. and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. |
| [1] | Mills, D., Martin, J., Burbank, J. and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. |
| [2] | Brandenburg, R, Stokking, H, Deventer, O, Niamut, O, Walraven, F, Vaishnavi, I, Boronat, F and M Montagud, "RTCP for inter-destination media synchronization", Internet-Draft draft-ietf-avtcore-idms-01, July 2011. |
| [3] | Institute of Electrical and Electronics Engineers, "1588-2002 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2002, 2002. |
| [4] | Institute of Electrical and Electronics Engineers, "1588-2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008, 2008. |
| [5] | Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", . | , "