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]