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
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
RTP和闰秒
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.
本文档讨论RTP会话跨越协调世界时（UTC）闰秒时出现的问题。它通过描述RTP发送器和接收器在存在闰秒时的行为来更新RFC3550。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
在一些媒体网络应用程序中，RTP流引用的是挂钟时间（绝对日期和时间）。这是通过使用发送方报告（SR）中的NTP时间戳字段来创建RTP时间戳和挂钟之间的映射来实现的。当使用挂钟参考时，RTP数据包的播放时间参考挂钟。平滑连续的媒体播放需要平滑连续的时基。挂钟使用的时基可能包括未平滑渲染的闰秒。
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.
本文档更新了RFC 3550[1]，提供了平滑渲染流媒体的建议，这些流媒体引用了在闰秒出现时不具有平滑或连续行为的普通墙上时钟。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中的描述进行解释，并指明符合性实施的要求级别。
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.
世界上的科学时间标准是国际原子时（TAI），它基于原子钟中铯原子的振动。世界民用时间是以地球自转为基础的。
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.
1972年，民用时间标准协调世界时（UTC）根据TAI重新定义，并引入闰秒概念，以使UTC与地球自转保持同步。
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.
闰秒由国际地球自转和参考系统服务公司安排。闰秒可以安排在任何月份的最后一天，但优先安排在12月和6月，其次是3月和9月[6]。由于地球自转是不可预测的，闰秒通常不会提前六个月以上安排。
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.
闰秒不尊重当地时间，总是在UTC日结束时出现。闰秒可以计划在一天中添加或删除一秒。增加额外秒数的闰秒称为正闰秒。跳过一秒的闰秒称为负闰秒。
Since their introduction in 1972, all leap seconds have been scheduled in June or December, and they have all been positive.
自1972年推出以来，所有闰秒都安排在6月或12月，而且都是积极的。
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].
注：国际电联正在研究一项提案，该提案可能最终消除UTC的闰秒。截至2012年1月，该提案预计不早于2015年作出决定[7]。
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".
UTC时钟的特点是在一天结束时有一个61秒的正闰秒。闰秒被指定为“23h 59m 60s”。
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.
在NTP[8]中，在一天的最后一秒开始时插入闰秒。这会导致时钟在受影响的一天的最后一秒之前冻结或减慢一秒钟。这将导致一天的最后一秒具有两秒的实时持续时间。在这段时间内，时间戳的准确性会受到影响，因为时钟的速率没有很好地定义。
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.
POSIX（便携式操作系统接口）标准[3]要求在报告的时间中省略闰秒。所有天数定义为86400秒，但时基定义为UTC，即闰秒方位基准。标准为POSIX系统的实施者提供了相当大的自由度，让他们知道如何将POSIX时间映射到UTC。
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.
其他系统使用与NTP相同的技术，在受影响的一天的最后一秒之前冻结或减速一秒钟。
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.
在某些情况下，闰秒由翘曲时间[5][4]调节；也就是说，闰秒附近的秒的长度略有改变。
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.
表1显示了2012年6月30日发生的正闰秒，当时TAI和UTC之间的偏移量从34秒更改为35秒。第一列显示8kHz音频流的RTP时间戳。第二列显示TAI引用。以下列显示上述闰秒承重墙时钟的行为。时间值以半秒的间隔显示。
+-------+--------------+--------------+--------------+--------------+
| 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 |
+-------+--------------+--------------+--------------+--------------+
+-------+--------------+--------------+--------------+--------------+
| 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
表1：积极的闰秒行为
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.
注意：某些NTP实现在插入闰秒时不会完全冻结时钟。检索系统时间的连续调用返回无穷大的时间值（例如，大1微秒或大1纳秒）。此行为旨在满足应用程序可能使时间单调增加的假设。此行为发生在时间值的最低有效位，因此在表中所示的人类可读格式中通常不可见。
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.
注意：POSIX实现各不相同。此处显示的实现重复受影响的一天的最后一秒。其他实现镜像NTP行为或在闰秒附近改变秒的长度。
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.
在事先不了解闰秒计划的情况下，NTP服务器和客户端可能会相对于其UTC参考精确偏移1秒。这种潜在的差异开始于闰秒，结束于所有参与者收到服务器或对等方的时间更新。根据系统实施情况，偏移可以持续几秒钟到几天。长期存在的差异可能会对NTP引用RTP流的操作造成特别大的干扰。
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.
这些差异（取决于方向）可能会导致接收器认为他们在应该播放RTP数据包之后接收到了RTP数据包，或者在播放之前尝试将接收到的数据再缓冲一秒钟。任何一种情况都可能导致播放中断。一些接收机可以自动识别意外的偏移，并与流重新同步以适应它。一旦偏移被解决，此类接收机可能需要再次重新同步。
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.
通过使用具有不包括闰秒的时间刻度的时钟，可以简化使用墙时钟参考的RTP实现。IEEE 1588[9]、GPS[10]和其他使用TAI[11]参考的系统不包括闰秒。NTP时间、操作系统时钟和其他使用UTC参考的系统包括闰秒。
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.
请注意，一些基于TAI的系统，如IEEE 1588和GPS，除了TAI参考时钟外，还提供TAI到UTC的映射信息。通过组合交付的TAI参考时钟和映射信息，这些系统的一些接收器能够合成闰秒方向的UTC参考时钟。在本文件中，重要的是要认识到，确定基准时钟是否为闰秒方位的是所使用的时间刻度，而不是传递机制。
+-------------------------+---------------------+---------------+
| 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 |
+-------------------------+---------------------+---------------+
+-------------------------+---------------------+---------------+
| 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
表2：建议摘要
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].
所有生成或使用与闰秒轴承参考相关的时间戳的参与者必须识别闰秒，并且应该有一个工作的通信通道来接收闰秒计划的通知。工作通信信道包括通知时钟即将发生闰秒的协议装置，如NTP报头中的闰秒指示器[8]，以及顶层时钟接收国际地球自转和参考系统服务发布的闰秒时间表信息的装置[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.
这种通信信道可能并非在所有网络上都可用。出于安全或其他原因，可以为某些网络或时钟手动配置闰秒计划。当设备不能可靠地接收闰秒调度信息时，可能会发生第4节所述的故障。
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
由于正闰秒可能带来的时间戳模糊性，以及不同系统容纳正闰秒的方式不一致，因此应避免在已安排正闰秒的一天的整个最后一秒钟内生成或使用NTP时间戳。请注意，要避免的时段的实时持续时间为2秒。在表1示例中，要避免的区域由RTP时间戳12000到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.
负闰秒不会引起时间戳模糊或其他复杂情况。在负闰秒的情况下，不需要特殊处理来避免RTP时间戳的模糊性。
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.
对于互操作时间戳引用而言，使用扭曲技术来适应闰秒（例如，[4][5]）的POSIX时钟不是一个好的选择，不应用于对RTP流进行时间戳。
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
为了避免在正闰秒期间生成或使用NTP时间戳，RTP发送方和接收方需要避免发送或使用发送方报告来同步其在正闰秒附近的时钟
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.
使用闰秒方向的时间戳引用的RTP发送方不应生成包含正闰秒附近的原始NTP时间戳的发送方报告。为保持一致的RTCP计划并避免意外超时的风险，此类发送方可在闰秒附近发送接收方报告，代替发送方报告。
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.
为了忽略闰秒附近的发送者报告，接收者可以假设在每个月的最后一天结束时发生正闰秒。
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.
使用闰秒轴承时间戳的接收器应考虑参考中的正闰秒和负闰秒，以根据RTP数据包中数据的RTP时间戳确定播放时间。
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.
这里使用的壁时钟基准的RTP流与自时钟流相比，提出了附加的攻击向量。在发送方或接收方操纵挂钟可能会中断流。
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.
为了使以闰秒方位基准运行的RTP流能够可靠地跨闰秒运行，发送方和接收方都必须知道闰秒。可以通过阻止或延迟向其中一个参与者发送闰秒通知来中断流。如果其中一名参与者被欺骗，认为在没有闰秒的地方安排了闰秒，则流媒体也会受到类似的影响。这些漏洞存在于RFC 3550[1]中，这些新建议既没有增强也没有削弱这些漏洞。闰秒计划的完整性由操作系统和时间分配机制负责，两者均不在RFC 3550[1]和这些建议的范围内。
The authors would like to thank Steve Allen for his valuable comments that helped to improve this document.
作者要感谢Steve Allen的宝贵意见，这些意见有助于改进本文件。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] IEEE, "Portable Operating System Interface (POSIX)", IEEE Standard 1003.1-2008, December 2008, <http://standards.ieee.org/findstds/standard/1003.1-2008.html>.
[3] IEEE，“便携式操作系统接口（POSIX）”，IEEE标准1003.1-2008，2008年12月<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>.
[4] 谷歌公司，“时间、技术和跳跃秒”，2011年9月<http://googleblog.blogspot.com/2011/09/ 时间技术和跳跃秒。html>。
[5] Kuhn, M., "Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS)", Work in Progress, January 2006.
[5] Kuhn，M.“具有平滑闰秒的协调世界时（UTC-SLS）”，正在进行的工作，2006年1月。
[6] ITU, "Standard-frequency and time-signal emissions", ITU-R TF.460-6, February 2002, <http://www.itu.int/rec/R-REC-TF.460/>.
[6] ITU，“标准频率和时间信号发射”，ITU-R TF.460-62002年2月<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>.
[7] ITU，“UTC时间尺度的未来”，问题ITU-R 236/7，2012年2月<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.
[8] Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[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>.
[9] IEEE，“网络测量和控制系统精确时钟同步协议的IEEE标准”，IEEE标准1588-2008，2008年7月<http://standards.ieee.org/findstds/standard/1588-2008.html>.
[10] Global Positioning Systems Directorate, "Systems Engineering & Integration Interface Specification", September 2011, <http://www.navcen.uscg.gov/pdf/IS-GPS-200F.pdf>.
[10] 全球定位系统理事会，“系统工程与集成接口规范”，2011年9月<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>.
[11] 国际测量局，“国际原子时”，导航星GPS空间段/导航用户段界面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>.
[12] IERS地球定位中心，“公告C-产品元数据”<http://datacenter.iers.org/web/guest/eop/-/somos/5Rgv/ 产品编号/16>。
Authors' Addresses
作者地址
Kevin Gross AVA Networks Boulder, CO US
凯文·格罗斯美国博尔德艾娃网络公司
EMail: kevin.gross@avanw.com
EMail: kevin.gross@avanw.com
Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT the Netherlands
雷范勃兰登堡TNO Brasserspein 2代尔夫特2612荷兰
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl