From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7164.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc7164.txt (limited to 'doc/rfc/rfc7164.txt') 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, + . + + [4] Google, Inc., "Time, technology and leaping seconds", September + 2011, . + + [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, + . + + [7] ITU, "The future of the UTC time scale", Question ITU-R 236/7, + February 2012, . + + [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, + . + + + + + + + +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, + . + + [11] Bureau International des Poids et Mesures, "International + Atomic Time", Navstar GPS Space Segment/Navigation User Segment + Interfaces IS-GPS-200, + . + + [12] IERS Earth Orientation Centre, "Bulletin C - Product metadata", + . + +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] + -- cgit v1.2.3