draft-ietf-avtcore-leap-second-07.txt   draft-ietf-avtcore-leap-second-08.txt 
AVTCore K. Gross AVTCore K. Gross
Internet-Draft AVA Networks Internet-Draft AVA Networks
Updates: 3550 (if approved) R. van Brandenburg Updates: 3550 (if approved) R. van Brandenburg
Intended status: Standards Track TNO Intended status: Standards Track TNO
Expires: June 30, 2014 December 27, 2013 Expires: July 16, 2014 January 12, 2014
RTP and Leap Seconds RTP and Leap Seconds
draft-ietf-avtcore-leap-second-07 draft-ietf-avtcore-leap-second-08
Abstract Abstract
This document discusses issues that arise when RTP sessions span This document discusses issues that arise when RTP sessions span
Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550
to describe how RTP senders and receivers should behave in the to describe how RTP senders and receivers should behave in the
presence of leap seconds. presence of leap seconds.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 30, 2014. This Internet-Draft will expire on July 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 19 skipping to change at page 2, line 19
3. Leap seconds . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Leap seconds . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. UTC behavior during positive leap second . . . . . . . . 3 3.1. UTC behavior during positive leap second . . . . . . . . 3
3.2. NTP behavior during positive leap second . . . . . . . . 3 3.2. NTP behavior during positive leap second . . . . . . . . 3
3.3. POSIX behavior during positive leap second . . . . . . . 3 3.3. POSIX behavior during positive leap second . . . . . . . 3
3.4. Example of leap-second behaviors . . . . . . . . . . . . 4 3.4. Example of leap-second behaviors . . . . . . . . . . . . 4
4. Receiver behavior during leap second . . . . . . . . . . . . 5 4. Receiver behavior during leap second . . . . . . . . . . . . 5
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Sender Reports . . . . . . . . . . . . . . . . . . . . . 6 5.1. Sender Reports . . . . . . . . . . . . . . . . . . . . . 6
5.2. RTP Packet Playout . . . . . . . . . . . . . . . . . . . 7 5.2. RTP Packet Playout . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
In some media networking applications, RTP streams are referenced to In some media networking applications, RTP streams are referenced to
a wall-clock time (absolute date and time). This is accomplished a wall-clock time (absolute date and time). This is accomplished
through use of the NTP timestamp field in the sender report (SR) to through use of the NTP timestamp field in the sender report (SR) to
skipping to change at page 5, line 40 skipping to change at page 5, line 40
resolved, such receivers may need to resynchronize again. resolved, such receivers may need to resynchronize again.
5. Recommendations 5. Recommendations
Senders and receivers which are not referenced to a wall clock are Senders and receivers which are not referenced to a wall clock are
not affected by issues associated with leap seconds and no special not affected by issues associated with leap seconds and no special
accommodation is required. accommodation is required.
RTP implementation using a wall-clock reference is simplified by RTP implementation using a wall-clock reference is simplified by
using a clock with a timescale which does not include leap seconds. using a clock with a timescale which does not include leap seconds.
IEEE 1588,[9] GPS [10] and other TAI [11] references do not include IEEE 1588,[9] GPS [10] and other systems that use a TAI [11]
leap seconds. NTP time, operating system clocks and other UTC reference do not include leap seconds. NTP time, operating system
references include leap seconds. 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
synthezise a leap-second-bearing UTC reference clock. For the
purposes of this draft, it is important to recognise that it is the
timescale used, not the delivery mechanism which determines whether a
reference clock is leap-second bearing.
+-------------------------+----------------+---------------+ +-------------------------+----------------+---------------+
| Reference clock type | Examples | Accommodation | | Reference clock type | Examples | Accommodation |
+-------------------------+----------------+---------------+ +-------------------------+----------------+---------------+
| None | Self clocking | None needed | | None | Self clocking | None needed |
| Non-leap-second-bearing | 1588, GPS, TAI | None needed | | Non-leap-second-bearing | 1588, GPS, TAI | None needed |
| Leap-second-bearing | NTP | Recommended | | Leap-second-bearing | NTP | Recommended |
+-------------------------+----------------+---------------+ +-------------------------+----------------+---------------+
Recommendations summary Recommendations summary
All participants working to a leap-second-bearing reference SHOULD All participants working to a leap-second-bearing reference MUST
recognize leap seconds and have a working communications channel to recognize leap seconds and SHOULD have a working communications
receive notification of leap-second scheduling. Note that a working channel to receive notification of leap-second scheduling. A working
communication channel includes a protocol means of notifying clocks communication channel includes a protocol means of notifying clocks
of an impending leap second such as the Leap Indicator in the NTP of an impending leap second such as the Leap Indicator in the NTP
header [8] but also a means for top-tier clocks to receive leap- header [8] but also a means for top-tier clocks to receive leap-
second schedule information published by the International Earth second schedule information published by the International Earth
Rotation and Reference Systems Service. [12] Rotation and Reference Systems Service. [12]
These recommendations appreciate that 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 Because of the timestamp ambiguity that positive leap seconds can
introduce and the inconsistent manner in which different systems introduce and the inconsistent manner in which different systems
accommodate positive leap seconds, generating or using NTP timestamps accommodate positive leap seconds, generating or using NTP timestamps
during the entire last second of a day on which a positive leap 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 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 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 example, the region to be avoided is indicated by RTP timestamps
12000 through 28000 12000 through 28000
Negative leap seconds do not introduce timestamp ambiguity or other Negative leap seconds do not introduce timestamp ambiguity or other
 End of changes. 8 change blocks. 
12 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/