summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7164.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7164.txt')
-rw-r--r--doc/rfc/rfc7164.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc7164.txt b/doc/rfc/rfc7164.txt
new file mode 100644
index 0000000..59212a4
--- /dev/null
+++ b/doc/rfc/rfc7164.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) K. Gross
+Request for Comments: 7164 AVA Networks
+Updates: 3550 R. van Brandenburg
+Category: Standards Track TNO
+ISSN: 2070-1721 March 2014
+
+
+ RTP and Leap Seconds
+
+Abstract
+
+ This document discusses issues that arise when RTP sessions span
+ Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550
+ by describing how RTP senders and receivers should behave in the
+ presence of leap seconds.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7164.
+
+Copyright Notice
+
+ Copyright (c) 2014 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.
+
+
+
+
+
+
+
+Gross & van Brandenburg Standards Track [Page 1]
+
+RFC 7164 RTP and Leap Seconds March 2014
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Leap Seconds . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3.1. UTC Behavior during a Positive Leap Second . . . . . . . 3
+ 3.2. NTP Behavior during a Positive Leap Second . . . . . . . 3
+ 3.3. POSIX Behavior during a Positive Leap Second . . . . . . 3
+ 3.4. Example of Leap-Second Behaviors . . . . . . . . . . . . 4
+ 4. Receiver Behavior during a Leap Second . . . . . . . . . . . 5
+ 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5.1. Sender Reports . . . . . . . . . . . . . . . . . . . . . 6
+ 5.2. RTP Packet Playout . . . . . . . . . . . . . . . . . . . 7
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 8
+
+1. Introduction
+
+ In some media networking applications, RTP streams are referenced to
+ a wall-clock time (absolute date and time). This is accomplished
+ through use of the NTP timestamp field in the sender report (SR) to
+ create a mapping between RTP timestamps and the wall clock. When a
+ wall-clock reference is used, the playout time for RTP packets is
+ referenced to the wall clock. Smooth and continuous media playout
+ requires a smooth and continuous time base. The time base used by
+ the wall clock may include leap seconds that are not rendered
+ smoothly.
+
+ This document updates RFC 3550 [1] by providing recommendations for
+ smoothly rendering streamed media referenced to common wall clocks
+ that do not have smooth or continuous behavior in the presence of
+ leap seconds.
+
+2. Terminology
+
+ 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 [2] and
+ indicate requirement levels for compliant implementations.
+
+3. Leap Seconds
+
+ The world's scientific time standard is International Atomic Time
+ (TAI), which is based on vibrations of cesium atoms in an atomic
+ clock. The world's civil time is based on the rotation of the Earth.
+
+
+
+Gross & van Brandenburg Standards Track [Page 2]
+
+RFC 7164 RTP and Leap Seconds March 2014
+
+
+ In 1972, the civil time standard, Coordinated Universal Time (UTC),
+ was redefined in terms of TAI and the concept of leap seconds was
+ introduced to allow UTC to remain synchronized with the rotation of
+ the Earth.
+
+ Leap seconds are scheduled by the International Earth Rotation and
+ Reference Systems Service. Leap seconds may be scheduled at the last
+ day of any month but are preferentially scheduled for December and
+ June and secondarily March and September [6]. Because Earth's
+ rotation is unpredictable, leap seconds are typically not scheduled
+ more than six months in advance.
+
+ Leap seconds do not respect local time and always occur at the end of
+ the UTC day. Leap seconds can be scheduled to either add or remove a
+ second from the day. A leap second that adds an extra second is
+ known as a positive leap second. A leap second that skips a second
+ is known as a negative leap second.
+
+ Since their introduction in 1972, all leap seconds have been
+ scheduled in June or December, and they have all been positive.
+
+ NOTE: The ITU is studying a proposal that could eventually eliminate
+ leap seconds from UTC. As of January 2012, this proposal is expected
+ to be decided no earlier than 2015 [7].
+
+3.1. UTC Behavior during a Positive Leap Second
+
+ UTC clocks feature a 61st second at the end of the day when a
+ positive leap second is scheduled. The leap second is designated
+ "23h 59m 60s".
+
+3.2. NTP Behavior during a Positive Leap Second
+
+ Under NTP [8], a leap second is inserted at the beginning of the last
+ second of the day. This results in the clock freezing or slowing for
+ one second immediately prior to the last second of the affected day.
+ This results in the last second of the day having a real-time
+ duration of two seconds. Timestamp accuracy is compromised during
+ this period because the clock's rate is not well defined.
+
+3.3. POSIX Behavior during a Positive Leap Second
+
+ The POSIX (Portable Operating System Interface) standard [3] requires
+ that leap seconds be omitted from reported time. All days are
+ defined as having 86,400 seconds, but the timebase is defined to be
+ UTC, a leap-second-bearing reference. Implementors of POSIX systems
+ are offered considerable latitude by the standard as to how to map
+ POSIX time to UTC.
+
+
+
+Gross & van Brandenburg Standards Track [Page 3]
+
+RFC 7164 RTP and Leap Seconds March 2014
+
+
+ In many systems, leap seconds are accommodated by repeating the last
+ second of the day. A timestamp within the last second of the day is
+ therefore ambiguous in that it can refer to a moment in time in
+ either of the last two seconds of a day containing a leap second.
+
+ Other systems use the same technique used by NTP, freezing or slowing
+ for one second immediately prior to the last second of the affected
+ day.
+
+ In some cases, leap seconds are accommodated by warping time [5] [4];
+ that is, the length of the second in the vicinity of a leap second is
+ slightly altered.
+
+3.4. Example of Leap-Second Behaviors
+
+ Table 1 illustrates the positive leap second that occurred June 30,
+ 2012 when the offset between TAI and UTC changed from 34 to 35
+ seconds. The first column shows RTP timestamps for an 8 kHz audio
+ stream. The second column shows the TAI reference. The following
+ columns show behavior for the leap-second-bearing wall clocks
+ described above. Time values are shown at half-second intervals.
+
+ +-------+--------------+--------------+--------------+--------------+
+ | RTP | TAI | UTC | POSIX | NTP |
+ +-------+--------------+--------------+--------------+--------------+
+ | 8000 | 00:00:32.500 | 23:59:58.500 | 23:59:58.500 | 23:59:58.500 |
+ | 12000 | 00:00:33.000 | 23:59:59.000 | 23:59:59.000 | 23:59:59.000 |
+ | 16000 | 00:00:33.500 | 23:59:59.500 | 23:59:59.500 | 23:59:59.500 |
+ | 20000 | 00:00:34.000 | 23:59:60.000 | 23:59:59.000 | 00:00:00.000 |
+ | 24000 | 00:00:34.500 | 23:59:60.500 | 23:59:59.500 | 00:00:00.000 |
+ | 28000 | 00:00:35.000 | 00:00:00.000 | 00:00:00.000 | 00:00:00.000 |
+ | 32000 | 00:00:35.500 | 00:00:00.500 | 00:00:00.500 | 00:00:00.500 |
+ +-------+--------------+--------------+--------------+--------------+
+
+ Table 1: Positive Leap-Second Behavior
+
+ NOTE: Some NTP implementations do not entirely freeze the clock while
+ the leap second is inserted. Successive calls to retrieve system
+ time return infinitesimally larger (e.g., 1 microsecond or 1
+ nanosecond larger) time values. This behavior is designed to satisfy
+ assumptions applications may make that time increases monotonically.
+ This behavior occurs in the least-significant bits of the time value
+ and so is not typically visible in the human-readable format shown in
+ the table.
+
+
+
+
+
+
+
+Gross & van Brandenburg Standards Track [Page 4]
+
+RFC 7164 RTP and Leap Seconds March 2014
+
+
+ NOTE: POSIX implementations vary. The implementation shown here
+ repeats the last second of the affected day. Other implementations
+ mirror NTP behavior or alter the length of a second in the vicinity
+ of the leap second.
+
+4. Receiver Behavior during a Leap Second
+
+ Timestamps generated during a leap second may be ambiguous or
+ interpreted differently by a sender and receiver or interpreted
+ differently by different receivers.
+
+ Without prior knowledge of the leap-second schedule, NTP servers and
+ clients may become 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. Depending on the system implementation, the offset
+ can last anywhere from a few seconds to a few days. A long-lived
+ discrepancy can be particularly disruptive to operation of NTP-
+ referenced RTP streams.
+
+ These discrepancies, depending on direction, may cause receivers to
+ think they are receiving RTP packets after they should be played or
+ to attempt to buffer received data an additional second before
+ playing it. Either situation can cause an interruption in playback.
+ Some receivers may automatically recognize an unexpected offset and
+ resynchronize to the stream to accommodate it. Once the offset is
+ resolved, such receivers may need to resynchronize again.
+
+5. Recommendations
+
+ Senders and receivers that are not referenced to a wall clock are not
+ affected by issues associated with leap seconds, and no special
+ accommodation is required.
+
+ RTP implementation using a wall-clock reference is simplified by
+ using a clock with a timescale that does not include leap seconds.
+ IEEE 1588 [9], GPS [10], and other systems that use a TAI [11]
+ reference do not include leap seconds. NTP time, operating system
+ clocks, and other systems using a UTC reference include leap seconds.
+
+ Note that some TAI-based systems such as IEEE 1588 and GPS, in
+ addition to the TAI reference clock, deliver TAI to UTC mapping
+ information. By combining the delivered TAI reference clock and the
+ mapping information, some receivers of these systems are able to
+ synthesize a leap-second-bearing UTC reference clock. For the
+ purposes of this document, it is important to recognize that it is
+ the timescale used, not the delivery mechanism that determines
+ whether a reference clock is leap-second bearing.
+
+
+
+Gross & van Brandenburg Standards Track [Page 5]
+
+RFC 7164 RTP and Leap Seconds March 2014
+
+
+ +-------------------------+---------------------+---------------+
+ | Reference clock type | Examples | Accommodation |
+ +-------------------------+---------------------+---------------+
+ | None | Self clocking | None needed |
+ | Non-leap-second-bearing | IEEE 1588, GPS, TAI | None needed |
+ | Leap-second-bearing | NTP | Recommended |
+ +-------------------------+---------------------+---------------+
+
+ Table 2: Recommendations Summary
+
+ All participants generating or consuming timestamps associated with a
+ leap-second-bearing reference MUST recognize leap seconds and SHOULD
+ have a working communications channel to receive notifications of
+ leap-second scheduling. A working communication channel includes a
+ protocol means of notifying clocks of an impending leap second such
+ as the Leap Indicator in the NTP header [8] and also a means for top-
+ tier clocks to receive leap-second schedule information published by
+ the International Earth Rotation and Reference Systems Service [12].
+
+ Such a communications channel may not be available on all networks.
+ For security or other reasons, leap-second schedules may be
+ configured manually for some networks or clocks. When a device does
+ not reliably receive leap-second scheduling information, failures as
+ described in Section 4 may occur.
+
+ Because of the timestamp ambiguity that positive leap seconds can
+ introduce and the inconsistent manner in which different systems
+ accommodate positive leap seconds, generating or using NTP timestamps
+ during the entire last second of a day on which a positive leap
+ second has been scheduled SHOULD be avoided. Note that the period to
+ be avoided has a real-time duration of two seconds. In the Table 1
+ example, the region to be avoided is indicated by RTP timestamps
+ 12000 through 28000
+
+ Negative leap seconds do not introduce timestamp ambiguity or other
+ complications. No special treatment is needed to avoid ambiguity
+ with respect to RTP timestamps in the presence of a negative leap
+ second.
+
+ POSIX clocks that use a warping technique to accommodate leap seconds
+ (e.g., [4] [5]) are not a good choice for an interoperable timestamp
+ reference and SHOULD not be used to timestamp RTP streams.
+
+5.1. Sender Reports
+
+ In order to avoid generating or using NTP timestamps during positive
+ leap seconds, RTP senders and receivers need to avoid sending or
+ using sender reports to synchronize their clocks in the vicinity of a
+
+
+
+Gross & van Brandenburg Standards Track [Page 6]
+
+RFC 7164 RTP and Leap Seconds March 2014
+
+
+ leap second and instead rely on their internal clocks to maintain
+ synchronization until the leap second has passed.
+
+ RTP Senders using a leap-second-bearing reference for timestamps
+ SHOULD NOT generate sender reports containing an originating NTP
+ timestamp in the vicinity of a positive leap second. To maintain a
+ consistent RTCP schedule and avoid the risk of unintentional
+ timeouts, such senders MAY send receiver reports in place of sender
+ reports in the vicinity of the leap second.
+
+ For the purpose of suspending sender reports in the vicinity of a
+ leap second, senders MAY assume that a positive leap second occurs at
+ the end of the last day of every month.
+
+ Receivers consuming leap-second-bearing timestamps SHOULD ignore
+ timestamps in any sender reports generated in the vicinity of a
+ positive leap second.
+
+ For the purpose of ignoring sender reports in the vicinity of a leap
+ second, receivers MAY assume that a positive leap second occurs at
+ the end of the last day of every month.
+
+5.2. RTP Packet Playout
+
+ Receivers consuming leap-second-bearing timestamps SHOULD take both
+ positive and negative leap seconds in the reference into account to
+ determine the playout time based on RTP timestamps for data in RTP
+ packets.
+
+6. Security Considerations
+
+ RTP streams using a wall-clock reference as discussed here present an
+ additional attack vector compared to self-clocking streams.
+ Manipulation of the wall clock at either the sender or receiver can
+ potentially disrupt streaming.
+
+ For an RTP stream operating to a leap-second-bearing reference to
+ operate reliably across a leap second, the sender and receiver must
+ both be aware of the leap second. It is possible to disrupt a stream
+ by blocking or delaying leap second notification to one of the
+ participants. Streaming can be similarly affected if one of the
+ participants can be tricked into believing a leap second has been
+ scheduled where there is not one. These vulnerabilities are present
+ in RFC 3550 [1] and these new recommendations neither heighten nor
+ diminish them. Integrity of the leap-second schedule is the
+ responsibility of the operating system and time distribution
+ mechanism, both of which are outside the scope of RFC 3550 [1] and
+ these recommendations.
+
+
+
+Gross & van Brandenburg Standards Track [Page 7]
+
+RFC 7164 RTP and Leap Seconds March 2014
+
+
+7. Acknowledgements
+
+ The authors would like to thank Steve Allen for his valuable comments
+ that helped to improve this document.
+
+8. References
+
+8.1. Normative References
+
+ [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", STD 64,
+ RFC 3550, July 2003.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+8.2. Informative References
+
+ [3] IEEE, "Portable Operating System Interface (POSIX)", IEEE
+ Standard 1003.1-2008, December 2008,
+ <http://standards.ieee.org/findstds/standard/1003.1-2008.html>.
+
+ [4] Google, Inc., "Time, technology and leaping seconds", September
+ 2011, <http://googleblog.blogspot.com/2011/09/
+ time-technology-and-leaping-seconds.html>.
+
+ [5] Kuhn, M., "Coordinated Universal Time with Smoothed Leap
+ Seconds (UTC-SLS)", Work in Progress, January 2006.
+
+ [6] ITU, "Standard-frequency and time-signal emissions", ITU-R
+ TF.460-6, February 2002,
+ <http://www.itu.int/rec/R-REC-TF.460/>.
+
+ [7] ITU, "The future of the UTC time scale", Question ITU-R 236/7,
+ February 2012, <http://www.itu.int/pub/R-QUE-SG07.236-2001>.
+
+ [8] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time
+ Protocol Version 4: Protocol and Algorithms Specification", RFC
+ 5905, June 2010.
+
+ [9] IEEE, "IEEE Standard for a Precision Clock Synchronization
+ Protocol for Networked Measurement and Control Systems", IEEE
+ Standard 1588-2008, July 2008,
+ <http://standards.ieee.org/findstds/standard/1588-2008.html>.
+
+
+
+
+
+
+
+Gross & van Brandenburg Standards Track [Page 8]
+
+RFC 7164 RTP and Leap Seconds March 2014
+
+
+ [10] Global Positioning Systems Directorate, "Systems Engineering &
+ Integration Interface Specification", September 2011,
+ <http://www.navcen.uscg.gov/pdf/IS-GPS-200F.pdf>.
+
+ [11] Bureau International des Poids et Mesures, "International
+ Atomic Time", Navstar GPS Space Segment/Navigation User Segment
+ Interfaces IS-GPS-200,
+ <http://www.bipm.org/en/scientific/tai/tai.html>.
+
+ [12] IERS Earth Orientation Centre, "Bulletin C - Product metadata",
+ <http://datacenter.iers.org/web/guest/eop/-/somos/5Rgv/
+ product/16>.
+
+Authors' Addresses
+
+ Kevin Gross
+ AVA Networks
+ Boulder, CO
+ US
+
+ EMail: kevin.gross@avanw.com
+
+
+ Ray van Brandenburg
+ TNO
+ Brassersplein 2
+ Delft 2612CT
+ the Netherlands
+
+ Phone: +31-88-866-7000
+ EMail: ray.vanbrandenburg@tno.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gross & van Brandenburg Standards Track [Page 9]
+