Audio/Video Transport Extensions A. Williams Internet-Draft Audinate Intended status: Standards Track October 31, 2011 Expires: May 3, 2012 IEEE 1588/802.1AS Synchronisation for RTP Streams draft-williams-avtext-avbsync-02 Abstract This memo specificies an RTP header extension for carrying in-band synchronization metadata provided by the IEEE1588/802.1AS Precision Time Protocols. Requirements Language 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 [1]. Status of this Memo 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 May 3, 2012. Copyright Notice Copyright (c) 2011 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 Williams Expires May 3, 2012 [Page 1] Internet-Draft AVB/RTP Synchronisation October 2011 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. Table of Contents 1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Reference Clocks and Clock Domains . . . . . . . . . . . . . . 4 4. Timestamp formats . . . . . . . . . . . . . . . . . . . . . . 5 5. IEEE 1733 / AVB RTCP Packet Type . . . . . . . . . . . . . . . 5 5.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. RTCP Packet Subtypes . . . . . . . . . . . . . . . . . . . 7 6. Timing Header Extension . . . . . . . . . . . . . . . . . . . 8 7. SDP signalling . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Clock domain . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Quality of Service . . . . . . . . . . . . . . . . . . . . 11 8. An Alternative Approach . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Williams Expires May 3, 2012 [Page 2] Internet-Draft AVB/RTP Synchronisation October 2011 1. Outline Alternative approach Use existing header extension for timestamps. (RFC 6051) Create additional small header extension for metadata (traceability, uncertainty, media clock discontinuity). IDMS wants accurate timing too and has a method for describing clocks. Create a single specification for signalling clock domains which covers both use cases. IDMS can use that too. 2. Introduction Synchronisation between RTP flows and between devices rendering RTP flows is currently facilitated by means of NTP format timestamps taken with respect to a shared reference clock. In many applications (e.g. professional, commercial and automotive AV), the NTP clock synchronisation protocol does not meet the necessary time alignment and synchronisation speed requirements. Like NTP, 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 rather than minutes. 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: o IEEE 1588-2002 [4]: the original "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". This is often called IEEE1588v1 or PTPv1. o IEEE 1588-2008 [5]: the second version of the "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". This is a revised version of the original IEEE1588-2002 standard and is often called IEEE1588v2 or PTPv2. Williams Expires May 3, 2012 [Page 3] Internet-Draft AVB/RTP Synchronisation October 2011 o IEEE 802.1AS [6]: "Timing and Synchronization for Time Sensitive Applications in Bridged Local Area Networks". This is a Layer-2 only profile of IEEE 1588-2008 for use in Audio/Video Bridged LANs. By using an IEEE 1588 derived reference clock, synchronisation of RTP streams and devices in LANs can be considerably improved. 3. Reference Clocks and Clock Domains RTP uses NTP format timestamps to exchange information about media clock timing. NTP timestamps may come from a clock which is synchronised to a global time reference, but this is not 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. 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. The grandmaster clock identity can be used to identify a set of clocks in a single clock domain. The IEEE1588 protocol family also carries an indication that the grand master clock provides traceable time. Traceablility of a time source implies that the clock is ultimately slaved to a global time source (e.g. GPS). A slave may consider one or more grandmaster clocks providing traceable time as belonging to the same (global) clock domain. Informally, traceabiliity trumps ClockIdentity when comparing clock domains. Traceable time is particularly applicable for wide area applications such as broadcast, transport and reflection seismology. 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 Williams Expires May 3, 2012 [Page 4] Internet-Draft AVB/RTP Synchronisation October 2011 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. Accurate signal playout time alignment and accurate capture of input signal phase relationships are important requirements for A/V systems. In distributed AV systems containing many senders/receivers and differing network path lengths, a shared reference clock providing absolute time is needed. Relative timing using unsychronised clocks cannot provide the required level of time alignment (+/- 1us). 4. Timestamp formats IEEE 1588/802.1AS timestamps use International Atomic Time (TAI) rather than UTC. Timestamps are 80 bits in total, divided into two parts: PTP_sec: 48 bits seconds since epoch PTP_nsec: 32 bits nanoseconds A shorter 32 bit timestamp has also been defined for use in streaming media protocols in the following way: as_timestamp = (PTP_sec * 10^9 + PTP_nsec) modulo 2^32 The shorter as_timestamp field covers a time interval slightly larger than 4 seconds. 5. IEEE 1733 / AVB RTCP Packet Type IEEE 1733 [7] defines the "AVB RTCP packet" type reproduced in Figure 1. RTCP AVB packets contain a mapping between RTP timestamp and an 802.1AS timestamp as well as additional clock and QoS information. The RTCP packet type shown below provides the corresponding IEEE1588 timestamp for an RTP timestamp in a similar fashion to an RTCP Sender Report (SR). In addition, the source of the timing information (i.e. the grandmaster ClockIdentity) is included. Clock domain information Williams Expires May 3, 2012 [Page 5] Internet-Draft AVB/RTP Synchronisation October 2011 allows an RTP implementation to determine whether sender and receiver timestamps have been taken using a shared reference clock. If the sender and receiver share a common clock domain, timestamps and be used and compared in an absolute sense. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|subtype=0| PT=208 | length=9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name (ASCII) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R | gmTimeBaseIndicator | gmPortNumber |T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C | |P + gmClockIdentity (EUI-64) + | |A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+V | |B + stream_id (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | as_timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rtp_timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IEEE 1733 / AVB RTCP packet format A brief description of the major fields follows: name Reserved, must be set to zero and ignored on reception. gmTimeBaseIndicator This field identifies the clock master time base. The gmTimeBaseIndicator increments each time a step change in time or frequency occurs. If the value of the gmTimeBaseIndicator and gmIdentity in the RTCP packet (i.e., of the sender) match the gmTimeBaseIndicator and gmIdentity at the receiver, the receiver is assured that timestamps have been taken using a shared reference clock. If they do not match, actions performed by the receiver are application dependent but may include entering a holdover mode until a positive match is again achieved. Williams Expires May 3, 2012 [Page 6] Internet-Draft AVB/RTP Synchronisation October 2011 gmPortNumber An integer identifying the port used on a grand master. gmClockIdentity An EUI-64 identifying the grand master clock used by the source to generate as_timestamps for this flow. stream_id A 64 bit number identifying the 802.1Qat [8] QoS reservation associated with this RTP flow. as_timestamp The 32 bit 802.1AS timestamp (Section 4) associated with the RTP timestamp carried in this packet. rtp_timestamp The RTP timestamp of a media packet. Please consult the IEEE 1733 specification [7] for more details. 5.1. Observations The RTCP packet type above provides the basic information for linking IEEE1588 time to RTP timestamps, however there are some additions which would improve the functionality provided. The IEEE1733 specifcation does not define any SDP signalling. This means that the QoS parameters (ie the stream_id) cannot be signalled at call/flow setup time using SIP/RTSP. Whilst IEEE1733 provides clock domain information, it doesn't really define how clock domains work. Further, IEEE1733 does not include metadata to indicate clock changes. This specification addresses each of these issues. 5.2. RTCP Packet Subtypes Systems not using the full AVB protocol suite can still benefit from timing improvements offered by IEEE 1588v1 and IEEE 1588v2. In general, the IEEE 1733 / AVB RTCP packet format (Figure 1) can be used to relate RTP timestamp instants in media packets to a reference clock provided by any of the IEEE 1588/PTP family of clock synchronisation protocols. The subtype field indicates which IEEE 1588 protocol was used by the timestamping clock: 0x00 IEEE 802.1AS (defined by IEEE 1733) 0x01 IEEE 1588v1 0x02 IEEE 1588v2 Williams Expires May 3, 2012 [Page 7] Internet-Draft AVB/RTP Synchronisation October 2011 6. Timing Header Extension The header extension shown below provides a combination of media timestamps and timing metadata. The provision of IEEE1588 timestamps in the RTP header is analogous to the existing NTP timestamp header extension supporting rapid synchonisation of RTP flows. High performance systems often handle RTP media packets in hardware and carriage of timing metadata in the media packets provides increased performance (e.g. faster lock times) and simplifies the system. In contrast to using RTCP, a header extension guarantees that timing metadata arrives at the receiver with the first media packet allowing them to be processed immediately. This approach facilitates fast switching between sources as is commonly used in zoned paging applications. If the sender and receiver share a clock domain, source timestamps in media packets facilitate the collection of high quality information about the actual delays experienced by media packets through the network. Accurate delay information is important for diagnosing operational problems and for system optimisation. The metadata included in the header allows senders to signal changes in clock disposition to receivers. Since IEEE1588 uses an election mechanism to determine the clock master it is possible for the master and/or grand master to change during the transmission of an RTP flow. Changing from one master clock to another may involve changes in clock frequency and/or phase. Additionally, the election protocol is not guaranteed to complete at the same time at all nodes in the clock domain, so there will be a transition period during which timestamps at the sender and receiver are not directly comparable. A sender indicates changes in IEEE1588 clocking by setting the timestamp uncertain (U) bit in the header. For example, the bit may be set when the best master clock election process is triggered due to loss of the current master clock. Once set, this bit should remain set during the entire period where PTP timing is in flux and for at least 5 seconds after PTP timing has stabilised (5 seconds allows as_timestamps which cover about 4 seconds to be disambiguated). When PTP timestamps are uncertain the receiver may refrain from updating the rtp_timestamp to wallclock mapping, effectively processing packets on the basis of rtp_timestamp alone. In AV systems, media clocks are often provided via an external connection. When a media clock is disconnected or switched from one source to another (e.g. between two different SP/DIF ports), synchronisation may be lost and noise may be generated. A sender can indicate the loss of a media clock for a transmitted signal by toggling the media clock restart (M) bit. A receiver may use a Williams Expires May 3, 2012 [Page 8] Internet-Draft AVB/RTP Synchronisation October 2011 change in the media clock restart bit to mute audio or to hold a frame or to trigger resynchronisation to the new media clock. In some systems, senders and receivers are on different networks with different grand master clocks however they may be part of a single global clock domain that uses traceable time. A sender can indicate that media packet timestamps have been taken with a traceable clock by setting T=1. Since it is possible for a PTP clock master to change during an RTP flow, the T bit may change. For example, if the traceable grand master clock used by the sender fails, PTP will elect a new grand master which may not be slaved to a global time source. In systems where traceable time is important, all candidate PTP masters should support traceable time and media signals timestamps should be clearly marked as traceable or not traceable. If timestamps are not traceable, T MUST be set to zero. Figure 2 shows the fields of the AVB sync header extension. It uses the standard RTP header extension mechanism defined in RFC 5285 [2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|1| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R | timestamp |T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P | synchronisation source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 0xBE | 0xDE | length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E | ID=7 | L=6 | subtype |T|M|U| reserved |x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t | as_timestamp |n +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | payload data | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Timestamp Header Extension The fields are defined as follows: T Bit field indicating traceable timestamps. If T=1, the timestamp in this packet was taken by a clock slaved to a global time source otherwise T MUST be set to zero. Williams Expires May 3, 2012 [Page 9] Internet-Draft AVB/RTP Synchronisation October 2011 M Toggling the value of the media clock restart field (M) indicates a change in the source of the media clock. This kind of change need not be seamless but allows the receiver to take any appropriate action to minimize the disruption to the stream. The value of the M bit is toggled once by the sender each time the media clock source is changed. Toggling the bit rather than setting/resetting ensures media clock restarts will not be missed if it were to appear in a single RTP packet which happens to be dropped. U The sender sets U=1 to indicate that timestamps may not be globally synchronized with network time. An example is the invocation of the best master clock algorithm because of a PTP SYNC timeout . Receivers may use the U bit, possibly in conjunction with their knowledge of the status of the PTP clock, to prevent unacceptable disturbances in the recovered media streams. subtype See Section 5.2. as_timestamp A 32 bit IEEE 1588/802.1AS timestamp as defined in Section 4. reserved As this specification evolves, additional fields may be included in this header. The as_timestamp MUST correspond to the same instant as the RTP timestamp in the packet's header, and MUST be derived from the same clock used to generate the as_timestamps in the RTCP AVB packets. Provided that it has knowledge of the SSRC to CNAME mapping, either from prior receipt of an RTCP CNAME packet or via out of band signalling such as RFC 5576 [3], the receiver can use the information provided as input to the synchronization algorithm, in exactly the same way as if an additional RTCP AVB packet had been received for the flow. 7. SDP signalling The Session Description Protocol (SDP) allows clock domain and QoS information to be signalled via SIP or RTSP at call setup time. In the case of SIP, changes in information can also be signalled during the RTP session. 7.1. Clock domain General format for signalling clock domains (todo: convert to EBNF): Williams Expires May 3, 2012 [Page 10] Internet-Draft AVB/RTP Synchronisation October 2011 a=clockdomain:ptp-version=PTP-PROTOCOL gmid=EUI-64 traceable=YES-OR-NO Examples: a=clockdomain:ptp-version=IEEE1588v1 gmid=39-A7-94-FF-FE-07-CB-D0 traceable=yes a=clockdomain:ptp-version=IEEE1588v2 gmid=39-A7-94-FF-FE-07-CB-D0 traceable=yes a=clockdomain:ptp-version=802.1AS gmid=39-A7-94-FF-FE-07-CB-D0 traceable=no 7.2. Quality of Service General format for signalling AVB QoS to a receiver: a=8021qat-qos:stream-id=EUI-64 Example: a=8021qat-qos:stream-id=00-1D-C1-97-BB-3A-01-01 8. An Alternative Approach Some RTP specifications already exists which cover aspects of the functionality described in this specification. Most notably, there is a specification for a header extension allowing NTP format timestamps to be included in RTP media packet headers (RFC 6051). In addition, some new work (http://tools.ietf.org/html/draft-ietf-avtcore-idms-02) specifies a mechanism for describing clock sources including those based on IEEE 1588. Rather developing new specifications based on the 32 bit as_timestamp format, an alternative approach which could fulfil the goals of this specification could be to: 1. Use the existing RFC 6051 to carry timestamps in RTP media packets (nothing to be done). 2. Create a new specification describing clock sources/domains and their signalling that is independent of both this specification and the IDMS specification. This would allow clock domains to be signalled generally in RTP. This might be done in avtcore. 3. Create a new specification augmenting RFC 6051 which carries the timing metadata (ptp uncertainty, media clock change, Williams Expires May 3, 2012 [Page 11] Internet-Draft AVB/RTP Synchronisation October 2011 traceability). 4. This specification: the header extension and clock domain signally go into other documents. There may be some remaining text describing how AVB systems in particular would use the above mechanisms. 9. IANA Considerations TBD: A URN will be required to signal the presence of this header extension, such as: urn:ietf:params:rtp-hdrext:avb-sync 10. Acknowledgements The timing metadata (U and M) bits were inspired by the IEEE 1722 specification. 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008. [3] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. 11.2. Informative References [4] 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, . [5] 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, Williams Expires May 3, 2012 [Page 12] Internet-Draft AVB/RTP Synchronisation October 2011 . [6] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks - IEEE Draft Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", IEEE Std 802.1AS-2011, 2011, . [7] Institute of Electrical and Electronics Engineers, "1733-2011 - IEEE Standard for Layer 3 Transport Protocol for Time-Sensitive Applications in Local Area Networks", IEEE Draft Std 1733/D7.0, February 2011, . [8] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks---Virtual Bridged Local Area Networks Amendment 14: Stream Reservation Protocol (SRP)", IEEE Std 802.1Qat-2010 (Revision of IEEE Std 802.1Q-2005), 2010, . Appendix A. An Appendix Author's Address Aidan Williams Audinate Level 1, 458 Wattle St Ultimo, NSW 2007 Australia Phone: +61 2 8090 1000 Fax: +61 2 8090 1001 Email: aidan.williams@audinate.com Williams Expires May 3, 2012 [Page 13]