Network Working Group D. Brown Internet-Draft Bit9, Inc. Intended status: Experimental S. Farrell Expires: April 28, 2011 Trinity College Dublin S. Burleigh Jet Propulsion Laboratory October 25, 2010 DTN Bundle Age Block for Expiration without UTC draft-irtf-dtnrg-bundle-age-block-01 Abstract As originally specified, [RFC5050] presumes that any DTN node will have access to accurate real world time. Experience has shown that there are devices and networks where accurate real world time is difficult or impossible to consistently obtain. This draft proposes an extension block that contains the current age of a bundle in order to support bundle expiration for nodes and networks that have faulty, intermittent, or no notion of the real world time. Bundle age may be used to expire bundles by a Bundle Protocol Agent which does not have access to accurate real world time. The bundle age must be updated at each hop in order to maintain accuracy. 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 April 28, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Brown, et al. Expires April 28, 2011 [Page 1] Internet-Draft DTN-AGE October 2010 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. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 2. Other Terminology . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Age Extension Block . . . . . . . . . . . . . . . . . . . . . 6 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Age Block Processing . . . . . . . . . . . . . . . . . . . . . 8 6.1. At Nodes without AEB Support . . . . . . . . . . . . . . . 8 6.2. At Nodes with AEB support . . . . . . . . . . . . . . . . 8 6.3. Expiration . . . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Upon Bundle Creation . . . . . . . . . . . . . . . . . . . 8 6.4.1. At Nodes with UTC . . . . . . . . . . . . . . . . . . 8 6.4.2. At Nodes without UTC . . . . . . . . . . . . . . . . . 9 6.5. Upon BPA Enqueuing to CLA . . . . . . . . . . . . . . . . 9 6.5.1. At Nodes with UTC . . . . . . . . . . . . . . . . . . 9 6.5.2. At Nodes without UTC . . . . . . . . . . . . . . . . . 9 6.6. Upon Retrieval from Persistent Storage . . . . . . . . . . 9 6.7. At CLA Transmission and Reception . . . . . . . . . . . . 10 6.8. Upon Reception by BPA . . . . . . . . . . . . . . . . . . 10 6.9. While Bundle Resident at BPA . . . . . . . . . . . . . . . 10 7. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Bundle Forwarding Examples . . . . . . . . . . . . . . . . 11 7.1.1. UTC to non-UTC . . . . . . . . . . . . . . . . . . . . 11 7.1.2. Non-UTC to UTC . . . . . . . . . . . . . . . . . . . . 11 7.2. Interaction with Fragmentation . . . . . . . . . . . . . . 12 7.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Future Considerations . . . . . . . . . . . . . . . . . . . . 13 8.1. Incorporation of Age into Primary Bundle Block . . . . . . 13 8.2. Margin of Error for Time Values . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Brown, et al. Expires April 28, 2011 [Page 2] Internet-Draft DTN-AGE October 2010 1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Brown, et al. Expires April 28, 2011 [Page 3] Internet-Draft DTN-AGE October 2010 2. Other Terminology This document distinguishes between devices which are only able to measure elapsed time and those which have access to global time. By "global time" we mean "an acceptably accurate approximation of the current time reported by the authoritative atomic clocks on Earth". Global time will be referred to as Coordinated Universal Time (UTC) whether the node samples a UTC clock directly or infers UTC based on the local wall clock time and current time zone. Devices which do not have access to UTC will be referred to as having "node local" or just "local" time. Clock accuracy is the additive inverse of clock error. Clock error is the difference between UTC as reported by that clock and UTC as reported by the authoritative atomic clocks on Earth, at a given moment. Stability refers to the ability of a clock to maintain a constant value of clock error. Lack of stability is also referred to as clock drift. Precision refers to the granularity of the time representation. For example, microseconds have higher precision than milliseconds. Brown, et al. Expires April 28, 2011 [Page 4] Internet-Draft DTN-AGE October 2010 3. Introduction Experience has shown that clock drift in DTN nodes is sometimes unavoidable and has detrimental effects on the protocol. The detrimental effects are magnified for bundles sourced with short lifetimes. Additionally, [RFC5050] compliance is not possible when devices do not have access to accurate UTC via either synchronization or an accurate, persistent battery-backed UTC clock. An [RFC5050]- compliant DTN implementation currently requires either an accurate UTC clock or a battery-backed real-time clock (RTC) and the consistent availability of synchronization signals. There is a variety of scenarios where neither of these requirements can be met. Many commercial, of-the-shelf (COTS) devices such as cell phones, smartphones, and military radios contain no internal battery suitable for a persistent RTC, and thus provide no time when powered on outside the reach of provider infrastructure. In the case of smartphones, these devices are generally tamper- resistant and as such offer no reasonable means for changing an internal battery. Military devices tend to eschew internal consumer oriented batteries, which may leak, preferring instead external hardened battery packs which may be disconnected frequently, thus making a persistent clock impractical. Brown, et al. Expires April 28, 2011 [Page 5] Internet-Draft DTN-AGE October 2010 4. Age Extension Block This document proposes the Age Extension Block (AEB), which denotes the time since the bundle has been created, with microsecond precision. The Age Extension Block format below includes the [RFC5050] required block header fields. +----------------+----------------+-------------------+------------+ | Block Type | Proc. Flags(*) | Block Length(*) | Age(*) | +----------------+----------------+-------------------+------------+ Support for the AEB by BPA implementations is RECOMMENDED for interoperability but not required. The Age field is defined to represent the approximate elapsed number of microseconds since the creation of the bundle. Notes: o (*) Indicates field contains a Self-Delimiting Numeric Value (SDNVs). See RFC 5050 [RFC5050] Sec. 4.1. o "Block Type" is a 1-byte mandatory field set to the value 10, indicating the Age Extension Block. See RFC 5050 [RFC5050] Sec. 4.3. o "Block Processing Control Flags" is an SDNV that contains the Bundle Protocol block processing control flags. For the AEB, the "Block must be replicated in every fragment" bit MUST be set. This also dictates that the AEB must occur before the payload block. See RFC 5050 [RFC5050] Sec 4.3. o "Block Length" is a mandatory SDNV that contains the aggregate length of all remaining fields of the block. A one octet SDNV is shown here for convenience in representation. See RFC 5050 [RFC5050] Sec 3.1. Brown, et al. Expires April 28, 2011 [Page 6] Internet-Draft DTN-AGE October 2010 5. Applicability A DTN node that does not have access to UDC MUST set Creation Timestamp Time to zero in each bundle for which it is the source node. Note that this implies that bundles sourced at such a node can only be distinguished (for purposes of custody acceptance, etc.) by Creation Timestamp Sequence Number. Tracking bundle age solely via the AEB is insufficient for applications where a bundle spends an indeterminate amount of time in suspension. When a bundle with a zero-valued Creation Timestamp Time is stored to persistent media, for example, and the time of its storage is unknown or inaccurate, its age cannot in general be determined with any reasonable accuracy upon later being accessed. An example of this situation is when a bundle with a zero-valued Creation Timestamp Time is stored on a USB mass storage device regardless of whether it is treated as a DTN link or node. Unless the time of storage is tracked separately or known to be accurately stored on the filesystem, then the Age is unknown upon access. See also Section 6.6. Brown, et al. Expires April 28, 2011 [Page 7] Internet-Draft DTN-AGE October 2010 6. Age Block Processing 6.1. At Nodes without AEB Support Nodes which do not support the AEB must have access to UTC time and therefore can only expire bundles on the basis described in [RFC5050]. To improve interoperability with BPAs that implement the support for the AEB, whenever a BPA that does not support processing the AEB receives a bundle with Creation Timestamp Time value of zero the BPA MAY use zero as "the current time" for the purposes of Section 5.5 of [RFC5050] with respect to treatment of that bundle. When implemented, this mechanism prevents deletion of the bundle due to an incorrectly computed expiration time. All further specification of AEB treatment applies only to nodes which support the AEB unless stated otherwise. 6.2. At Nodes with AEB support It is expected that implementations which support the AEB will have a means of tracking the elapsed time a bundle is resident at a node in order to appropriately update the AEB age field upon delivery to a local endpoint or forwarding to another node, or to determine the time a bundle should be expired. 6.3. Expiration If the AEB is supported by a receiving node, the bundle MUST be treated as expired if Age > Lifetime. 6.4. Upon Bundle Creation Since a zero-valued Creation Timestamp Time field is used to signal that the sender does not have access to accurate UTC, then a BPA MUST NOT create a bundle with both a zero-valued Creation Timestamp Time and no AEB. For the sake of interoperability it is RECOMMENDED that an AEB be provided whenever it is not impractical to do so. 6.4.1. At Nodes with UTC There may be DTNs where all nodes have accurate realtime clocks, and bundles are not expected to travel to other networks. In these cases, A BPA MAY add a bundle Age Extension Block when creating a bundle. In all other cases, where it is possible that bundles may be Brown, et al. Expires April 28, 2011 [Page 8] Internet-Draft DTN-AGE October 2010 received by nodes without accurate realtime clocks, the AEB SHOULD be added at time of bundle creation. If the BPA has access to UTC upon creation of a bundle, it SHOULD place the current UTC into the Creation Timestamp Time field when creating a bundle. 6.4.2. At Nodes without UTC If a BPA does not have access to UTC or chooses not to set the Creation Timestamp to UTC, a BPA MUST create an AEB with Age value 0. 6.5. Upon BPA Enqueuing to CLA 6.5.1. At Nodes with UTC Any time a bundle is enqueued at a CLA for transmission by a BPA with access to UTC, the BPA SHOULD first update the AEB age field as UTC - Creation Timestamp Time. This applies regardless of where in the network the bundle originated. 6.5.2. At Nodes without UTC If UTC is unavailable, the AEB age field should be increased by the time which has elapsed since the age field was last updated or if the age field was not updated, by the elapsed time since the bundle was received. This applies regardless of where in the network the bundle originated. 6.6. Upon Retrieval from Persistent Storage A bundle with a zero-valued Creation Timestamp Time and with an indeterminate age MAY be treated as expired upon being read from persistent storage. This situation arises, for example, when a node without access to UTC accesses bundles from persistent storage after power cycling. Such a node cannot determine the elapsed time that a bundle has spent in persistent storage across power cycles. If a node has additional resources to spare or if it is pertinent to do so, bundles with a zero-valued Creation Timestamp Time and with an indeterminate age MAY be forwarded in a best-effort manner as the data may still be relevant to the recipient. Bundles with a non-zero Creation Timestamp Time MAY be forwarded since it may be possible for some node with UTC to accurately update the AEB age field. Brown, et al. Expires April 28, 2011 [Page 9] Internet-Draft DTN-AGE October 2010 6.7. At CLA Transmission and Reception In some networks a convergence layer and/or the CLA may impose non- negligible delays. In deep space networks, propagation delay can be significant. Other CLAs may impose other delays, for example CLAs which provide some notion of reliable delivery to multiple neighbors. A CLA SHOULD convey additional delays imposed either by non- negligible propagation delay or non-negligible queuing delay at the CLA. The CLA implementation should make provisions for either the sender or receiver or some combination of sender and receiver to provide this information. This representation SHOULD be made available to the receiving BPA as an elapsed value conveyed by the CLA to the BPA with the bundle. 6.8. Upon Reception by BPA In general, a DTN node should maintain an accurate representation of a bundle's age so that the bundle can be accurately expired and the AEB field can be accurately maintained across transmissions. Each time the bundle is delivered to a local endpoint or forwarded to another node, the AEB should be made to reflect the age of the bundle as accurately as possible. This implies that nodes without UTC will need to store the node-local time associated with the reception of a bundle in order to later determine the elapsed resident time and accurately update the AEB Age field upon transmission or delivery, or to determine the node-local time at which the bundle should expire; nodes with access to UTC must store the UTC at the time the bundle was received, for the same purpose. The Age field is updated as Age = Age + ElapsedTime, where ElapsedTime = NodeLocalTime - RecordedNodeLocalTime or ElapsedTime = UTC - RecordedUTC. The BPA SHOULD take into account elapsed time spent at a CLA if the CLA provides this information. The age field should be updated upon reception by the BPA in this case by Age = Age + ElapsedTimeAtCLA. 6.9. While Bundle Resident at BPA A resident bundle whose age exceeds its lifetime while residing at a node MUST be expired. Note that age in this context needs to include the bundle's AEB age field and any elapsed time while resident at the node which is not presently accounted for in the age field. Brown, et al. Expires April 28, 2011 [Page 10] Internet-Draft DTN-AGE October 2010 7. Interoperability Interoperability can be achieved between nodes which support AEB or between nodes which have access to UTC. Since the AEB provides the necessary time information for a node without UTC to process the bundle, the only circumstance in which interoperability cannot be achieved is between an implementation which does not support the AEB (and which therefore must have access to UTC), and another node which does not have access to UTC. If a bundle is sourced by a UTC node without an AEB, nodes without UTC cannot reasonably process the bundle. If a bundle is sourced by a node without UTC (and must therefore have an AEB), this bundle cannot be reasonably processed by a UTC node which has no AEB support (with the possible exception of being allowed to forward the bundle without delay, see Section 6.1). This interoperability issue may be partly mitigated by the provision of a gateway node which adds AEB extension blocks to bundles which are sourced without one. This allows nodes without UTC to process bundles sourced by UTC nodes that do not support the AEB. For the time being, interoperability can only be fully realized in networks which contain only nodes with UTC or in networks where all nodes implement the AEB. See Section 8.1. 7.1. Bundle Forwarding Examples 7.1.1. UTC to non-UTC A UTC node which supports the age extension block creates a bundle which uses UTC in the Creation Timestamp Time field, and presumably a small or zero-valued AEB age field. The bundle is forwarded to a non-UTC node. The non-UTC node examines the age field, compares Age to Lifetime and determines that the bundle is still valid. The node also associates the node-local time with the bundle as soon as it arrives. Upon retransmitting the bundle or delivering the bundle to an application, presuming it has not expired, the node calculates the AEB age field as: Age = Age + NodeLocalTime - RecordedNodeLocalTime. 7.1.2. Non-UTC to UTC A Non-UTC node can only process bundles which have an AEB and so we can presume that a bundle forwarded from a Non-UTC node has an AEB. We will also presume for this example that the bundle originated like it did in the previous example at a UTC node and therefore has a non- Brown, et al. Expires April 28, 2011 [Page 11] Internet-Draft DTN-AGE October 2010 zero Creation Timestamp Time. In this case the bundle arrives at the receiving UTC node which, seeing the non-zero Creation Timestamp Time ignores the AEB and processes the bundle as described in RFC 5050. Upon forwarding the bundle to a next hop, the UTC node updates the Age field as: Age = UTC - Creation Timestamp Time. If the bundle was instead sourced at a Non-UTC node, then the bundle has a zero-valued Creation Timestamp Time. Upon receiving this bundle, the UTC node records the bundle's UTC time of arrival. Upon transmitting or delivering this bundle, the node updates the AEB age field based on UTC - RecordedBundleUTC. 7.2. Interaction with Fragmentation A BPA needs to fragment a bundle which is larger than the MTU imposed by the CLA over which the bundle will be forwarded. In that case, the BPA creates bundle fragments which are themselves bundles. These bundles may be forwarded at different times and therefore must carry different age values. Because of this, the "Block must be replicated in every fragment" bit must be set for the AEB, and each bundle fragment must have its AEB age field appropriately set according to the specifications contained here. 7.3. Security When security is a concern and since the AEB age field can change at each hop, the AEB MAY be encrypted on a hop-by-hop basis via the Bundle Security Protocol provided by [I-D.irtf-dtnrg-bundle-security] Section 2.5. In that case, the Security-destination MUST be present and MUST specify the EID of the next forwarding hop. Brown, et al. Expires April 28, 2011 [Page 12] Internet-Draft DTN-AGE October 2010 8. Future Considerations 8.1. Incorporation of Age into Primary Bundle Block It is strongly recommended that specification of Age at bundle inception and the processing of Age values become mandated by moving the Age value in some form into the primary bundle block at some future time. This will improve interoperability and precision of bundle expiration without detrimental effect on expiration semantics for current [RFC5050] implementations. 8.2. Margin of Error for Time Values As previously shown, the AEB's age may contain some error. Propagation delay that is difficult or impossible to account for is one potential source of error. This type of error may accumulate at each hop. Another potential source of error is an inaccurate RTC. Nodes which have a somewhat synchronized but potentially inaccurate clock require some means for expressing the potential inaccuracy of Creation Timestamp Times for sourced bundles. In the former case, a Margin of Error (MOE) field associated with the Age value seems like a reasonable mechanism for extending bundle lifetime in the face of accumulated Age error. The MOE field represents plus-or-minus uncertainty. For example, a 5 second MOE indicates that the Age is expected to be accurate to within +/- 5 seconds. A bundle SHOULD NOT be considered expired unless Age - AgeMOE - CreationMOE > Lifetime. In the latter case, a node with a somewhat synchronized RTC might create bundles with a non-zero Creation Timestamp Time. In this case, the Age value can be considered a more accurate representation of the bundle's age than CurrentTime - Creation Timestamp Time. However, without being able to represent this state of affairs, a node with an accurate RTC may incorrectly adjust the Age value since it may only presume that the Creation Timestamp Time is accurate. Considering MOE values for Age, Creation, RTC, the bundle SHOULD be expired if and only if Age - CreationMOE - AgeMOE > Lifetime or RTC - RTCMOE > Lifetime. Here is a graphical depiction of MOE for Age, Creation Timestamp Time and RTC: Brown, et al. Expires April 28, 2011 [Page 13] Internet-Draft DTN-AGE October 2010 ================== Lifetime ==================== | ____| |\ + RTCMOE | \ ----| } <-- RTC - RTCMOE | / ____|/ | |____ /| / | + AgeMOE Age --> { |---- \ | - AgeMOE \|____ | | |____ /| / | + CreationMOE Creation --> { |-- \ | - CreationMOE \|____ | Margin of Error This would seem to argue for an eventual specification of margin of error for some or all time fields specified in the bundle. Since these considerations involve additional complexity and potential changes to [RFC5050] itself, they are only noted in this document as future considerations and not treated normatively for the protocol. Brown, et al. Expires April 28, 2011 [Page 14] Internet-Draft DTN-AGE October 2010 9. IANA Considerations This extension block has fields requiring registries managed by IANA. 9.1. Bundle Block Types This specification allocates one codepoint from the existing Bundle Block Type Codes registry defined in [I-D.irtf-dtnrg-iana-bp-registries]. Additional Entries for the Bundle Block Type Codes Registry: +-------+----------------------------------------+----------------+ | Value | Description | Reference | +-------+----------------------------------------+----------------+ | 10 | Age Extension Block | This document | +-------+----------------------------------------+----------------+ Brown, et al. Expires April 28, 2011 [Page 15] Internet-Draft DTN-AGE October 2010 10. References [I-D.irtf-dtnrg-bundle-security] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", draft-irtf-dtnrg-bundle-security-16 (work in progress), July 2010. [I-D.irtf-dtnrg-iana-bp-registries] Blanchet, M., "Delay-Tolerant Networks (DTN) Bundle Protocol IANA Registries", draft-irtf-dtnrg-iana-bp-registries-00 (work in progress), April 2010. [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. Brown, et al. Expires April 28, 2011 [Page 16] Internet-Draft DTN-AGE October 2010 Authors' Addresses Daniel W. Brown Bit9, Inc. Stephen Farrell Trinity College Dublin Distributed Systems Group Department of Computer Science Trinity College Dublin 2 Ireland Phone: +353-1-896-2354 Email: stephen.farrell@cs.tcd.ie Scott Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive, m/s 301-490 Pasadena, California 91109 USA Phone: +1-818-393-3353 Email: scott.c.burleigh@jpl.nasa.gov Brown, et al. Expires April 28, 2011 [Page 17]