One document matched: draft-irtf-dtnrg-bundle-age-block-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1112 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1112.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3171 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3171.xml'>
<!ENTITY rfc3376 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3376.xml'>
<!ENTITY rfc3927 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3927.xml'>
<!ENTITY rfc3986 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml'>
<!ENTITY rfc4838 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4838.xml'>
<!ENTITY rfc5050 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5050.xml'>
<!ENTITY I-D.irtf-dtnrg-bundle-security PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-irtf-dtnrg-bundle-security-15.xml'>
]>
<!-- TODO: authors, references -->
<rfc category="exp" ipr="trust200902" docName="draft-irtf-dtnrg-bundle-age-block-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<!--
$Id$
$Author$
$Date$
-->
<front>
<title abbrev="DTN-AGE">DTN Bundle Age Block for Expiration without UTC</title>
<author initials="D." surname="Brown" fullname="Daniel W. Brown">
<organization>
Raytheon BBN Technologies
</organization>
<address>
<postal>
<street>10 Moulton St.</street>
<city>Cambridge</city> <region>MA</region>
<code>02138</code>
<country>US</country>
</postal>
<email>dbrown@bbn.com</email>
</address>
</author>
<author initials="S." surname="Farrell" fullname="Stephen Farrell">
<organization>Trinity College Dublin</organization>
<address>
<postal>
<street>Distributed Systems Group</street>
<street>Department of Computer Science</street>
<street>Trinity College </street>
<city>Dublin</city>
<code>2</code>
<country>Ireland</country>
</postal>
<phone>+353-1-896-2354</phone>
<email>stephen.farrell@cs.tcd.ie</email>
</address>
</author>
<author fullname="Scott Burleigh" initials="S.B." surname="Burleigh">
<organization>Jet Propulsion Laboratory</organization>
<address>
<postal>
<street>4800 Oak Grove Drive, m/s 301-490</street>
<city>Pasadena</city>
<region>California</region>
<code>91109</code>
<country>USA</country>
</postal>
<phone>+1-818-393-3353</phone>
<email>scott.c.burleigh@jpl.nasa.gov</email>
</address>
</author>
<date/>
<abstract>
<t>
As originally specified, <xref target='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.
</t>
<t>
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 Age must be updated at each
hop in order to maintain accuracy.
</t>
</abstract>
</front>
<middle>
<section title="Requirements Terminology">
<t>
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.
</t>
</section>
<section title="Other Terminology">
<t> This document distinguishes between devices which are only able to
measure elapsed time and those which have access to global time. Access
to global time will be referred to as Coordinated Universal Time (UTC)
whether the node stores UTC directly or can infer it 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. </t>
<t> Accuracy refers to the ability of a node to maintain correct elapsed
or UTC time since the last synchronization information received. Lack
of accuracy is also referred to as clock drift. </t>
<t> Precision refers to the granularity of the time representation. For example,
microseconds is higher precision than milliseconds. </t>
</section>
<section title="Introduction">
<t> 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. </t>
<t> Additionally, <xref target='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 <xref target='RFC5050'/>-compliant DTN implementation currently
requires either an accurate UTC clock or a battery-backed RTC and the
consistent availability of synchronization signals. </t>
<t> There is a variety of scenarios where neither of these requirements can
be met. Many COTS devices such as cell phones, smartphones, and military
radios contain no internal battery suitable for a persistent RTC,
and so provide no time when powered on outside the reach of provider infrastructure. </t>
<t> In the case of smartphones, these devices
are generally tamper-resistent 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,
making a persistent clock impractical. </t>
</section>
<section title="Age Extension Block">
<t> This document proposes an Age Extension Block (AEB),
which denotes the time since the bundle has been created, with microsecond
precision. </t>
<t> The Age Extension Block format below includes the <xref target='RFC5050'/> required
block header fields. </t>
<figure title="">
<artwork>
+----------------+----------------+-------------------+------------+
| Block type | Proc. Flags (*)| Block length(*) | Age(*) |
+----------------+----------------+-------------------+------------+
(*) Self-Delimiting Numeric Values (SDNVs). See RFC 5050 Sec. 4.1
</artwork>
</figure>
<t> Support for the AEB by BPA implementations is RECOMMENDED for
interoperability but not required. </t>
<t> The Age field is defined to represent the approximate elapsed number of
microseconds since the creation of the bundle. </t>
<t> The "Block must be replicated in every fragment" bit must be set
for the AEB. This also dictates that the AEB must occur before the
payload block per <xref target='RFC5050'/> Sec. 4.3. </t>
</section>
<section title="Applicability">
<t> 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 CreationTimestamp 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. </t>
<t> An example of this situation is when a bundle with a zero-valued
CreationTime 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. </t>
<t> See also <xref target="upon_access_from_storage"/>. </t>
</section>
<section title="Age Block Processing">
<section title="At Nodes without AEB Support" anchor="no_aeb_support">
<t> Nodes which do not support the AEB must have access to UTC time and
therefore can only expire bundles on the basis described in <xref target='RFC5050'/>.</t>
<t> 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 time
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. </t>
<t> All further specification of AEB treatment applies only to nodes
which support the AEB unless stated otherwise. </t>
</section>
<section title="At nodes with AEB support">
<t> 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.</t>
</section>
<section title="Expiration">
<t> If the AEB is supported by a receiving node, the bundle MUST be treated
as expired if Age > Lifetime. </t>
</section>
<section title="Upon Bundle Creation">
<t> Since a zero-valued Creation 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 Time and no AEB. </t>
<t> For the sake of interoperability it is RECOMMENDED that an AEB be
provided whenever it is not impractical to do so. </t>
<section title="At nodes with UTC">
<t> 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 received by nodes without
accurate realtime clocks, the AEB SHOULD be added at creation time. </t>
<t> If the BPA has access to UTC upon creation of a bundle, it SHOULD
place the current UTC into the Creation Timestamp field when creating
a bundle. </t>
</section>
<section title="At nodes without UTC">
<t> If a BPA does not have access to UTC or chooses not to set the Creation
Timestamp on UTC, a BPA MUST create an AEB with value 0 and set the Lifetime
field to the desired time to live for the bundle. </t>
</section>
</section>
<section title="Upon BPA Enqueuing to CLA">
<section title="At nodes with UTC">
<t> 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 - CreationTimestamp. This applies whether the bundle originated
at the node or this node is forwarding a bundle originating at
another node. </t>
</section>
<section title="At nodes without UTC">
<t> 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 whether the bundle originated
at the node or this node is forwarding a bundle originating at
another node. </t>
</section>
</section>
<section title="Upon Retrieval from Persistent Storage"
anchor="upon_access_from_storage">
<t> A bundle with a zero-valued CreationTime and with an
indeterminate age SHOULD 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. </t>
<t> Bundles with a non-zero CreationTime MAY be forwarded since it
may be possible for some node with UTC to accurately update the AEB age
field. </t>
</section>
<section title="At CLA Transmission and Reception">
<t> 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. </t>
<t> A CLA SHOULD convey additional delays imposed either by non-neglible
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.</t>
<t> This representation SHOULD be made available to the receiving BPA
as an elapsed value conveyed by the CLA to the BPA with the bundle. </t>
</section>
<section title="Upon Reception by BPA">
<t> 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 UTC or 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 UTC or node-local time at which the bundle
should expire. The age field is updated as
Age = Age + ElapsedTime, where ElapsedTime = NodeLocalTime - RecordedNodeLocalTime or
ElapsedTime = UTC - RecordedUTC. </t>
<t> 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.</t>
</section>
<section title="While Bundle Resident at BPA">
<t> A resident bundle whose age exceeds its lifetime while residing at a node
should 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. </t>
</section>
</section>
<section title="Interoperability">
<t> 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.</t>
<t> 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
<xref target="no_aeb_support"/>).</t>
<t> 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. </t>
<t> 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 <xref target="age_in_primary_block"/>. </t>
<section title="Bundle Forwarding Examples">
<section title="UTC to non-UTC">
<t> A UTC node which supports the age extension block creates a bundle which
has a UTC timestamp for the creation 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 + UTC - RecordedUTC. </t>
</section>
<section title="Non-UTC to UTC">
<t> 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-zero CreationTimestamp. In this case the
bundle arrives at the receiving UTC node which, seeing the non-zero CreationTimestamp
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 - CreationTimestamp. </t>
<t> If the bundle was instead sourced at a Non-UTC node, then the bundle has a
zero-valued CreationTimestamp. 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. </t>
</section>
</section>
<section title="Interaction with Fragmentation">
<t> 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. </t>
</section>
<section title="Security">
<t> 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 <xref target="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. </t>
</section>
</section>
<section title="Future Considerations">
<section title="IANA Considerations">
<t> An IANA block type registration for the AEB will need eventually be created. </t>
</section>
<section title="Incorporation of Age into Bundle Primary Block" anchor="age_in_primary_block">
<t> 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 Bundle primary block at some future time.
This will improve interoperability and precision of bundle expiration
without detrimental effect on expiration semantics for current <xref target='RFC5050'/>
implementations. </t>
</section>
<section title="Margin of Error for Time Values">
<t> 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 timestamps for sourced bundles. </t>
<t> 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. </t>
<t> A bundle SHOULD NOT be considered expired unless Age - AgeMOE - CreationMOE > Lifetime. </t>
<t> In the latter case, a node with a somewhat synchronized RTC might create
bundles with a non-zero Creation timestamp. In this case, the Age value can
be considered a more accurate representation of the bundle's age than
CurrentTime - CreationTime. 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 CreationTime is accurate. </t>
<t> Considering MOE values for Age, Creation, RTC, the bundle SHOULD be expired
if and only if Age - CreationMOE - AgeMOE > Lifetime or RTC - RTCMOE > Lifetime. </t>
<t> Here is a graphical depiction of MOE for Age, Creation time and RTC: </t>
<figure title="Margin of Error">
<artwork>
================== Lifetime ====================
|
____|
|\
+ RTCMOE | \
----| } <-- RTC
- RTCMOE | /
____|/
|
|____
/|
/ | + AgeMOE
Age --> { |----
\ | - AgeMOE
\|____
|
|
|____
/|
/ | + CreationMOE
Creation --> { |--
\ | - CreationMOE
\|____
|
</artwork>
</figure>
<t> 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
<xref target='RFC5050'/> itself, they are only noted in this document as future considerations
and not treated normatively for the protocol. </t>
</section>
</section>
</middle>
<back>
<references title="References">
&rfc4838;
&rfc5050;
&I-D.irtf-dtnrg-bundle-security;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:27:35 |