doc: Add RFC documents

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]
+