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 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
• 2. Discussion
• 3. IANA Considerations
• 4. Security Considerations
• 5. Acknowledgments
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address

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 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

6.2. Informative References

Author's Address