Internet DRAFT - draft-templin-dtntsync
draft-templin-dtntsync
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational March 12, 2014
Expires: September 13, 2014
Delay Tolerant Networking Time Synchronization - Problem Statement
draft-templin-dtntsync-00.txt
Abstract
Delay/Disruption Tolerant Networking (DTN) introduces a network model
in which communications may be subject to long delays and/or
intermittent connectivity. DTN nodes include timestamps in the
bundles of data they send so that correspondents can identify the
bundles and determine the length of time they have been in the
system. However, there is currently no specified strategy for
synchronizing the clocks between DTN nodes. This document therefore
presents a problem statement for time synchronization in DTNs.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 13, 2014.
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
Templin Expires September 13, 2014 [Page 1]
Internet-Draft DTNTSYNC March 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Templin Expires September 13, 2014 [Page 2]
Internet-Draft DTNTSYNC March 2014
1. Introduction
The Delay/Disruption Tolerant Network (DTN) architecture [RFC4838]
introduces a data communications concept in which "bundles" of data
are exchanged in store-and-forward fashion between endpoints that may
be separated by long-delay or intermittently-connected paths. The
Bundle Protocol Specification [RFC5050] provides the bundle message
format and operations, including convergence layer transmission,
fragmentation and custody transfer. Each bundle further may include
extensions, among which may be security parameters designed to ensure
confidentiality, integrity and authorization
[RFC6257][I-D.irtf-dtnrg-sbsp].
[WOOD08], Sections 4.2 - 4.4 has shown that time synchronization is
an important aspect of correct operation. In particular, the study
points out that Bundle Protocol agents that obey [RFC5050] require a
tightly-synchronized notion of Coordinated Universal Time (UTC).
However, there may be operational use cases in which time
synchronization without reliance on the Bundle Protocol itself may be
difficult or impossible to achieve. This document therefore
discusses problematic aspects of the Bundle Protocol time
synchronization requirement as motivation for solution proposals.
2. Discussion
Time synchronization in the Bundle Protocol serves three purposes:
1. Bundle lifetimes keep bundles from looping continuously due to
routing loops
2. The lifetime allows the network to purge expired bundles
3. The creation timestamp is used to uniquely identify each bundle.
However, the creation timestamp applied to each bundle is relative to
the clock of the DTN source node that produced the bundle. If the
source node's clock is sufficiently drifted from UTC, this could
result in several failure modes. First, if a forwarding DTN node on
the path to the final destination(s) receives a bundle whose
timestamp appears to be in the future, the forwarding node may drop
the bundle unconditionally and thereby deny service to the source
node. This can be due to either a time advancement in the source
node's clock or a time lag in the forwarding node's clock.
Second, if the timestamp applied by the source node is sufficiently
advanced into the future and the bundle is not rejected by forwarding
nodes, the bundle could spin continuously in a routing loop that is
Templin Expires September 13, 2014 [Page 3]
Internet-Draft DTNTSYNC March 2014
sustained longer than would be indicated by the bundle lifetime
(thereby wasting network resources). Finally, if the source node's
clock has drifted sufficiently into the past, any forwarding nodes
might discard the bundle based on the lifetime at a time that is
earlier than the source node intended.
Clearly, the current Bundle Protocol specification is dependent on
closely synchronized clocks for proper operation, while clock
synchronization may be difficult or impossible to achieve in some
applications. Also clearly, there may be other methods than strict
clock synchronization that can address the purposes listed above.
This document does not speculate as to alternate methods, but rather
outlines the problems and invites solution proposals.
3. IANA Considerations
There are no IANA considerations for this document.
4. Security Considerations
Timestamps are an integral aspect of security, since mistaken notions
of time may result in resource consumtion denial of service attack
vectors..
Bundle Protocol security considerations are discussed in
[RFC6257][I-D.irtf-dtnrg-sbsp].
5. Acknowledgments
Time synchronization has been discussed broadly in DTN mailing list
discussions as well as in many of the documents cited in this
publication.
6. References
6.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
Templin Expires September 13, 2014 [Page 4]
Internet-Draft DTNTSYNC March 2014
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
6.2. Informative References
[I-D.irtf-dtnrg-sbsp]
Birrane, E., "Streamlined Bundle Security Protocol
Specification", draft-irtf-dtnrg-sbsp-00 (work in
progress), July 2013.
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257,
May 2011.
[WOOD08] Wood, L., Eddy, W., and P. Holliday, "A Bundle of
Problems", December 2008.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires September 13, 2014 [Page 5]
