Boeing Research & Technology

P.O. Box 3707 Seattle WA 98124 USA fltemplin@acm.org

I-D Internet-Draft 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.

The Delay/Disruption Tolerant Network (DTN) architecture 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 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 . , 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 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.

Time synchronization in the Bundle Protocol serves three purposes: Bundle lifetimes keep bundles from looping continuously due to routing loops The lifetime allows the network to purge expired bundles 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 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.

There are no IANA considerations for this document.

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 .

Time synchronization has been discussed broadly in DTN mailing list discussions as well as in many of the documents cited in this publication.