Delay Tolerant Networking Research Group K. Scott Internet Draft The MITRE Corporation <draft-irtf-dtnrg-bundle-spec-00.txt> S. Burleigh March 2003 Jet Propulsion Laboratory Expires: September 2003 Bundle Protocol Specification Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes the end-to-end protocol, header formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). Conventions used in this document 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]. K. Scott and S. Burleigh Expires - September 2003 [Page 1]
Internet Draft Bundle Protocol Specification March 2003 Table of Contents 1. Introduction.........................................2 2. Service Description..................................4 2.1 Definitions..........................................4 2.2 Services at the User Interface.......................4 2.3 Summary of Primitives................................4 2.4 Summary of Parameters................................5 2.5 Bundling Service Primitives..........................6 3. Bundle Message Format...............................11 3.1 General Bundle Header Format........................15 3.2 Tuples..............................................15 3.3 Primary and Variable-Length Immutable Portion Headers16 3.4 Current Custodian Header............................19 3.5 Bundle Status Report Header.........................20 3.6 Bundle Payload Header...............................21 3.7 Subsequent Bundle Payload Header....................21 3.8 Authentication Header...............................22 3.9 16-bit Extended Offset Header.......................23 3.10 Rules Governing the Appearance and Order of Headers.23 4. Bundle Processing...................................24 4.1 Bundles received from applications via the API......24 4.2 Bundles received from other bundle agents...........24 4.3 Bundle Fragmentation and Reassembly.................27 Security Considerations.........................................28 Informative References..........................................28 Acknowledgements................................................29 Author's Addresses..............................................29 1. Introduction Delay Tolerant Networking (DTN) is an end-to-end architecture providing communications in and/or through highly stressed environments. Stressed networking environments include those with intermittent connectivity, large and/or variable delays, and high bit error rates. To provide its services, the DTN protocols, also known as bundle protocols, sit at the application layer of the constituent internets, forming a store-and-forward overlay network. Key capabilities of the bundling protocols include: o Custody-based reliability o Ability to cope with intermittent connectivity o Ability to take advantage of scheduled and opportunistic connectivity (in addition to 'always-up' connectivity) o Late binding of names to addresses K. Scott and S. Burleigh Expires - August 2003 [Page 2]
Internet Draft Bundle Protocol Specification March 2003 For descriptions of these capabilities and rationale for the DTN architecture, see [2]. [3] contains a tutorial-level overview of DTN concepts. The bundle protocols sit at the application layer of the constituent internets as shown in Figure 1. Bundling uses the 'native' internet protocols for communications within a given internet. Note that 'internet' in the preceding is used in a general sense and does not necessarily refer to TCP/IP. The interface between the common bundle protocol and a specific internetwork protocol suite is known as a convergence layer. Figure 1 shows three distinct transport and network protocols (denoted T1/N1, T2,N2, and T3/N3). +-----------+ +-----------+ | BundleApp | | BundleApp | +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ | Bundle v | | ^ Bundle v | | ^ Bundle v | | ^ Bundle | +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | +-----------+ +------------+ +-------------+ +-----------+ | | | | |<-- An Internet --->| |<--- An Internet --->| | | | | Figure 1: The bundling protocol sits at the application layer of the Internet model. This document describes the format of the messages (called bundles) passed between entities participating in bundle communications. The entities are referred to as bundle nodes or bundle agents. This document does not address: o The mechanisms bundle agents use to transport data through a specific Internet, called convergence layers, or the bundle agent to convergence layer API. o The bundle routing algorithm or mechanisms for populating the routing or forwarding information bases of bundle nodes. K. Scott and S. Burleigh Expires - August 2003 [Page 3]
Internet Draft Bundle Protocol Specification March 2003 2. Service Description 2.1 Definitions Communications Endpoint ID û A Communications Endpoint ID or 'Communications endpoint' corresponds to a 'tuple' in [2]. A communications endpoint is identified by a DTN region identifier and an administrative part that is opaque to the bundle system outside the destination region. Passive bundle reception û A bundle application is said to be in a period of passive bundle reception if it expects the bundle agent to asynchronously notify it of new bundles. This assumes that the application has registered a Communications Endpoint ID and a callback mechanism with a bundle agent. Send token binding, registration token binding û A token passed from a bundle application to the bundle agent when sending a bundle / registering to receive bundles. This token is used to associate an opaque token returned by the bundle agent with a specific bundle / registration. 2.2 Services at the User Interface 2.2.1 The bundling protocol SHALL provide the following services to bundling applications: a) sending a bundle to an identified communications endpoint; b) canceling a previously submitted request to send a bundle c) beginning a period of passive bundle reception; d) ending a period of passive bundle reception; e) actively requesting delivery of a bundle. 2.3 Summary of Primitives 2.3.1 The bundling service SHALL consume the following request primitives: a) Send.request; b) Cancel.request c) Register.request; d) Deregister.request; e) Poll.request; K. Scott and S. Burleigh Expires - August 2003 [Page 4]
Internet Draft Bundle Protocol Specification March 2003 2.3.2 The Bundling service SHALL deliver the following indication primitives: a) Bundle.indication; b) SendError.indication c) SendToken.indication d) RegistrationToken.indication 2.4 Summary of Parameters NOTE û The availability and use of parameters for each primitive are indicated in section 2.5, where optional parameters are identified with square brackets [thus]. The following definitions apply. 2.4.1 Destination Communications endpoint ID The destination communications endpoint ID parameter identifies the communications endpoint to which the bundle is to be sent. One can think of a DTN communications endpoint as an application, but in general the definition is meant to be broader. For example, elements of a sensor network might register with a local bundle agent to receive information about certain topics of interest. A communications endpoint could thus refer to a process running on a general-purpose processor, a special-purpose hardware device, an object in an object-oriented operating system, etc. 2.4.2 Source Communications endpoint ID The source communications endpoint ID parameter shall uniquely identify the communications endpoint from which the bundle was sent. 2.4.3 Reply Communications endpoint ID The reply communications endpoint ID parameter shall identify the communications endpoint to which any bundle status reports pertaining to the bundle, including end-to-end acknowledgments, should be sent. 2.4.4 Class of Service Parameter The class of service parameter shall indicate which class of standard procedures shall be followed when transmitting and delivering the bundle. Its value shall be one of the following: o Bulk o Normal o Expedited K. Scott and S. Burleigh Expires - August 2003 [Page 5]
Internet Draft Bundle Protocol Specification March 2003 2.4.5 Delivery Options Parameter The delivery options parameter shall indicate what optional procedures shall additionally be followed when transmitting and delivering the bundle. Its value shall be a combination of zero or more of the following: o Custody transfer o Return receipt o Delivery record received o Delivery record custody taken o Security requirements - Confidentiality - Integrity - Authentication 2.4.6 Lifespan parameter The lifespan parameter shall indicate the length of time, following initial transmission of a bundle, after which bundling agents shall no longer store or forward the bundle. The sum of the bundle's transmission time and lifespan is its delivery deadline, the moment at which it will be deleted from the DTN network if it has not already been delivered to its destination communications endpoint. 2.4.7 Application Data Unit Parameter The application data unit parameter shall indicate the location (in memory or non-volatile storage, a local implementation matter) of the application data conveyed by the bundle. 2.4.8 Delivery Failure Action Parameter The delivery failure action parameter shall indicate what action is to be taken when a bundle arrives for delivery at a moment when its destination communications endpoint is not currently in a period of passive bundle reception. Its value shall be one of the following: o Defer delivery until the entity either actively requests delivery of the bundle or else begins a period of passive bundle reception. o Abort delivery of the bundle. o Execute a specified procedure, where the expression of the procedure to be executed is a matter of local implementation. 2.5 Bundling Service Primitives K. Scott and S. Burleigh Expires - August 2003 [Page 6]
Internet Draft Bundle Protocol Specification March 2003 2.5.1 SEND.REQUEST The Send.request primitive shall be used by the application to request transmission of an application data unit from the source communications endpoint to a destination communications endpoint. Semantics: Send.request shall provide parameters as follows: Send.request( source communications endpoint ID, destination communications endpoint ID, reply communications endpoint ID, class of service, delivery options, lifespan, send token binding, application data unit) When Generated: Send.request is generated by the source Bundling application at any time. Effect on Receipt: Receipt of Send.request shall cause the Bundling agent to initiate bundle transmission procedures. In addition, the agent will generate a SendToken.indication for the application. The SendToken.indication returns to the application the send token binding and a token that the application can later use to refer to this bundle. Additional Comments: None. 2.5.2 CANCELBUNDLE.REQUEST The CancelBundle.request primitive shall be used by the application to request that a bundle previously sent via a Send.request be cancelled. Semantics: CancelBundle.request shall provide parameters as follows: Cancel.request ( send token ) When Generated: CancelBundle.request MAY be generated by the application after sending a bundle via the Send.request and after receiving a reference token for the bundle via a SendToken.indication. A CancelBundle.request should be sent if the application no longer wished to send the bundle referenced by the send token. Effect on Receipt: Receipt of CancelBundle.request shall cause the Bundling agent to cease attempts to transmit the given bundle. If the bundle agent is the current custodian, then retransmission resources, including any retransmission timers, associated with the bundle will be released. K. Scott and S. Burleigh Expires - August 2003 [Page 7]
Internet Draft Bundle Protocol Specification March 2003 Additional Comments: None. 2.5.3 REGISTER.REQUEST The Register.request primitive shall be used to notify the Bundling agent of the start of a period of passive bundle reception. Semantics: Register.request shall provide parameters as follows: Register.request( delivery failure action, registration token binding, destination communications endpoint ID) When Generated: Register.request is generated by any Bundling application at any time when not currently in a period of passive bundle reception. Effect on Receipt: Receipt of Register.request shall cause the Bundling agent to deliver to the Bundling application any bundles destined for the application that (a) arrived in the past and were deferred or (b) arrive during the new period of passive bundle reception. Receipt of Register.request will also cause the agent to deliver a RegisterToken.indication to the application. The RegisterToken.indication contains a token that the application can use to refer to this registration. Additional Comments: There are currently no provisions for multipoint delivery of bundles. Bundle agents MAY prohibit multiple applications from registering for passive bundle reception with the same destination communications endpoint ID. The behavior of the bundle agent when multiple applications register with the same communications endpoint ID is undefined. The registration token binding is currently unused but included in anticipation of being useful for multipoint delivery. 2.5.4 DEREGISTER.REQUEST The Deregister.request primitive shall be used to notify the Bundling agent of the end of a period of passive bundle reception. Semantics: Deregister.request shall provide parameters as follows: Deregister.request(destination communications endpoint id) When Generated: Deregister.request is generated by any Bundling application at any time when the application is currently in a period of passive bundle reception. K. Scott and S. Burleigh Expires - August 2003 [Page 8]
Internet Draft Bundle Protocol Specification March 2003 Effect on Receipt: Receipt of Deregister.request shall cause the Bundling agent to dispatch any subsequently arriving bundles destined for the application in accord with the delivery failure action specified by the most recent Register.request primitive issued by this application. Additional Comments: None. 2.5.5 POLL.REQUEST The Poll.request primitive shall be used to request immediate delivery of a bundle. Semantics: Poll.request shall provide parameters as follows: Poll.request(destination communications endpoint id) When Generated: Poll.request is generated by any Bundling application at any time when not currently in a period of passive bundle reception. Effect on Receipt: Receipt of Poll.request shall cause the Bundling Agent to deliver to the Bundling application the least recently received bundle, destined for the communications endpoint ID, for which delivery was deferred. Additional Comments: There are currently no provisions for multipoint bundle delivery. If multiple distinct applications poll for delivery of bundles using the same communications endpoint ID, each application may receive some subset of the bundles that the agent has received destined for that ID. 2.5.6 BUNDLE.INDICATION The Bundle.indication primitive shall be used to deliver the content of a bundle to the bundle's destination communications endpoint. Semantics: Bundle.indication shall provide parameters as follows: Bundle.indication ( source communications endpoint ID, destination communications endpoint ID, reply communications endpoint ID, class of service, delivery options, lifespan, application data unit) When Generated: Bundle.indication shall be generated on receipt of a Poll.request primitive from a Bundling application or on arrival of a bundle destined for the application at a time when the application is in a period of passive bundle reception. K. Scott and S. Burleigh Expires - August 2003 [Page 9]
Internet Draft Bundle Protocol Specification March 2003 Effect on Receipt: The effect on receipt of Bundle.indication by a Bundling application is undefined. Additional Comments: None. 2.5.7 SENDERROR.INDICATION The SendError.indication primitive shall be used to deliver information about bundles that the agent cannot accept from the application. Semantics: SendError.indication shall provide parameters as follows: SendError.indication ( source communications endpoint ID, destination communications endpoint ID, reply communications endpoint ID, class of service, delivery options, lifespan, application data unit) When Generated: SendError.indication shall be generated when a bundle sent by an application cannot be accepted by the agent. Effect on Receipt: The effect on receipt of SendError.indication by a Bundling application is undefined. Additional Comments: None. 2.5.8 SENDTOKEN.INDICATION The SendToken.indication primitive shall be used to deliver a token to the application that it can use to refer to a particular bundle sent via s Send.request primitive. Semantics: SendToken.indication shall provide parameters as follows: SendToken.indication ( send token binding, send token) When Generated: SendToken.indication shall be generated when a bundle is accepted by the agent for transmission. The send token binding parameter is the same as that supplied with the Send.indication, and the send token can be supplied to refer to the particular bundle. Effect on Receipt: The effect on receipt of SendToken.indication by a Bundling application is undefined. Additional Comments: None. K. Scott and S. Burleigh Expires - August 2003 [Page 10]
Internet Draft Bundle Protocol Specification March 2003 2.5.9 REGISTRATIONTOKEN.INDICATION The RegistrationToken.indication primitive shall be used to deliver a token to the application that it can use to refer to a particular registration invoked with the Register.request primitive. Semantics: RegistrationToken.indication shall provide parameters as follows: RegistrationToken.indication ( registration token binding, registration token) When Generated: RegistrationToken.indication shall be generated when a registration.request primitive is serviced by the agent. Effect on Receipt: The effect on receipt of RegistrationToken.indication by a Bundling application is undefined. Additional Comments: The Registration.indication is currently unused. It is expected that it will be useful when multipoint delivery is implemented. 3. Bundle Message Format The DTN protocols use a chained header format reminiscent of IPv6 headers. Each bundle header consists of at least a primary bundle header and a variable-length Immutable Portion (VLIP) header. Other header types can be chained after the VLIP to support additional functionality such as authentication, bundle segmentation, etc. This section describes the format of the different bundle headers. Rules for processing bundle headers appear in section 4 of this document. The currently defined headers are: Table 1: Bundle Header Types +--------------------+------+---------------------------------------+ | Header | Type | Comment | +====================+======+=======================================+ | | 0x00 | Reserved | +--------------------+------+---------------------------------------+ | Primary bundle | 0x01 | Must appear before any other bundle | | header | | header. | +--------------------+------+---------------------------------------+ | Variable Length | 0x02 | (VLIP) contains source, destination, | | Immutable Portion | | and reply-to tuples. | +--------------------+------+---------------------------------------+ K. Scott and S. Burleigh Expires - August 2003 [Page 11]
Internet Draft Bundle Protocol Specification March 2003 | Current Custodian | 0x03 | Indicates current bundle custodian. | | | | Present only if the custody transfer | | | | service is requested. | +--------------------+------+---------------------------------------+ | Bundle Status | 0x04 | Used to report bundle receipt, | | Report | | forwarding, and custody actions. | +--------------------+------+---------------------------------------+ | Bundle Payload | 0x05 | Identifies actual bundle content. | +--------------------+------+---------------------------------------+ | Subsequent Bundle | 0x06 | Used when more than one bundle is | | Payload Header | | transmitted under a single primary | | | | header. | +--------------------+------+---------------------------------------+ | Authentication | 0x07 | Content depends on the type of | | | | authentication used. | +--------------------+------+---------------------------------------+ | 16-bit Extended | 0x08 | Provides extended reference | | Offset | | capabilities when the combination of | | | | source, dest, and reply-to tuples in | | | | the VLIP precludes their reference | | | | by -byte offsets. | +--------------------+------+---------------------------------------+ | Bundle Fragment | 0x09 | This bundle is a fragment of a | | | | larger one. +--------------------+------+---------------------------------------+ | All other values reserved for future use. | +--------------------+------+---------------------------------------+ The format of the various headers is shown in Figure 2 below. Primary Bundle Header +----------------+----------------+----------------+----------------+ | Version | Next Header | Destination | Source | +----------------+----------------+----------------+----------------+ | Reply-To | Cur. Custodian | COS Flags | Authentication | +----------------+----------------+----------------+----------------+ | | + Creation Timestemp (8 bytes) + | | +---------------------------------+---------------------------------+ | Expiration Time | +----------------+----------------+---------------------------------+ K. Scott and S. Burleigh Expires - August 2003 [Page 12]
Internet Draft Bundle Protocol Specification March 2003 Variable Length Immutable Portion Header +----------------+----------------+----------------+----------------+ | Next Header | Total Length | Destination Tuple (variable) | +----------------+----------------+ | / / / / +----------------+----------------+----------------+----------------+ | Source Tuple (variable) | / / / / +----------------+----------------+----------------+----------------+ | Reply-To Tuple (variable) | / / / / +----------------+----------------+----------------+----------------+ Current Custodian Header +----------------+----------------+----------------+----------------+ | Next Header | Current custodian tuple (variable) | +----------------+----------------+----------------+----------------+ Bundle Status Report Header for bundle 'X' +----------------+----------------+----------------+----------------+ | Next Header | Length | Status Flags | Fragment +----------------+----------------+----------------+----------------+ offset (4 bytes, if present) | Fragment +--------------------------------------------------+----------------+ length (4 bytes, if present) | Copy of | +--------------------------------------------------+ | | X's Creation Timestamp (8 bytes) | + +----------------+ | | Time of +----------------+----------------+----------------+ | | Receipt of Bundle 'X' (8 Bytes, if present) + +----------------+ | | Time of | +----------------+----------------+----------------+ | | Forwarding of Bundle 'X' (8 bytes, if present) | + +----------------- | | Copy of X's | +--------------------------------------------------+ | | Source Tuple (variable) | +-------------------------------------------------------------------+ K. Scott and S. Burleigh Expires - August 2003 [Page 13]
Internet Draft Bundle Protocol Specification March 2003 Bundle Payload Header +----------------+----------------+----------------+----------------+ | Next Header | Length of bundle payload (4 bytes) +----------------+----------------+----------------+----------------+ | | +----------------+ | | Bundle Payload (variable) | | | / / / / | | +-------------------------------------------------------------------+ Bundle Fragment Header +----------------+----------------+----------------+----------------+ | Next Header | Length of original bundle payload (4 bytes) +----------------+----------------+----------------+----------------+ | Offset of this bundle fragment (4 bytes) +----------------+--------------------------------------------------+ | -----------------+ Subsequent Bundle Payload Header +----------------+----------------+----------------+----------------+ | Next Header | Length of subsequent bundle payload (4 bytes) +----------------+----------------+----------------+----------------+ | Creation Timestamp (8 bytes) | +----------------+ | | | + +--------------------------------------------------+ | | | +----------------+ | | Bundle Payload (variable) + + | / / / / | | +-------------------------------------------------------------------+ K. Scott and S. Burleigh Expires - August 2003 [Page 14]
Internet Draft Bundle Protocol Specification March 2003 16-bit Extended Offset Header +----------------+----------------+----------------+----------------+ | Next Header | Destination | Source +----------------+----------------+----------------+----------------+ | Reply-To | Cur. Custodian +----------------+----------------+----------------+----------------+ | +----------------+ Authentication +----------------+----------------+----------------+----------------+ | Next Header | Length | Auth. information (variable) +----------------+----------------+----------------+----------------+ Figure 2: Bundle header formats. 3.1 General Bundle Header Format In most cases a bundle header begins with a one-octet next header type field. This field identifies the type of the header following the one the field is part of. The exception to this rule is the primary bundle header, which must appear before any other bundle sub- headers. The primary bundle header begins with a 1-byte version field that identifies the version of the bundling protocols used to create the current bundle, followed by a 1-byte next header type field. All multi-byte fields are transmitted in network byte order. Note that the class of service in the primary bundle header is not a single two-byte field but instead the functional concatenation of two one-byte fields. 3.2 Tuples Communicating entities in the DTN are referred to via name tuples. A name tuple contains a routing part that identifies the entity's DTN region, and an administrative part that identifies the entity within that region. The routing part of a DTN name tuple must be globally parsable throughout the DTN. The administrative part is opaque outside of the destination region, but must be parsable anywhere in the destination region. Note that the administrative part of a DTN name tuple may include information about a specific machine as well as a specific application or process on that machine. The representation of a tuple contains a 1-byte length subfield indicating the total length of the tuple, including the length subfield, followed by the routing and administrative parts of the K. Scott and S. Burleigh Expires - August 2003 [Page 15]
Internet Draft Bundle Protocol Specification March 2003 tuple. Note that in Figure 1 above, the length fields of tuples are explicitly shown. 3.3 Primary and Variable-Length Immutable Portion Headers The primary bundle header together with the variable length Immutable Portion header contains the basic information needed to route bundles to their destinations. The main goal in separating the primary bundle header from the variable length Immutable Portion header is to make processing simpler. Section 3.3.1 describes the fields of the primary bundle header, and section 3.3.2 the fields of the variable-length Immutable Portion header. The processing rules for the primary and variable-length Immutable Portion headers are described in sections 4.2 (Bundle Routing) and 4.3 (Current Custodian Header Fields). 3.3.1 Primary Bundle Header The field of the primary bundle header are: Version. A 1-byte field indicating the version of the bundling protocol that generated this header. Next Header Type. The Next Header Type field is a 1-byte field that indicates the type of the header that immediately follows this one. Header types are listed in Table 1 above. Destination Tuple Offset. This 1-byte field contains the offset of the beginning of the destination name tuple, in bytes, from the beginning of the primary bundle header. The format of a tuple is described in section 3.3.2.1. Source Tuple Offset. A 1-byte field containing the offset of the beginning of the source name tuple, in bytes, from the beginning of the primary bundle header. If the source and destination tuples are the same, then the source tuple offset may equal the destination tuple offset. In this case the length of the source tuple in the VLIP header (described below) will be 1 (i.e. the length will include only the 1-byte length field). Reply-To Tuple Offset. A 1-byte field containing the offset of the beginning of the reply-to name tuple, in bytes, from the beginning of the primary bundle header. Note that if the reply-to tuple is the same as the source tuple (that is, the source wants replies sent to it), then the reply-to offset may be the same as the source offset. In this case the length of the reply-to tuple in the VLIP header (described below) will K. Scott and S. Burleigh Expires - August 2003 [Page 16]
Internet Draft Bundle Protocol Specification March 2003 be 1 (i.e. the length will include only the 1-byte length and no tuple). Current custodian Tuple Offset. A 1-byte field containing the offset of the beginning of the current custodian name tuple, in bytes, from the beginning of the primary bundle header. Bundles requiring custodial delivery must contain a current custodian header, and the current custodian tuple offset points to the current custodian tuple in that header, even if the current custodian is the source. Class of Service. The class of service is the concatenation of two 1- byte fields that contains a number of class-of-service related parameters and flags. The COS consists of a 1-bit custody switch followed by four (4) bits of priority, three (3) bits of delivery record request flags, and an 8-bit 'authentication present & type' field. If the custody bit is 1 then the sender requests custodial transfer of the bundle. The four- bit priority field indicates the bundle's priority, with higher values being of higher priority. The priorities are strict in that all bundles with higher priorities should be transmitted before any bundles of lower priorities. The interpretation of the delivery record request flags is as follows. Table 2: Delivery Record Request Flag Meanings +---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 000 | No delivery records requested. | +---------+--------------------------------------------+ | 001 | Request custody transfer reporting | +---------+--------------------------------------------+ | 010 | Request reporting of bundle reception. | +---------+--------------------------------------------+ | 100 | Request end-to-end return receipt. | +---------+--------------------------------------------+ The Authentication Present (&Type) field indicates whether or not bundle authentication is present and, if so, the authentication type. The values for this field are: K. Scott and S. Burleigh Expires - August 2003 [Page 17]
Internet Draft Bundle Protocol Specification March 2003 Table 3: Authentication Values in the Primary Bundle Header +---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 0x00 | No bundle authentication present. | +---------+--------------------------------------------+ | 0x01 | Authentication with DSA. | +---------+--------------------------------------------+ | 0x02 | Authentication with DES-MAC | +---------+--------------------------------------------+ | 0x03 | Authentication with other | +---------+--------------------------------------------+ | All | Reserved. | | Others | | +---------+--------------------------------------------+ Creation Timestamp. The creation timestamp is an 8-byte field containing the time the bundle was first accepted for transmission by the source bundle agent, formatted as an NTP timestamp. Expiration Time. The four-byte expiration time field indicates the time at which the bundle's data will no longer be useful, encoded as the number of seconds past the creation timestamp. When the current time is greater than the creation timestamp plus the expiration time, bundles may be discarded. The reason that the creation timestamp has higher granularity than the expiration time is because the creation timestamp together with the source tuple make up the bundle identifier, which must be unique to every bundle in the system. 3.3.2 Variable Length Immutable Portion (VLIP) Header The variable length Immutable Portion header follows the primary bundle header if all of the source, destination, reply-to, and current custodian offsets can be accommodated by the primary bundle header's one-byte offset fields. If any of the offsets cannot be accommodated by the primary bundle header's 1-byte offset fields, then a 16-bit Extended Offset Header will separate the primary bundle header from the VLIP. If the 16-bit Extended Offset Header is present, the source, destination, reply-to, and current custodian offsets in the primary bundle header must all be zero. The fields of the variable length immutable portion header are: K. Scott and S. Burleigh Expires - August 2003 [Page 18]
Internet Draft Bundle Protocol Specification March 2003 Next Header Type. The Next Header Type field is a 1-byte field that indicates the type of the header that immediately follows this one. Header types are listed in Table 1 above. Total Length. A 1-byte field indicating the total length, in bytes, of the Variable Length Immutable Portion header, including the next header type field. If the sum of the dest, source, and reply-to tuples is too long for the total length field of the variable-length Immutable Portion header then the tuples are split into multiple VLIPHes. In this case a 16-bit extended offset header will be required after the primary bundle header to convey the offsets of the various tuples. Destination Tuple. The destination tuple indicates the intended recipient(s) of the bundle. The format of a tuple is described in section 3.3.2.1. Source Tuple. The source tuple indicates the sender of the bundle. The format of a tuple is described in section 3.3.2.1. Reply-To Tuple. The reply-to tuple identifies the communicating entity that is to receive bundle status reports associated with the current bundle. Messages that are sent to the reply- to tuple include any bundle status reports requested in this bundle's class of service field and any end-to-end error messages associated with the bundle. The format of a tuple is described in section 3.3.2.1. The combination of the source tuple and the creation timestamp constitute the bundle identifier, or bundleID. BundleIDs are used by the network to differentiate bundles, and must therefore be unique throughout a DTN. Thus a source may not send two bundles with the same creation timestamp. 3.4 Current Custodian Header Custody transfer provides a means of reliable bundle transfer. The rationale behind custody transfers is discussed in detail in [2]. The rules for processing custodial bundles are described in section 4.5 below. The fields of the current custodian header are: Next Header Type. The Next Header Type field is a 1-byte field that indicates the type of the header that immediately follows this one. Header types are listed in Table 1 above. Current Custodian Tuple. The DTN name tuple of the bundle agent that is the current custodian of the bundle. K. Scott and S. Burleigh Expires - August 2003 [Page 19]
Internet Draft Bundle Protocol Specification March 2003 3.5 Bundle Status Report Header This section describes the fields in a bundle status report header. Rules for processing delivery record requests are described in section 4.3. The fields in a bundle status report header are: Next Header Type. The Next Header Type field is a 1-byte field that indicates the type of the header that immediately follows this one. Header types are listed in Table 1 above. Length. A 1-byte field indicating the total length, in bytes, of the Bundle Status Report Header, including the next header type field. Status Flags. A 1-byte field containing the following flags: Table 4: Status Flags for Bundle Status Report Headers +---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 0x01 | Reporting node correctly received bundle. | +---------+--------------------------------------------+ | 0x02 | Reporting node took custody of bundle. | +---------+--------------------------------------------+ | 0x04 | Reporting node has forwarded the bundle. | +---------+--------------------------------------------+ | 0x08 | Reserved for future use. +---------+--------------------------------------------+ | 0x10 | Time of receipt (TOR) field present. | +---------+--------------------------------------------+ | 0x20 | Time of forward (TOR) field present. | +---------+--------------------------------------------+ | 0x40 | Report is for a bundle fragment; fragment | | | offset and length fields are present. | +---------+--------------------------------------------+ | 0x80 | Reserved for future use. | +---------+--------------------------------------------+ Send Timestamp For Reported Bundle. A copy of the send timestamp of the bundle that caused the status report to be generated. Time of Receipt (if present). If the TOR present bit is set in the status flags, then a timestamp indicating the time at which K. Scott and S. Burleigh Expires - August 2003 [Page 20]
Internet Draft Bundle Protocol Specification March 2003 the bundle was received by the reporting node is included here. The timestamp is 8 bytes long, formatted as an NTP timestamp. Time of Forward (if present). If the TOF present bit is set in the status flags, then a timestamp indicating the time at which the bundle was first forwarded by the reporting node is included here. The timestamp is 8 bytes long, formatted as an NTP timestamp. Reported Bundle's Source Tuple. The source tuple of the bundle that caused the status report to be generated. The combination of the reported bundle's send timestamp and source tuple constitute the bundle identifier. This uniquely identifies the bundle to the reportee. Discussion of delivery record requests and bundle status reports appears in section 4.3 below. 3.6 Bundle Payload Header The fields of the bundle payload header are: Next Header Type. The Next Header Type field is a 1-byte field that indicates the type of the header that immediately follows this one. Header types are listed in Table 1 above. Length. A 4-byte field indicating the total length, in bytes, of the Bundle Payload (data-carrying portion of the bundle). This length does NOT include the lengths of the header elements of this bundle payload header. Payload. The bundle payload. This is the application data. 3.7 Subsequent Bundle Payload Header It may be desirable to combine several payloads to the same destination, provided that the information in their primary, variable-length immutable portion, current custodian, and authentication headers are compatible. The subsequent bundle payload header provides a mechanism to include additional bundle payloads after the primary payload. To be compatible, the following must be true of all bundles combined under a single primary bundle header: o They all have the same version, source, destination, reply-to (if any), and current custodian (if any). o Their 'custody required' bits must be the same. K. Scott and S. Burleigh Expires - August 2003 [Page 21]
Internet Draft Bundle Protocol Specification March 2003 o Their priorities must be the same. o Compatibility of various authentication methods is currently undefined. Bundles that are not using authentication (i.e. the "Authentication Present & Type" field in their primary bundle headers are all 0x00) are compatible. o The difference between the maximum and minimum expiration times (in absolute seconds) must be less than a TBD value. If multiple compatible bundles are combined under a single primary bundle header, a single expiration time must be chosen to cover them all. In this case, the expiration time in the primary bundle header is set to the maximum of the expiration times of the constituent bundle payloads. Note that because the expiration time is expressed as a delta from the send timestamp, the various expiration times must be added to the 'seconds' portions of their send timestamps. This yields a list of bundle expiration times in absolute seconds. 3.7.1 The fields of the Subsequent bundle payload header are: Next Header Type. The Next Header Type field is a 1-byte field that indicates the type of the header that immediately follows this one. Header types are listed in Table 1 above. Length. A 4-byte field indicating the total length, in bytes, of the Bundle Payload (data-carrying portion of the bundle). This length does NOT include the lengths of the header elements of this bundle payload header. Creation Timestamp. The creation timestamp of this payload, an 8- byte object formatted as an NTP timestamp. This is necessary because the combination of the creation timestamp and the source tuple uniquely identify a bundle. Payload. The bundle payload. This is the user data. 3.8 Authentication Header The fields of the authentication header are: Next Header Type. The Next Header Type field is a 1-byte field that indicates the type of the header that immediately follows this one. Header types are listed in Table 1 above. Length. The length of the authentication header depends on the algorithm used, but can be determined from the algorithm type. Authentication. Authentication is achieved by the source generating a hash over the immutable portion header and the immutable payload then running the hash through a signature algorithm û K. Scott and S. Burleigh Expires - August 2003 [Page 22]
Internet Draft Bundle Protocol Specification March 2003 e.g., sign using sender's private key. Authentication when the bundle agent is physically separated from the bundle applications using it is an open question 3.9 16-bit Extended Offset Header The 16-bit extended offset header immediately follows the primary bundle header whenever any of the destination, source, or reply-to tuple offsets are greater than the 1-byte offset fields in the primary bundle header allow (i.e. 255). Recall that the tuple offsets are defined as the indices of the starts of the various tuples relative to the beginning of the primary bundle header. The fields of the 16-bit Extended Offset Header are: Next Header Type. The Next Header Type field is a 1-byte field that indicates the type of the header that immediately follows this one. Header types are listed in Table 1 above. Destination Tuple Offset. The byte offset of the beginning of the destination name tuple, in bytes, from the beginning of the primary bundle header. The format of a tuple is described in section 3.3.2.1. This is a 16-bit field. Source Tuple Offset. The byte offset of the beginning of the source name tuple, in bytes, from the beginning of the primary bundle header. This is a 16-bit field. Reply-To Tuple Offset. The byte offset of the beginning of the reply-to name tuple, in bytes, from the beginning of the primary bundle header. This is a 16-bit field. Note that if the reply-to tuple is the same as the source tuple (that is, the source wants replies sent to it), then the reply-to offset may be the same as the source offset. In this case the length of the reply-to tuple in the variable-length Immutable Portion header (described 3.3.2.1) will be 1 (i.e. the length will include only the 1-byte length and no tuple). 3.10 Rules Governing the Appearance and Order of Headers The following rules apply to the order and presence of DTN headers: o The primary bundle header must appear first, followed by either the 16-bit extended offset header (if present) or the variable length Immutable Portion header. o The only headers allowed after a bundle payload header are subsequent bundle payload headers and (possibly) their associated authentication headers. In cases where a subsequent bundle payload requires authorization, the payload's authorization header will immediately precede the payload. A K. Scott and S. Burleigh Expires - August 2003 [Page 23]
Internet Draft Bundle Protocol Specification March 2003 bundle payload header must appear before any subsequent bundle payload headers. o Rules regarding the order of appearance of other header types have not yet been established, though we expect to formulate such rules soon. 4. Bundle Processing There are currently no provisions for multipoint delivery of bundles. 4.1 Bundles received from applications via the API Step 1: Permissions checking. Bundle agents MAY enforce policy that restricts the permissions of applications. Such policy could, for example, limit the rate at which particular applications are allowed to inject traffic, or limit the CoS options that particular applications are allowed to use. Bundles that do not meet the policy criteria MAY be silently dropped by the bundle agent, though some indication SHOULD be provided to the application via the API. Step 2: If the bundle is accepted for transmission, then processing proceeds from Step 3 of section 4.2. 4.2 Bundles received from other bundle agents The steps in processing bundles received from other bundle agents are: Step 1: Bundle Authentication: The bundle must first be authenticated as described in section 3.13 of [2]. The purpose of this authentication is to protect the bundle transmission infrastructure, not to provide security services to the bundle per se. If the authentication fails then the bundle is silently discarded. Step 2: Generate a bundle status report, if requested. If the bundle class of service requests that a bundle status report be generated when the bundle is received, a bundle status report SHOULD be generated. For bundles requesting only bundle receipt notification, the bundle status report can be immediately queued for transmission to the bundle's reply-to address. If the bundle requests custody transfer reporting, a single bundle status report MAY be generated after the agent decides whether or not to take custody of the bundle. K. Scott and S. Burleigh Expires - August 2003 [Page 24]
Internet Draft Bundle Protocol Specification March 2003 Step 3: Local bundle delivery processing. The steps described here are carried out ONLY if the bundle's destination tuple matches one of the bundle agent's interfaces. Step 3a: Reassembly. If the received bundle contains a fragmentation header, it MUST be combined with the rest of the fragments that make up the entire original bundle before the content can be further processed. Step 3b: Processing custody acknowledgements. A custody acknowledgement is a bundle status report directed to the current agent indicating that a downstream agent has taken custody of the bundle. Custody acknowledgements may be for entire bundles or for fragments of bundles. This bundle agent must examine the bundle status report and the saved state associated with the bundle to determine how much of the bundle is acknowledged by the report. If the report covers only a portion of a bundle, the bundle agent SHOULD mark that piece of the bundle as being acknowledged. The bundle agent SHOULD maintain the retransmission timer for any pieces of the bundle NOT covered by the status report. When status reports have been received taking custody of the entire bundle, the bundle agent SHOULD stop any retransmission timers and free all retransmission resources associated with the bundle. Step 3c: If an application has registered with the bundle agent with the bundle's destination communication endpoint ID and is in a period of passive bundle reception, the bundle SHALL be delivered to the application. Step 3d: If the bundle class of service requests that and end-to-end return receipt be sent, such a receipt SHOULD be generated once the bundle has been delivered to the application. Note that this return receipt only states that the bundle has been delivered to the application, not that the application has processed the content. Step 4: Bundle forwarding. Step 4a: Test for bundle expiration. If the bundle has expired then it SHOULD be silently discarded. A bundle has expired if the current time is greater than the bundle's creation time plus its lifetime as specified in the primary bundle header. Step 4b: Custody transfer processing. If the bundle class of service requests custodial transfer, the bundle agent has to decide whether or not to take custody of the bundle. The decision as to whether or not to take custody of a bundle may involve both resource and policy considerations. If the agent elects to NOT K. Scott and S. Burleigh Expires - August 2003 [Page 25]
Internet Draft Bundle Protocol Specification March 2003 take custody of the bundle, it SHOULD forward the bundle as if it did not request custodial service. In particular, if the bundle agent does not take custody of the bundle then it MUST NOT modify the bundle's current custodian header. If the bundle requests custodial transfer and the agent elects to take custody of the bundle, then it MUST take the following actions: o If the bundle requests custody transfer reporting, a bundle status report indicating that the current agent is taking custody of the bundle SHOULD be generated. This report MAY be combined with a record of the bundle's reception, if such a report was not already generated and queued for transmission above. It is important to note that this bundle status report is addressed to the bundle's 'REPLY- TO' address; the bundle status report effecting the custodial acknowledgement is handled below. If the received bundle is a fragment (i.e. it contains a fragment header) the bundle status report MUST contain the Fragment flag and the fragment offset and fragment length fields. o The agent generates a bundle status report for the bundle, destined for the bundle's current custodian. This is the custodial acknowledgment that allows the previous custodian to release resources associated with the bundle. The bundle status report MUST contain the status flag indicating that the bundle agent has taken custody of the bundle. The status report MUST be sent with the CoS flag requesting custodial delivery set. If the received bundle is a fragment (i.e. it contains a fragment header) the bundle status report MUST contain the Fragment flag and the fragment offset and fragment length fields. o The bundle agent then modifies the bundle's current custodian header, setting itself as the bundle's current custodian. o The bundle agent MUST keep a copy of the bundle, and this copy SHOULD be in persistent storage if at all possible. o The bundle agent MUST set a retransmission timer so that the bundle will be retransmitted if a custody acknowledgement is not received. The value of the retransmission timer is up to the bundle agent. K. Scott and S. Burleigh Expires - August 2003 [Page 26]
Internet Draft Bundle Protocol Specification March 2003 o After the above, the normal bundle forwarding processing is resumed. Step 4c: Determine next hop for bundle. o If the bundle agent does NOT have an interface in the bundle's destination region, then it MUST determine the bundle's next hop using ONLY the bundle's destination region. The information in the bundle's endpoint identifier is NOT used at this time. In this case, the agent consults a region routing table to determine the next hop bundle agent to which the bundle will be transmitted. The agent then schedules the bundle for transmission. o If the bundle agent contains an interface in the bundle's destination region, then the bundle's next hop depends on whether the region is a DIRECT or an INDIRECT region. For DIRECT regions, the bundle can be transmitted directly to the communications entity specified in the administrative part of the bundle's destination tuple. For INDIRECT regions, the bundle agent consults a separate routing table to determine the 'care-of' host to which the bundle should be transmitted. Step 5: Forward the bundle. At this point the bundle agent can schedule the bundle for transmission via an appropriate convergence layer. 4.3 Bundle Fragmentation and Reassembly It may be necessary for bundle agents to break bundles into smaller units in order to forward them. This might be the case, for example, if the next hop destination is available only via intermittent contacts, and no upcoming contact is long enough to support sending the entire bundle. The process of breaking bundles into smaller units is called fragmentation. Reassembly of bundle fragments occurs at the ultimate destination. 4.3.1 Bundle Fragmentation Bundle fragments are themselves bundles, and are individually routable. When breaking a bundle into fragments, the following WILL be true: o All fragments will contain the same headers as the original bundle. In particular, the creation timestamps of all bundle K. Scott and S. Burleigh Expires - August 2003 [Page 27]
Internet Draft Bundle Protocol Specification March 2003 fragments MUST be the same as that of the original bundle. Recall that the pair (source tuple, creation timestamp) is unique for each bundle. This allows the destination to associate the bundle fragments with a single reconstructed bundle. The payload headers of the fragments MUST be modified to reflect the actual lengths of the fragments. o In addition to the original headers, each fragment MUST contain a fragment header identifying the original bundle's length and the fragment's position and length within the original bundle. Note that if a bundle fragment is further fragmented, the original bundle length from the fragment header is used in subsequent fragments. That is, there is only one 'level' of fragmentation (as in IP fragmentation). After fragmentation, the fragments are individually forwarded. 4.3.2 Bundle Reassembly Each bundle fragment contains a fragment header. The fragment header contains the original bundle's length as well as the fragment's offset within the original bundle. The fragment's bundle payload header contains the length of the current fragment. This information is enough for the receiving bundle agent to reconstruct the original bundle from the fragments. Security Considerations Section 3.13 of [2] describes the general methods for protecting the DTN infrastructure. In summary, bundle applications must present credentials to bundle agents before the agents will accept bundles from the applications. Agents sign all bundles they transmit, and receiving bundle agents discard any bundles whose signatures are not valid. Informative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] V. Cerf, et. al., "Delay-Tolerant Network Architecture," work in progress, draft-irtf-dtnrg-arch-02.txt, March 2003. [3] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial", Wartham Associates, Available from http://www.dtnrg.org K. Scott and S. Burleigh Expires - August 2003 [Page 28]
Internet Draft Bundle Protocol Specification March 2003 Acknowledgements The authors gratefully acknowledge the contributions of Dr. Vint Cerf of Worldcom, Dr. Kevin Fall of Intel Corporation, Adrian Hooke and Leigh Torgerson of the Jet Propulsion Laboratory, and Howard Weiss of SPARTA, Inc. Author's Addresses Dr. Keith L. Scott Scott C. Burleigh The MITRE Corporation Jet Propulsion Laboratory 1820 Dolley Madison Blvd. 4800 Oak Grove Drive M/S H300 M/S: 179-206 McLean, VA 22102 Pasadena, CA 91109-8099 Telephone +1 (703) 883-6547 Telephone +1 (818) 393-3353 FAX +1 (703) 883-7142 FAX +1 (818) 354-1075 Email kscott@mitre.org Email Scott.Burleigh@jpl.nasa.gov Intellectual Property Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. K. Scott and S. Burleigh Expires - August 2003 [Page 29]
Internet Draft Bundle Protocol Specification March 2003 Copyright "Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." K. Scott and S. Burleigh Expires - August 2003 [Page 30]
