DTN Research Group S. Parikh
Internet-Draft S. Symington
Intended status: Experimental K. Scott
Expires: July 9, 2009 R. Durst
R. Edell
The MITRE Corporation
January 5, 2009
Delay-Tolerant Networking Superseding Bundle Extension Block
draft-parikh-bundle-superseding-extension-block-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 9, 2009.
Copyright Notice
Copyright (c) 2009 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.
Parikh, et al. Expires July 9, 2009 [Page 1]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
Abstract
This document defines an optional Bundle Protocol block called the
Superseding Bundle Extension Block (SBEB) for use with the Bundle
Protocol in the context of the Delay-Tolerant Networking
Architecture. Applications use this block to call for the removal of
previously sent bundles that are rendered obsolete by more recent
bundles. Upon receiving a bundle with an SBEB, a node will search
its bundle store (and outbound queues) for bundles that are obsoleted
by other related bundles according to their source and destination
EID, and the SBEB cookie (if present), and may delete some or all of
them. Discarding obsolete bundles helps conserve storage space and
prevents expending resources in further forwarding bundles that are
no longer relevant. The bundle protocol already uses expiration
times to remove bundles that are no longer useful to applications.
The SBEB is a way for applications to mark bundles that a node may
delete prior to their expiration times.
Parikh, et al. Expires July 9, 2009 [Page 2]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Superseding Bundle Extension Block Format . . . . . . . . . . 7
4. Superseding Bundle Block Processing . . . . . . . . . . . . . 9
4.1. Bundle Transmission . . . . . . . . . . . . . . . . . . . 9
4.2. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 9
4.3. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 9
5. Interactions with Bundle Protocol Features . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Parikh, et al. Expires July 9, 2009 [Page 3]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
1. Introduction
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 [1].
This document defines an optional Bundle Protocol block called the
Superseding Bundle Extension Block (SBEB) for use with the Bundle
Protocol [2] in the context of the DTN Architecture [3].
Applications use this block to call for the removal of previously
sent bundles that are rendered obsolete by more recent bundles. Upon
receiving a bundle with an SBEB, a node will search its bundle store
(and outbound queues) for bundles that are obsoleted by other related
bundles according to their source and destination EID and the SBEB
cookie (if present), and may delete some or all of them. Thus, a
bundle with an SBEB can trigger the flushing of bundles from nodes as
it traverses the network.
A newly arriving bundle might render obsolete an older bundle that is
currently in the store, and the node may delete it. If an older
bundle arrives after a newer bundle (possible because of out-of-
sequence arrivals), then the node may delete the older (but most
recently arrived) bundle. The SBEB includes a retention count that
instructs the node to retain a number (not just one) of the newest
bundles according to their timestamp.
Discarding obsolete bundles helps conserve storage space and prevents
expending resources in further forwarding bundles that are no longer
relevant. The bundle protocol already uses expiration times to
remove bundles that are no longer useful to applications. The SBEB
is a way for applications to mark bundles that a node may delete
prior to their expiration times. However, this extension is not
intended as a reliable mechanism for applications to eliminate
bundles in the network; it is intended to assist in reducing the load
on DTN nodes and the network.
The capabilities described in this document are optional for
deployment with the Bundle Protocol. The use of this extension block
is voluntary by applications, and even bundle nodes that support it
can choose to ignore it. To support this extension, a bundle
protocol agent must be capable of receiving bundles with this
extension block and processing them as described in this document.
Parikh, et al. Expires July 9, 2009 [Page 4]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
2. Motivation
This extension is motivated by applications that send "cyclic
telemetry", that is, bundles containing information that supplants
information in previously sent bundles.
The primary example comes from applications that distribute status
updates. Consider a server that tracks the location of vehicles and
distributes that information to clients over a network of DTN nodes.
The server sends a bundle containing the location of a particular
vehicle when that vehicle reports its position to the server. The
clients only want the most recent location of each vehicle; the
history of the vehicle's location is not useful information (in this
particular example). Therefore, if multiple location updates are
present in a node's bundle store, the node need only forward the most
recent one. By using SBEB, the server can send bundles that will
replace older bundles along the path to the destination. In this
example, the application may use an EID that only identifies the
source application, not the vehicle to which the bundle pertains
(that is, it uses the same source EID regardless of the particular
vehicle). The payload will contain an identifier of the vehicle and
its location; thus, a node will need additional information to
identify bundles that pertain to a particular vehicle, because nodes
do not examine bundle payloads. The cookie field in the extension
block can contain an identifier for the vehicle, and the node can
search the bundle store for bundles with that cookie (in addition to
the source and destination).
A motivating case for retaining more than one matching bundle comes
from a camera system that monitors highway traffic, intended for
commuters to check roadways that are prone to gridlock or accidents,
so they can plan their trip accordingly. The camera sends a snapshot
bundle once every minute to a collecting server over a network of DTN
nodes. The server then posts that image on a website which commuters
check over the Internet (the cameras are not on the Internet). The
expiration time of bundles containing the snapshots are
conservatively set to 10 minutes to give the image sufficient
lifetime to traverse the challenged network of DTN nodes. Suppose
that an intermittent link in the challenged network results in
snapshot bundles accumulating at a node. Only the five (for the sake
of example) most recent photos are useful; previous photos in the
bundle store are not. This gives an observer enough pictures to
gauge the flow of traffic (something that might be difficult for the
camera to compute), but a complete historical record of all images is
not needed. The SBEB instructs the node to retain only the freshest
images and delete the others, thereby releasing storage resources and
preventing the further transmittal of out-of-date bundles. In this
scenario (in contrast to the previous example), since each camera
Parikh, et al. Expires July 9, 2009 [Page 5]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
would have a unique source EID, the tuple of source EID, destination
EID, and timestamp would be sufficient to identify obsolete bundles
in a node's bundle store; no additional cookie is needed.
Note that DTN nodes do not guarantee that bundles arrive at a node in
order of timestamp. Therefore, a node might discard the newly
arrived bundle if a more recent one is already present in the bundle
store. The search only applies to bundles that are currently in the
bundle store when the node acts in response to the SBEB. The node
does not track or consider the timestamps of bundles that have
already departed the node.
In some ways, the SBEB serves as a congestion control guidance
mechanism for DTN nodes. It provides applications a way to advise
which bundles a node can remove to help conserve storage, and in this
respect it supplements the bundle expiration time. However, the goal
of the SBEB is not to provide applications a way to reliably rid the
network of stale bundles. If storage and link resources are
plentiful, nodes may choose to ignore the SBEB; applications should
not depend on nodes to respond to the SBEB.
Parikh, et al. Expires July 9, 2009 [Page 6]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
3. Superseding Bundle Extension Block Format
The SBEB Block uses the Canonical Bundle Block Format as defined in
the Bundle Protocol [2], using the block layout without an EID
Reference List. That is, it is comprised of the following elements:
Block-type code (1 byte): Defined as in all bundle protocol blocks
except the primary bundle block (as described in the Bundle
Protocol). The block type code for the SBEB is 0x0A.
Block processing control flags (SDNV): Defined as in all bundle
protocol blocks except the primary bundle block. SDNV encoding is
described in the Bundle Protocol.
Bit 0 ("Block must be replicated in every fragment") SHOULD be
set.
Bit 2 ("Delete bundle if block can't be processed") MUST NOT be
set.
Bit 4 ("Discard block if it can't be processed") MUST NOT be
set.
Bit 6 ("Block contains an EID-reference field") MUST NOT be
set.
Block EID references count and EID references: This field MUST NOT
be present.
Block data length (SDNV): defined as in all bundle protocol blocks
except the primary bundle block. SDNV encoding is described in
the bundle protocol.
Block-type-specific data fields as follows:
Retention Count Field (SDNV): Indicates the number of newest (by
timestamp) matching bundles that a node MUST retain (if as many
bundles are indeed available). The value must be at least one for
a node to search and discard bundles in response to the SBEB;
thus, a value greater than zero serves to activate an SBEB. An
application uses a value of zero on bundles that might later be
subject to removal by a future bundle, but that do not themselves
trigger the removal of bundles; this allows the application
control over when to activate the discarding of older bundles. In
the first motivating example above, the server might use a zero
value when it wants all vehicle updates to reach the client,
unless the vehicle is later removed from the tracking database.
Parikh, et al. Expires July 9, 2009 [Page 7]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
Cookie Field: Contains optional data that must exactly match (in
addition to source and destination EID matching) the data in the
SBEB of a bundle being considered for removal. The cookie is
opaque data. Nodes only use it to match other bundles. Nodes do
not interpret the cookie. Cookies only have meaning to the
application.
The Structure of a Superseding Bundle Extension Block is as follows:
Superseding Bundle Extension Block:
+------+--------------+--------------+---------------+--------------+
|Type |Flags (SDNV) |Length (SDNV) |Retention Count (SDNV) |
+------+--------------+------------------------------+--------------+
|Cookie (optional) |
+-------------------------------------------------------------------+
Figure 1
Parikh, et al. Expires July 9, 2009 [Page 8]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
4. Superseding Bundle Block Processing
The following are the processing steps that a bundle node must take
relative to generation, reception, and processing of SBEB blocks.
4.1. Bundle Transmission
When an outbound bundle is created per the parameters of the bundle
transmission request, this bundle MAY (as influenced by local policy)
include one SBEB (as defined in this specification).
4.2. Bundle Forwarding
The node MUST NOT insert an SBEB into the bundle before forwarding
it. The node MUST NOT modify any part of the SBEB. The node MUST
NOT remove the SBEB before forwarding it.
4.3. Bundle Reception
If the bundle includes an SBEB, and if the receiving node chooses to
process it, the node MUST process it as follows. Upon receipt of a
bundle with an SBEB, the node searches for other bundles awaiting
forwarding that have an SBEB, and that have a matching source EID,
destination EID, and SBEB cookie (if present). Of those matching
bundles (including the arriving one), the node must retain the
retention count number of most recent bundles according to their
timestamp, and may discard the other matching bundles. The retention
count value in the SBEB of the most recent (i.e, the newest by
timestamp) bundle applies.
Parikh, et al. Expires July 9, 2009 [Page 9]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
5. Interactions with Bundle Protocol Features
If the SBEB would cause the deletion of a bundle with the custody
transfer requested flag set, then the node must accept custody before
deleting it.
When the SBEB results in a node deleting a bundle, the node may
generate a bundle deletion status report, as described in the Bundle
Protocol specification.
The Bundle Protocol permits nodes to fragment bundles. If a bundle
has an SBEB, the SBEB must be replicated in its fragments. A node
can discard fragments when executing the SBEB. However, a node MUST
never remove bundles (or bundle fragments) in favor of a newly
arrived bundle fragment, unless the node has all the fragments of a
replacing bundle.
An important implementation detail is that if a node replaces a
bundle that is in an outbound queue, the replacement bundle must
retain the position of the bundle being discarded. This prevents the
situation where replacing bundles are always sent to the tail of the
queue, causing a condition where bundles never depart from a node.
Parikh, et al. Expires July 9, 2009 [Page 10]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
6. Security Considerations
Because the SBEB is not included in the Mutable Canonicalization of
the bundle, its end-to-end integrity is not ensured by the use of the
mandatory Payload Integrity Block ciphersuite defined in the BSP.
Because the SBEB would be included in the Strict Canonicalization of
the bundle, its integrity would be ensured between one bundle
protocol agent and its adjacent bundle protocol agent, providing the
Bundle Authentication Block is used to protect the bundle during that
single DTN hop. The mandatory confidentiality ciphersuite currently
defined in the BSP does not provide for encryption of the SBEB.
Parikh, et al. Expires July 9, 2009 [Page 11]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
7. IANA Considerations
We may want to consider having IANA establish a register of Bundle
Protocol header types, with the Superseding Extension Block header
identified as type 0x0A.
Parikh, et al. Expires July 9, 2009 [Page 12]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
8. Acknowledgments
We recently learned of Michael Demmer's thesis [4], Chapter 5 of
which describes an "obsoletes identifier block" extension that is
functionally almost identical to the SBEB, and in fact, is more
general and designed for multicasting. It is further discussed in
[5]. The SBEB only works for single-source bundles.
Parikh, et al. Expires July 9, 2009 [Page 13]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
9. References
9.1. Normative References
[1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, October 1997.
[2] Scott, K. and S. Burleigh, "Bundle Protocol Specification",
RFC 5050, November 2007.
9.2. Informative References
[3] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R.,
Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network
Architecture", RFC 4838, April 2007.
[4] Demmer, M., "A Delay Tolerant Networking and System Architecture
for Developing Regions", University of California Berkeley,
Fall 2008.
[5] Demmer, M. and K. Fall, "The Design and Implementation of a
Session Layer for Delay-Tolerant Networks", Elsevier Computer
Communications (manuscript submitted December 2008).
Parikh, et al. Expires July 9, 2009 [Page 14]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
Authors' Addresses
S. Parikh
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-3560
Email: sparikh@mitre.org
URI: http://mitre.org/
S. Symington
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-7209
Email: susan@mitre.org
URI: http://mitre.org/
K. Scott
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-6547
Email: kscott@mitre.org
URI: http://mitre.org/
R. Durst
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-7535
Email: durst@mitre.org
URI: http://mitre.org/
Parikh, et al. Expires July 9, 2009 [Page 15]
Internet-Draft DTN Superseding Bundle Extension Block January 2009
R. Edell
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-4886
Email: redell@mitre.org
URI: http://mitre.org/
Parikh, et al. Expires July 9, 2009 [Page 16]