Delay Tolerant Networking Research Group K. Scott Internet Draft The MITRE Corporation <draft-irtf-dtnrg-bundle-spec-01.txt> S. Burleigh October 2003 Jet Propulsion Laboratory Expires: April 20024 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 - April 2004 [Page 1]
Internet Draft Bundle Protocol Specification October 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....................14 3.2 Tuples.......................................14 3.3 Primary and Variable-Length Immutable Portion Headers15 3.4 Current Custodian Header........................18 3.5 Bundle Status Report HeaderError! Bookmark not defined. 3.6 Bundle Payload Header..........................19 3.7 Authentication Header..........................19 3.8 16-bit Extended Offset Header ...................19 3.9 Bundle Fragment Header .........................20 3.10 Rules Governing the Appearance and Order of Headers.21 4. Bundle Processing..............................21 4.1 Bundles received from applications via the API.....21 4.2 Bundles received from other bundle agents.........21 4.3 Bundle Fragmentation and Reassembly..............24 4.4 Bundle Status Reports..........................25 Security Considerations...................................27 Informative References....................................27 Acknowledgements.........................................27 Author's Addresses.......................................27 1. Introduction This document describes version 2 of the Delay Tolerant Networking (DTN) or bundling protocol. Delay Tolerant Networking 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 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 - April 2004 [Page 2]
Internet Draft Bundle Protocol Specification October 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 - April 2004 [Page 3]
Internet Draft Bundle Protocol Specification October 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 - April 2004 [Page 4]
Internet Draft Bundle Protocol Specification October 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 - April 2004 [Page 5]
Internet Draft Bundle Protocol Specification October 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 - April 2004 [Page 6]
Internet Draft Bundle Protocol Specification October 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 - April 2004 [Page 7]
Internet Draft Bundle Protocol Specification October 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 - April 2004 [Page 8]
Internet Draft Bundle Protocol Specification October 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 - April 2004 [Page 9]
Internet Draft Bundle Protocol Specification October 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 - April 2004 [Page 10]
Internet Draft Bundle Protocol Specification October 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 | When used as a next header type, | | No more headers | | indicates that no other headers | | | | follow the current one. +--------------------+------+---------------------------------------+ | Primary bundle | 0x01 | Must appear before any other bundle | | header | | header. | +--------------------+------+---------------------------------------+ K. Scott and S. Burleigh Expires - April 2004 [Page 11]
Internet Draft Bundle Protocol Specification October 2003 | Variable Length | 0x02 | (VLIP) contains source, destination, | | Immutable Portion | | and reply-to tuples. | +--------------------+------+---------------------------------------+ | Current Custodian | 0x03 | Indicates current bundle custodian. | | | | Present only if the custody transfer | | | | service is requested. | +--------------------+------+---------------------------------------+ | Reserved | 0x04 | Reserved for future use. | +--------------------+------+---------------------------------------+ | Bundle Payload | 0x05 | Identifies actual bundle content. | +--------------------+------+---------------------------------------+ | Reserved | 0x06 | Reserved for future use. | +--------------------+------+---------------------------------------+ | 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 - April 2004 [Page 12]
Internet Draft Bundle Protocol Specification October 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 Payload Header +----------------+----------------+----------------+----------------+ | Next Header | Length of bundle payload (4 bytes) +----------------+----------------+----------------+----------------+ | | +----------------+ | | Bundle Payload (variable) | | | / / / / | | +-------------------------------------------------------------------+ Authentication Header +----------------+----------------+----------------+----------------+ | Next Header | Length | Auth. information (variable) +----------------+----------------+----------------+----------------+ K. Scott and S. Burleigh Expires - April 2004 [Page 13]
Internet Draft Bundle Protocol Specification October 2003 16-bit Extended Offset Header +----------------+----------------+----------------+----------------+ | Next Header | Destination | Source +----------------+----------------+----------------+----------------+ | Reply-To | Cur. Custodian +----------------+----------------+----------------+----------------+ | +----------------+ Bundle Fragment Header +----------------+----------------+----------------+----------------+ | Next Header | Length of original bundle payload (4 bytes) +----------------+----------------+----------------+----------------+ | Offset of this bundle fragment (4 bytes) +----------------+--------------------------------------------------+ | -----------------+ 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. K. Scott and S. Burleigh Expires - April 2004 [Page 14]
Internet Draft Bundle Protocol Specification October 2003 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 tuple. 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. This document describes version 0x02 of the bundling protocol. 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 K. Scott and S. Burleigh Expires - April 2004 [Page 15]
Internet Draft Bundle Protocol Specification October 2003 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 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. The value of this field SHOULD be set to zero on send and ignored on receipt if the Delivery Request Flag for custodial transfer (see below) is not set. 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 - April 2004 [Page 16]
Internet Draft Bundle Protocol Specification October 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 - April 2004 [Page 17]
Internet Draft Bundle Protocol Specification October 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 - April 2004 [Page 18]
Internet Draft Bundle Protocol Specification October 2003 3.5 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 payload that the sender will try to transmit. Note that this may be less than the bundle's original payload length if fragmentation has occurred. 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.6 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 û 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.7 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: K. Scott and S. Burleigh Expires - April 2004 [Page 19]
Internet Draft Bundle Protocol Specification October 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. 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.8 Bundle Fragment Header Bundle fragment headers are present in all bundle fragments whose offsets from the beginning of the original bundle are non-zero. Bundle fragment headers MAY also appear in bundles whose offsets from the beginning of the original bundle are zero. The fields of the Bundle Fragment 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 of Original Bundle Payload. This is the total length of the original bundle's payload before any fragmentation. Fragment Offset. The byte offset of the beginning of this fragment within the original bundle. Note: It is assumed that the transport mechanisms underlying bundling provide to bundle nodes the lengths of bundles received. Thus a bundle node can determine the payload (original or fragment) length without having it explicitly indicated by a header element. K. Scott and S. Burleigh Expires - April 2004 [Page 20]
Internet Draft Bundle Protocol Specification October 2003 3.9 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 There can be at most one bundle payload header per bundle. 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 and queued for transmission to the bundle's reply-to address. K. Scott and S. Burleigh Expires - April 2004 [Page 21]
Internet Draft Bundle Protocol Specification October 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 is a fragment of a larger bundle, it MUST be combined with the rest of the fragments that make up the entire original bundle before the content can be further processed. Identification of bundle fragments is discussed below. Step 3b: Processing custody acknowledgements. Destination nodes MAY take custody of custodially transferred bundles as in step 4b below. Note that destination bundle nodes SHOULD make every effort to either take custody of a custodially transferred bundle or to inform the current custodian and ultimate source that the destination is unable to receive 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 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: K. Scott and S. Burleigh Expires - April 2004 [Page 22]
Internet Draft Bundle Protocol Specification October 2003 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, 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. 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 identifier, then it MUST determine the bundle's next hop using ONLY the bundle's destination region identifier. 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 is a local policy matter. Bundle routers may forward bundles directly to their destinations once in the destination region, or they may forward bundles to intermediate point(s) in the region. K. Scott and S. Burleigh Expires - April 2004 [Page 23]
Internet Draft Bundle Protocol Specification October 2003 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 bundle agent. 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 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. o In addition to the original headers, each bundle fragment that does not begin at offset 0 within the original bundle MUST contain a fragment header identifying the fragment's position within the original bundle and the length of the original (unfragmented) bundle's payload. Note that there is only one 'level' of fragmentation (as in IP fragmentation). After fragmentation, the fragments are individually forwarded. A bundle node that decides to proactively fragment a bundle does so before it begins transmission. In this case, the first fragment MAY contain 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. K. Scott and S. Burleigh Expires - April 2004 [Page 24]
Internet Draft Bundle Protocol Specification October 2003 4.4 Bundle Status Reports One of the delivery options that senders can request is 'bundle status reports.' These reports are intended to provide information about how bundles are progressing through the system, including times of receipt and forwarding, and custodial operations. On receiving a bundle that requests that status reports be sent, a bundle node MAY generate a status report addressed to the bundle's reply-to address. Status reports are carried in the payload sections of bundles, and have the following format. Bundle Status Report Header for bundle 'X' +----------------+----------------+----------------+----------------+ | Status Flags | Fragment offset (4 bytes, if present) +----------------+----------------+----------------+----------------- | Fragment length (4 bytes, if present) +--------------------------------------------------+----------------+ | Copy of bundle X's Send Timestamp (8 bytes) | +----------------+ + | | + +----------------+----------------+----------------+ | | Time of Receipt fo 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 - April 2004 [Page 25]
Internet Draft Bundle Protocol Specification October 2003 The fields in a bundle status report are: Status Flags. A 1-byte field containing the following flags: Table 4: Status Flags for Bundle Status Reports +---------+--------------------------------------------+ | 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 (TOF) 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 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. K. Scott and S. Burleigh Expires - April 2004 [Page 26]
Internet Draft Bundle Protocol Specification October 2003 The action that the reply-to addressee takes on receipt of a bundle status report is application-specific. 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 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 K. Scott and S. Burleigh Expires - April 2004 [Page 27]
Internet Draft Bundle Protocol Specification October 2003 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. Copyright "Copyright (C) The Internet Society (date). 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 K. Scott and S. Burleigh Expires - April 2004 [Page 28]
Internet Draft Bundle Protocol Specification October 2003 PARTICULAR PURPOSE." K. Scott and S. Burleigh Expires - April 2004 [Page 29]
