draft-ietf-avtcore-clksrc-02.txt   draft-ietf-avtcore-clksrc-03.txt 
Audio/Video Transport Core Maintenance A. Williams Audio/Video Transport Core A. Williams
Internet-Draft Audinate Maintenance Audinate
Intended status: Standards Track K. Gross Internet-Draft K. Gross
Expires: August 23, 2013 AVA Networks Intended status: Standards Track AVA Networks
R. van Brandenburg Expires: September 19, 2013 R. van Brandenburg
H. Stokking H. Stokking
TNO TNO
February 19, 2013 March 18, 2013
RTP Clock Source Signalling RTP Clock Source Signalling
draft-ietf-avtcore-clksrc-02 draft-ietf-avtcore-clksrc-03
Abstract Abstract
NTP timestamps are used by several RTP protocols for synchronisation NTP format timestamps are used by several RTP protocols for
and statistical measurements. This memo specifies SDP signalling synchronisation and statistical measurements. This memo specifies
identifying NTP timestamp clock sources and SDP signalling SDP signalling identifying timestamp reference clock sources and SDP
identifying the media clock sources in a multimedia session. signalling identifying the media clock sources in a multimedia
session.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 43 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2013. This Internet-Draft will expire on September 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 29 skipping to change at page 3, line 29
RTP can time align flows from the same source at a given receiver RTP can time align flows from the same source at a given receiver
using relative timing, however tight synchronisation between two or using relative timing, however tight synchronisation between two or
more different receivers (possibly with different network paths) or more different receivers (possibly with different network paths) or
between two or more senders is not possible. between two or more senders is not possible.
High performance AV systems often use a reference media clock High performance AV systems often use a reference media clock
distributed to all devices in the system. The reference media clock distributed to all devices in the system. The reference media clock
is often distinct from the reference clock used to provide is often distinct from the reference clock used to provide
timestamps. A reference media clock may be provided along with an timestamps. A reference media clock may be provided along with an
audio or video signal interface, or via a dedicated clock signal audio or video signal interface, or via a dedicated clock signal
(e.g. genlock [19] or audio word clock [20]). If sending and (e.g. genlock [9] or audio word clock [10]). If sending and
receiving media clocks are known to be synchronised to a common receiving media clocks are known to be synchronised to a common
reference clock, performance can improved by minimising buffering and reference clock, performance can improved by minimising buffering and
avoiding rate conversion. avoiding rate conversion.
This specification defines SDP signalling of timestamp clock sources This specification defines SDP signalling of timestamp clock sources
and media reference clock sources. and media reference clock sources.
2. Applications 2. Applications
Timestamp clock source and reference media clock signalling benefit Timestamp clock source and reference media clock signalling benefit
applications requiring synchronised media capture or playout and low applications requiring synchronised media capture or playout and low
latency operation. latency operation.
Examples include, but are not limited to: Examples include, but are not limited to:
Social TV : RTCP for inter-destination media synchronization [9] Social TV : RTCP for inter-destination media synchronization [11]
defines social TV as the combination of media content consumption defines social TV as the combination of media content consumption
by two or more users at different devices and locations and real- by two or more users at different devices and locations and real-
time communication between those users. An example of Social TV, time communication between those users. An example of Social TV,
is where two or more users are watching the same television is where two or more users are watching the same television
broadcast at different devices and/or locations, while broadcast at different devices and/or locations, while
communicating with each other using text, audio and/or video. A communicating with each other using text, audio and/or video. A
skew in the media playout of the two or more users can have skew in the media playout of the two or more users can have
adverse effects on their experience. A well-known use case here adverse effects on their experience. A well-known use case here
is one friend experiencing a goal in a football match well before is one friend experiencing a goal in a football match well before
or after other friends. or after other friends.
skipping to change at page 5, line 28 skipping to change at page 5, line 28
source level : Source level information applies to a RTP media source level : Source level information applies to a RTP media
stream Source-Specific Media Attributes in the Session Description stream Source-Specific Media Attributes in the Session Description
Protocol (SDP) [3] defines how source-level information is Protocol (SDP) [3] defines how source-level information is
included into an SDP session description. included into an SDP session description.
traceable time : A clock is considered to provide traceable time if traceable time : A clock is considered to provide traceable time if
it can be proven to be synchronised to International Atomic Time it can be proven to be synchronised to International Atomic Time
(TAI). Coordinated Universal Time (UTC) is a time standard (TAI). Coordinated Universal Time (UTC) is a time standard
synchronized to TAI. UTC is therefore also considered traceable synchronized to TAI. UTC is therefore also considered traceable
time once leap seconds have been taken unto account. GPS [10] is time once leap seconds have been taken unto account. GPS [12] is
commonly used to provide a TAI traceable time reference. Some commonly used to provide a TAI traceable time reference. Some
network time synchronisation protocols (e.g. PTP [11], NTP) can network time synchronisation protocols (e.g. PTP [13], NTP) can
explicitly indicate that the master clock is providing a traceable explicitly indicate that the master clock is providing a traceable
time reference over the network. time reference over the network.
4. Timestamp Reference Clock Source Signalling 4. Timestamp Reference Clock Source Signalling
The NTP timestamps used by RTP are taken by reading a local real-time The NTP format timestamps used by RTP are taken by reading a local
clock at the sender or receiver. This local clock may be real-time clock at the sender or receiver. This local clock may be
synchronised to another clock (time source) by some means or it may synchronised to another clock (time source) by some means or it may
be unsynchronised. A variety of methods are available to synchronise be unsynchronised. A variety of methods are available to synchronise
local clocks to a reference time source, including network time local clocks to a reference time source, including network time
protocols (e.g. NTP [12]) and radio clocks (e.g. GPS [10]). protocols (e.g. NTP [14], PTP [13]) and radio clocks (e.g. GPS
[12]).
The following sections describe and define SDP signalling, indicating The following sections describe and define SDP signalling, indicating
whether and how the local timestamping clock in an RTP sender/ whether and how the local timestamping clock in an RTP sender/
receiver is synchronised to a reference clock. receiver is synchronised to a reference clock.
4.1. Clock synchronization 4.1. Clock synchronization
Two or more local clocks that are sufficiently synchronised will Two or more local clocks that are sufficiently synchronised will
produce timestamps for a given RTP event can be used as if they came produce timestamps for a given RTP event can be used as if they came
from the same clock. Providing they are sufficiently synchronised, from the same clock. Providing they are sufficiently synchronised,
skipping to change at page 6, line 48 skipping to change at page 6, line 49
synchronisation protocols provides a shared reference clock in an synchronisation protocols provides a shared reference clock in an
network - typically a LAN. IEEE 1588 provides sub-microsecond network - typically a LAN. IEEE 1588 provides sub-microsecond
synchronisation between devices on a LAN and typically locks within synchronisation between devices on a LAN and typically locks within
seconds at startup. With support from Ethernet switches, IEEE 1588 seconds at startup. With support from Ethernet switches, IEEE 1588
protocols can achieve nanosecond timing accuracy in LANs. Network protocols can achieve nanosecond timing accuracy in LANs. Network
interface chips and cards supporting hardware time-stamping of timing interface chips and cards supporting hardware time-stamping of timing
critical protocol messages are also available. critical protocol messages are also available.
Three flavours of IEEE 1588 are in use today: Three flavours of IEEE 1588 are in use today:
o IEEE 1588-2002 [13]: the original "Standard for a Precision Clock o IEEE 1588-2002 [15]: the original "Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control Synchronization Protocol for Networked Measurement and Control
Systems". This is also known as IEEE1588v1 or PTPv1. Systems". This is also known as IEEE1588v1 or PTPv1.
o IEEE 1588-2008 [11]: the second version of the "Standard for a o IEEE 1588-2008 [13]: the second version of the "Standard for a
Precision Clock Synchronization Protocol for Networked Measurement Precision Clock Synchronization Protocol for Networked Measurement
and Control Systems". This is a revised version of the original and Control Systems". This is a revised version of the original
IEEE1588-2002 standard and is also known as IEEE1588v2 or PTPv2. IEEE1588-2002 standard and is also known as IEEE1588v2 or PTPv2.
IEEE 1588-2008 is not protocol compatible with IEEE 1588-2002. IEEE 1588-2008 is not protocol compatible with IEEE 1588-2002.
o IEEE 802.1AS [14]: "Timing and Synchronization for Time Sensitive o IEEE 802.1AS [16]: "Timing and Synchronization for Time Sensitive
Applications in Bridged Local Area Networks". This is a Layer-2 Applications in Bridged Local Area Networks". This is a Layer-2
only profile of IEEE 1588-2008 for use in Audio/Video Bridged LANs only profile of IEEE 1588-2008 for use in Audio/Video Bridged LANs
as described in IEEE 802.1BA-2011 [15]. as described in IEEE 802.1BA-2011 [17].
Each IEEE 1588 clock is identified by a globally unique EUI-64 called Each IEEE 1588 clock is identified by a globally unique EUI-64 called
a "ClockIdentity". A slave clock using one of the IEEE 1588 family a "ClockIdentity". A slave clock using one of the IEEE 1588 family
of network time protocols acquires the ClockIdentity/EUI-64 of the of network time protocols acquires the ClockIdentity/EUI-64 of the
grandmaster clock that is the ultimate source of timing information grandmaster clock that is the ultimate source of timing information
for the network. A boundary clock which is itself slaved to another for the network. A boundary clock which is itself slaved to another
boundary clock or the grandmaster passes the grandmaster boundary clock or the grandmaster passes the grandmaster
ClockIdentity through to its slaves. ClockIdentity through to its slaves.
Several instances of the IEEE 1588 protocol may operate independently Several instances of the IEEE 1588 protocol may operate independently
skipping to change at page 14, line 21 skipping to change at page 14, line 21
aligned playout of two or more RTP sources still relies upon NTP aligned playout of two or more RTP sources still relies upon NTP
timestamps supplied via RTCP SRs or by the RFC6051 timestamp header timestamps supplied via RTCP SRs or by the RFC6051 timestamp header
extension. extension.
In a given system, master clock identifiers must be unique. Such In a given system, master clock identifiers must be unique. Such
identifiers MAY be manually configured, however 17 octet string identifiers MAY be manually configured, however 17 octet string
identifiers SHOULD be generated according to the "short-term identifiers SHOULD be generated according to the "short-term
persistent RTCP CNAME" algorithm as described in RFC6222 [7]. persistent RTCP CNAME" algorithm as described in RFC6222 [7].
A reference stream can be an RTP stream or AVB stream based on the A reference stream can be an RTP stream or AVB stream based on the
IEEE 1722 [16] standard. IEEE 1722 [18] standard.
An RTP clock master stream SHOULD be identified at the source level An RTP clock master stream SHOULD be identified at the source level
by an SSRC and master clock identifier. If master clock identifiers by an SSRC and master clock identifier. If master clock identifiers
are declared at the media or session level, all RTP sources at or are declared at the media or session level, all RTP sources at or
below the level of declaration MUST provide equivalent timing to a below the level of declaration MUST provide equivalent timing to a
slave receiver. slave receiver.
a=ssrc:<media-clock-master-ssrc-id> mediaclk:master-id=<media- a=ssrc:<media-clock-master-ssrc-id> mediaclk:master-id=<media-
clock-master-id> clock-master-id>
skipping to change at page 18, line 35 skipping to change at page 18, line 35
signalling. Asynchronous media clocking does not require reference signalling. Asynchronous media clocking does not require reference
clock signalling. An offer with asynchronous media clocking MAY clock signalling. An offer with asynchronous media clocking MAY
include reference clock signalling. Because the asynchronous media include reference clock signalling. Because the asynchronous media
clock is the default mode, the answerer is not required to explicitly clock is the default mode, the answerer is not required to explicitly
signal this even if it is explicitly signalled in the offer. signal this even if it is explicitly signalled in the offer.
6.2. Usage Outside of Offer/Answer 6.2. Usage Outside of Offer/Answer
SDP can be employed outside of the Offer/Answer context, for instance SDP can be employed outside of the Offer/Answer context, for instance
for multimedia sessions that are announced through the Session for multimedia sessions that are announced through the Session
Announcement Protocol (SAP) [17], or streamed through the Real Time Announcement Protocol (SAP) [19], or streamed through the Real Time
Streaming Protocol (RTSP) [18]. The signaling model is simpler, as Streaming Protocol (RTSP) [20]. The signaling model is simpler, as
the sender does not negotiate parameters, but the functionality the sender does not negotiate parameters, but the functionality
expected from specifying medial clock and reference clock attributes expected from specifying medial clock and reference clock attributes
is the same as in Offer/Answer. is the same as in Offer/Answer.
7. Security Considerations 7. Security Considerations
Entities receiving and acting upon an SDP message SHOULD be aware Entities receiving and acting upon an SDP message SHOULD be aware
that a session description cannot be trusted unless it has been that a session description cannot be trusted unless it has been
obtained by an authenticated transport protocol from a known and obtained by an authenticated transport protocol from a known and
trusted source. Many different transport protocols may be used to trusted source. Many different transport protocols may be used to
skipping to change at page 21, line 15 skipping to change at page 21, line 15
[7] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing [7] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing
RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RTP Control Protocol (RTCP) Canonical Names (CNAMEs)",
RFC 6222, April 2011. RFC 6222, April 2011.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
9.2. Informative References 9.2. Informative References
[9] Brandenburg, R., Stokking, H., Deventer, O., Boronat, F., [9] Society of Motion Picture & Television Engineers, "Television
and Audio - Synchronization of 59.94- or 50-Hz Related Video
and Audio Systems in Analog and Digital Areas - Reference
Signals", <http://standards.smpte.org/>.
[10] Audio Engineering Society, "AES11-2009: AES recommended
practice for digital audio engineering - Synchronization of
digital audio equipment in studio operations",
<http://www.aes.org/standards/>.
[11] Brandenburg, R., Stokking, H., Deventer, O., Boronat, F.,
Montagud, M., and K. Gross, "Inter-destination Media Montagud, M., and K. Gross, "Inter-destination Media
Synchronization using the RTP Control Protocol (RTCP)", Synchronization using the RTP Control Protocol (RTCP)",
draft-ietf-avtcore-idms-08 (work in progress), January 2013. draft-ietf-avtcore-idms-07 (work in progress), October 2012.
[10] Global Positioning Systems Directorate, "Navstar GPS Space [12] Global Positioning Systems Directorate, "Navstar GPS Space
Segment/Navigation User Segment Interfaces", September 2011. Segment/Navigation User Segment Interfaces", September 2011.
[11] Institute of Electrical and Electronics Engineers, "1588-2008 - [13] Institute of Electrical and Electronics Engineers, "1588-2008 -
IEEE Standard for a Precision Clock Synchronization Protocol IEEE Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems", IEEE Std 1588- for Networked Measurement and Control Systems", IEEE Std 1588-
2008, 2008, 2008, 2008,
<http://standards.ieee.org/findstds/standard/1588-2008.html>. <http://standards.ieee.org/findstds/standard/1588-2008.html>.
[12] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time [14] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time
Protocol Version 4: Protocol and Algorithms Specification", Protocol Version 4: Protocol and Algorithms Specification",
RFC 5905, June 2010. RFC 5905, June 2010.
[13] Institute of Electrical and Electronics Engineers, "1588-2002 - [15] Institute of Electrical and Electronics Engineers, "1588-2002 -
IEEE Standard for a Precision Clock Synchronization Protocol IEEE Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems", IEEE Std 1588- for Networked Measurement and Control Systems", IEEE Std 1588-
2002, 2002, 2002, 2002,
<http://standards.ieee.org/findstds/standard/1588-2002.html>. <http://standards.ieee.org/findstds/standard/1588-2002.html>.
[14] "Timing and Synchronization for Time-Sensitive Applications in [16] Institute of Electrical and Electronics Engineers, "Timing and
Bridged Local Area Networks", Synchronization for Time-Sensitive Applications in Bridged
Local Area Networks",
<http://standards.ieee.org/findstds/standard/ <http://standards.ieee.org/findstds/standard/
802.1AS-2011.html>. 802.1AS-2011.html>.
[15] "Audio Video Bridging (AVB) Systems", [17] Institute of Electrical and Electronics Engineers, "Audio Video
Bridging (AVB) Systems",
<http://standards.ieee.org/findstds/standard/ <http://standards.ieee.org/findstds/standard/
802.1BA-2011.html>. 802.1BA-2011.html>.
[16] "IEEE Standard for Layer 2 Transport Protocol for Time [18] Institute of Electrical and Electronics Engineers, "IEEE
Sensitive Applications in a Bridged Local Area Network", Standard for Layer 2 Transport Protocol for Time Sensitive
Applications in a Bridged Local Area Network",
<http://standards.ieee.org/findstds/standard/1722-2011.html>. <http://standards.ieee.org/findstds/standard/1722-2011.html>.
[17] Handley, M., Perkins, C., and E. Whelan, "Session Announcement [19] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[18] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming [20] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
URIs URIs
[19] <http://en.wikipedia.org/wiki/Genlock>
[20] <http://en.wikipedia.org/wiki/Word_clock>
[21] <http://www.ieee802.org/1/files/public/docs2007/ [21] <http://www.ieee802.org/1/files/public/docs2007/
as-dolsen-time-accuracy-0407.pdf> as-dolsen-time-accuracy-0407.pdf>
Authors' Addresses Authors' Addresses
Aidan Williams Aidan Williams
Audinate Audinate
Level 1, 458 Wattle St Level 1, 458 Wattle St
Ultimo, NSW 2007 Ultimo, NSW 2007
Australia Australia
 End of changes. 29 change blocks. 
43 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/