draft-ietf-avtcore-leap-second-03.txt   draft-ietf-avtcore-leap-second-04.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: January 15, 2014 July 14, 2013 Expires: February 28, 2014 August 27, 2013
RTP and Leap Seconds RTP and Leap Seconds
draft-ietf-avtcore-leap-second-03 draft-ietf-avtcore-leap-second-04
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 January 15, 2014. This Internet-Draft will expire on February 28, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Leap seconds . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Leap seconds . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . 4 4. Receiver behavior during leap second . . . . . . . . . . . . 4
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. RTP Sender Reports . . . . . . . . . . . . . . . . . . . 5 5.1. RTP Sender Reports . . . . . . . . . . . . . . . . . . . 6
5.2. RTP Packet Playout . . . . . . . . . . . . . . . . . . . 6 5.2. RTP Packet Playout . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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
skipping to change at page 3, line 9 skipping to change at page 3, line 9
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2] and document are to be interpreted as described in RFC 2119 [2] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Leap seconds 3. Leap seconds
The world scientific time standard is International Atomic Time (TAI) The world scientific time standard is International Atomic Time (TAI)
which is based on vibrations of cesium atoms in an atomic clock. The which is based on vibrations of cesium atoms in an atomic clock. The
world civil time is based on the rotation of the Earth. In 1972 the world civil time is based on the rotation of the Earth. In 1972 the
civil time standard, Coordinated Universal Time (UTC), was redefined civil time standard, Coordinated Universal Time (UTC), was redefined
in terms of TAI and the concept of leap seconds was introduced to in terms of TAI and the concept of leap seconds was introduced to
allow UTC to remain synchronized with with the rotation of the Earth. allow UTC to remain synchronized with the rotation of the Earth.
Leap seconds are scheduled by the International Earth Rotation and Leap seconds are scheduled by the International Earth Rotation and
Reference Systems Service. Leap seconds may be scheduled at the last Reference Systems Service. Leap seconds may be scheduled at the last
day of any month but are preferentially scheduled for December and day of any month but are preferentially scheduled for December and
June and secondarily March and September.[3] Because Earth's rotation June and secondarily March and September.[3] Because Earth's rotation
is unpredictable, leap seconds are typically not scheduled more than is unpredictable, leap seconds are typically not scheduled more than
six months in advance. six months in advance.
Leap seconds do not respect local time and always occur at the end of 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 the UTC day. Leap seconds can be scheduled to either add or remove a
skipping to change at page 5, line 27 skipping to change at page 5, line 27
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,[6] GPS [7] and other TAI [8] references do not include IEEE 1588,[6] GPS [7] and other TAI [8] references do not include
leap seconds. NTP time, operating system clocks and other UTC leap seconds. NTP time, operating system clocks and other UTC
references include leap seconds. references include leap seconds.
All participants working to a leap-second-bearing reference SHOULD All participants working to a leap-second-bearing reference SHOULD
recognize leap seconds and have a working communications channel to recognize leap seconds and have a working communications channel to
receive notification of leap-second scheduling. receive notification of leap-second scheduling. Note that 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 [5] but also a means for top-tier clocks to receive leap-
second schedule information published by the International Earth
Rotation and Reference Systems Service.
Because of the timestamp ambiguity, positive leap seconds can Because of the timestamp ambiguity, 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
complications. No special treatment with respect to RTP timestamps complications. No special treatment is needed to avoid ambiguity
is required in the presence of a negative leap second. with respect to RTP timestamps in the presence of a negative leap
second.
5.1. RTP Sender Reports 5.1. RTP Sender Reports
RTP Senders working to a leap-second-bearing reference SHOULD NOT RTP Senders working to a leap-second-bearing reference SHOULD NOT
generate sender reports containing an originating NTP timestamp in generate sender reports containing an originating NTP timestamp in
the vicinity of a positive leap second. To maintain a consistent the vicinity of a positive leap second. To maintain a consistent
RTCP schedule and avoid the risk of unintentional timeouts, such RTCP schedule and avoid the risk of unintentional timeouts, such
senders MAY send receiver reports in place of sender reports in the senders MAY send receiver reports in place of sender reports in the
vicinity of the leap second. vicinity of the leap second.
skipping to change at page 6, line 31 skipping to change at page 6, line 40
determining playout time based on RTP timestamps for data in RTP determining playout time based on RTP timestamps for data in RTP
packets. packets.
6. Security Considerations 6. Security Considerations
RTP streams using a wall-clock reference as discussed here present an RTP streams using a wall-clock reference as discussed here present an
additional attack vector compared to self-clocking streams. additional attack vector compared to self-clocking streams.
Manipulation of the wall clock at either sender or receiver can Manipulation of the wall clock at either sender or receiver can
potentially disrupt streaming. potentially disrupt streaming.
For an RTP stream operating to an leap-seocnd-bearing reference to For an RTP stream operating to an leap-second-bearing reference to
operate reliably across a leap second, sender and receive must both operate reliably across a leap second, sender and receive must both
be aware of the leap second. It is possible to disrupt a stream by be aware of the leap second. It is possible to disrupt a stream by
blocking or delaying leap second notification to one of the blocking or delaying leap second notification to one of the
participants. Streaming can be similarly affected if one of the participants. Streaming can be similarly affected if one of the
participants can be tricked into believing a leap second has been participants can be tricked into believing a leap second has been
scheduled where there is not one. These vulnerabilities are present scheduled where there is not one. These vulnerabilities are present
in RFC 3550 [1] and these new recommendations neither heighten or in RFC 3550 [1] and these new recommendations neither heighten or
diminish them. Integrity of the leap second schedule is the diminish them. Integrity of the leap second schedule is the
responsibility of the operating system and time distribution responsibility of the operating system and time distribution
mechanism both of which are outside the scope of RFC 3550 [1] and mechanism both of which are outside the scope of RFC 3550 [1] and
 End of changes. 9 change blocks. 
10 lines changed or deleted 16 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/