Internet Draft Bundle Protocol Specification September 2004 Delay Tolerant Networking Research Group K. Scott Internet Draft The MITRE Corporation <draft-irtf-dtnrg-bundle-spec-02.txt> September 2004 S. Burleigh Expires: March 2005 Jet Propulsion Laboratory Bundle Protocol Specification Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we am aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with Sections 5 and 6 of RFC3667 and Section 5 of RFC3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG). See http://www.dtnrg.org for more information. 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). K. Scott and S. Burleigh Expires - March 2005 [Page 1]
Internet Draft Bundle Protocol Specification September 2004 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]. Table of Contents 1. Introduction..........................................3 2. Service Description...................................4 2.1 Definitions...........................................4 2.2 Services at the User Interface........................5 2.3 Summary of Primitives.................................5 2.3.1 Requests..............................................5 2.3.2 Indications...........................................6 2.4 Summary of Parameters.................................6 2.4.1 Destination Communications endpoint ID................6 2.4.2 Source Communications endpoint ID.....................6 2.4.3 Report Communications endpoint ID.....................6 2.4.4 Class of Service......................................6 2.4.5 Delivery Options......................................7 2.4.6 Lifespan..............................................7 2.4.7 Application Data Unit.................................7 2.4.8 Delivery Failure Action...............................7 2.5 Bundling Service Primitives...........................8 2.5.1 SEND.REQUEST..........................................8 2.5.2 CANCELBUNDLE.REQUEST..................................8 2.5.3 REGISTER.REQUEST......................................9 2.5.4 START-DELIVERY.REQUEST................................9 2.5.5 STOP-DELIVERY.REQUEST................................10 2.5.6 CHANGE-REGISTRATION.REQUEST..........................10 2.5.7 DEREGISTER.REQUEST...................................10 2.5.8 POLL.REQUEST.........................................11 2.5.9 DATA.INDICATION......................................11 2.5.10 SENDERROR.INDICATION.................................12 2.5.11 SENDTOKEN.INDICATION.................................12 2.5.12 REGISTRATIONTOKEN.INDICATION.........................13 3. Bundle Message Format................................13 3.1 General Bundle Header Format.........................16 3.2 Tuples...............................................16 3.3 Primary Bundle Header................................17 3.4 Bundle Payload Header................................20 3.5 Bundle Authentication Header.........................20 3.6 Payload Security Header..............................20 3.7 Bundle Fragment Header...............................21 3.8 Dictionary Header....................................21 3.9 Rules Governing the Appearance and Order of Headers..22 4. Bundle Processing....................................22 4.1 Bundle transmission requests.........................22 4.2 Bundles received from other bundle agents............22 K. Scott and S. Burleigh Expires - March 2005 [Page 2]
Internet Draft Bundle Protocol Specification September 2004 4.3 Local bundle delivery................................25 4.4 Bundle forwarding....................................25 4.5 Bundle Fragmentation and Reassembly..................26 4.5.1 Bundle Fragmentation.................................26 4.5.2 Bundle Reassembly....................................28 4.6 Custodial Retransmission and Release.................28 5. Administrative Payloads..............................29 5.1 Bundle Status Reports................................29 5.2 Custodial Signals....................................32 6. Services Required of the Convergence Layer...........35 6.1 The Convergence Layer................................35 6.2 Summary of Convergence Layer Services................36 6.3 Summary of Primitives................................36 6.3.1 Requests.............................................36 6.3.2 Indications..........................................36 6.4 Summary of Parameters................................36 6.4.1 Receiving Bundle Agent Endpoint ID...................36 6.4.2 Sending Bundle Agent Endpoint ID.....................36 6.4.3 Bundle...............................................36 6.4.4 Bundle length........................................37 6.4.5 Bundle authenticity..................................37 6.4.6 Transmit length......................................37 6.5 Convergence Layer Service Primitives.................37 6.5.1 TRANSMIT.REQUEST.....................................37 6.5.2 TRANSMIT-REPORT.INDICATION...........................38 6.5.3 BUNDLE.INDICATION....................................38 1. Introduction This document describes version 3 of the Delay Tolerant Networking (DTN) "bundling" protocols. 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 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 K. Scott and S. Burleigh Expires - March 2005 [Page 3]
Internet Draft Bundle Protocol Specification September 2004 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 adapter. 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 layer adapters, although it does discuss the services that must be provided by the convergence layer. o The bundle routing algorithm or mechanisms for populating the routing or forwarding information bases of bundle nodes. 2. Service Description 2.1 Definitions Communications Endpoint ID - A Communications Endpoint ID identifies an application endpoint of DTN communications; the term corresponds to the term '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 indicated region. One can think of a DTN communications endpoint as an application task, 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 K. Scott and S. Burleigh Expires - March 2005 [Page 4]
Internet Draft Bundle Protocol Specification September 2004 information about certain topics of interest. A communications endpoint ID 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. Agent administration endpoint ID - Every bundle agent, in addition to being a sender, forwarder, and/or receiver of bundles, may also be the source and/or destination of bundle payloads (e.g., custody signals); that is, it may additionally function as a bundle application. Each agent therefore has its own "agent administration" endpoint ID(s), so that bundles can be addressed and routed to it from anywhere in the network. 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 handle passed from a bundle application to the bundle agent when sending a bundle / registering to receive bundles. This handle is used to associate an opaque token returned by the bundle agent with a specific bundle / registration. The terms "bundle content" and "bundle payload" (or simply "payload") are used interchangeably in this document. The payload of an "original" bundle - i.e., one that is not a fragment of some larger bundle - is an application data unit. 2.2 Services at the User Interface The bundling protocol SHALL provide the following services to bundling applications: a) sending an application data unit to an identified communications endpoint; b) canceling a previously submitted request to send an application data unit; c) beginning a period of passive application data unit reception; d) ending a period of passive application data unit reception; e) actively requesting delivery of an application data unit. 2.3 Summary of Primitives 2.3.1 Requests The bundling services SHALL consume the following request primitives from bundling applications: K. Scott and S. Burleigh Expires - March 2005 [Page 5]
Internet Draft Bundle Protocol Specification September 2004 a) Send.request; b) Cancel.request c) Register.request; d) Start_delivery.request; e) Stop_delivery.request; f) Change_registration.request; g) Deregister.request; h) Poll.request; 2.3.2 Indications The Bundling services SHALL deliver the following indication primitives to bundling applications: a) Data.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 shall identify the communications endpoint to which the application data unit is to be sent. 2.4.2 Source Communications endpoint ID The source communications endpoint ID parameter shall uniquely identify the communications endpoint from which the application data unit was sent. 2.4.3 Report Communications endpoint ID The report communications endpoint ID parameter shall identify the communications endpoint to which any bundle status reports pertaining to the application data unit, including end-to-end acknowledgments, should be sent. 2.4.4 Class of Service The class of service parameter shall indicate which class of standard procedures shall be followed when transmitting and delivering the application data unit. Its value shall be one of the following: K. Scott and S. Burleigh Expires - March 2005 [Page 6]
Internet Draft Bundle Protocol Specification September 2004 o Bulk o Normal o Expedited 2.4.5 Delivery Options The delivery options parameter shall indicate what optional procedures shall additionally be followed when transmitting and delivering the application data unit. Its value shall be a combination of zero or more of the following: o Custody transfer o Return receipt o Report when bundle received o Report when bundle forwarded o Report when bundle custody taken o Payload security requirements - Confidentiality - Integrity - Authentication 2.4.6 Lifespan 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 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 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 application data unit reception. Its value shall be one of the following: o Defer delivery until the entity either actively requests delivery of the application data unit or else begins a period of passive application data unit reception. o Abort delivery of the application data unit. o Defer delivery and also execute a specified procedure, where the expression of the procedure to be executed is a matter of local implementation. K. Scott and S. Burleigh Expires - March 2005 [Page 7]
Internet Draft Bundle Protocol Specification September 2004 2.5 Bundling Service Primitives 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, report communications endpoint ID, class of service, delivery options, lifespan, send token binding, application data unit) When Generated: Send.request MAY be 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 as described in section 4.1. The agent will deliver either a SendError.indication or a SendToken.indication to the application. The SendToken.indication contains the send token binding and a token that the application can later use to refer to this transmission. Additional Comments: None. 2.5.2 CANCELBUNDLE.REQUEST The CancelBundle.request primitive shall be used by the application to request that a bundle transmission previously initiated in response to 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 application data via the Send.request and after receiving a reference token for the transmission via a SendToken.indication. A CancelBundle.request should be sent if the application no longer wishes to effect the transmission referenced by the send token. Effect on Receipt: Receipt of CancelBundle.request shall cause the Bundling agent to cease attempts to effect the indicated transmission. 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 - March 2005 [Page 8]
Internet Draft Bundle Protocol Specification September 2004 Additional Comments: None. 2.5.3 REGISTER.REQUEST The Register.request primitive shall be used to notify the Bundling agent of the application's interest in bundles destined for a specified communications endpoint and of the action to take on the application's behalf with regard to those bundles. 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 registered. Effect on Receipt: Receipt of Register.request shall cause the agent to deliver a RegisterToken.indication to the application. The RegisterToken.indication contains the registration token binding and a token that the application can use to refer to this registration. Receipt of Register.request shall additionally cause the indicated delivery failure action to be applied to all arriving bundles destined for the indicated endpoint ID at any time when the application is not in a period of passive application data unit reception associated with this registration. Additional Comments: Multiple applications may register interest in bundles destined for the same communications endpoint, in which case the Bundling agent MUST honor individually the delivery failure actions specified for each such registration as applicable. Implementations MAY require that an expiration time be specified when Register.request is submitted, to enable the Bundling agent to conserve resources by autonomously issuing Deregister.requests as registrations expire. 2.5.4 START-DELIVERY.REQUEST The Start-delivery.request primitive shall be used to notify the Bundling agent of the start of a period of passive application data unit reception. Semantics: Start-delivery.request shall provide parameters as follows: Start-delivery.request( registration token) When Generated: Start_delivery.request is generated by any Bundling application at any time when it is registered but not currently in a period of passive application data unit reception. K. Scott and S. Burleigh Expires - March 2005 [Page 9]
Internet Draft Bundle Protocol Specification September 2004 Effect on Receipt: Receipt of Start-delivery.request shall cause the Bundling agent to deliver to the Bundling application the contents of any bundles destined for the registration's endpoint ID that (a) arrived in the past and were deferred or (b) arrive during the new period of passive application data unit reception. 2.5.5 STOP-DELIVERY.REQUEST The Stop-delivery.request primitive shall be used to notify the Bundling agent of the end of a period of passive application data unit reception. Semantics: Stop-delivery.request shall provide parameters as follows: Stop-delivery.request( registration token) When Generated: Stop-delivery.request MAY be generated by any Bundling application at any time when the application is currently in a period of passive application data unit reception. Effect on Receipt: Receipt of Stop-delivery.request shall cause the Bundling agent to dispatch any subsequently arriving bundles destined for the registration's endpoint in accord with the registration's delivery failure action. 2.5.6 CHANGE-REGISTRATION.REQUEST The Change-registration.request primitive shall be used to amend the action to take on the application's behalf with regard to bundles destined for the registration's endpoint. Semantics: Change-registration.request shall provide parameters as follows: Change-registration.request( registration token, delivery failure action) When Generated: Change-registration.request MAY be generated by any Bundling application at any time when registered. Effect on Receipt: Receipt of Change-registration.request shall cause the indicated delivery failure action to be applied to all arriving bundles destined for the registration's ID at any time when the application is not in a period of passive application data unit reception associated with this registration. 2.5.7 DEREGISTER.REQUEST The Deregister.request primitive shall be used to notify the Bundling agent of the end of the application's interest in bundles destined for an endpoint. Semantics: Deregister.request shall provide parameters as follows: K. Scott and S. Burleigh Expires - March 2005 [Page 10]
Internet Draft Bundle Protocol Specification September 2004 Deregister.request(registration token) When Generated: Deregister.request MAY be generated by any Bundling application at any time when registered. Effect on Receipt: Receipt of Deregister.request shall cause the Bundling agent to terminate the indicated registration. Any bundles retained for deferred delivery per this registration shall be discarded and the delivery failure action policy associated with this registration shall be rescinded. Additional Comments: None. 2.5.8 POLL.REQUEST The Poll.request primitive shall be used to request immediate delivery of a bundle's content. Semantics: Poll.request shall provide parameters as follows: Poll.request(registration token) When Generated: Poll.request MAY be generated by any Bundling application at any time when it is registered but not currently in a period of passive application data unit reception. Effect on Receipt: Receipt of Poll.request shall cause the Bundling Agent to deliver to the Bundling application the content of the least recently received bundle, destined for the registration's communications endpoint ID, for which delivery was deferred. 2.5.9 DATA.INDICATION The Data.indication primitive shall be used to deliver the content of a bundle to the bundle's destination communications endpoint. Semantics: Data.indication shall provide parameters as follows: Data.indication( source communications endpoint ID, destination communications endpoint ID, report communications endpoint ID, class of service, delivery options, lifespan, application data unit) When Generated: Data.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. Effect on Receipt: The effect on receipt of Data.indication by a Bundling application is undefined. K. Scott and S. Burleigh Expires - March 2005 [Page 11]
Internet Draft Bundle Protocol Specification September 2004 Additional Comments: None. 2.5.10 SENDERROR.INDICATION The SendError.indication primitive shall be used to deliver information about bundle transmission requests 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, report communications endpoint ID, class of service, delivery options, lifespan, application data unit) When Generated: SendError.indication shall be generated when a Send.request primitive 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.11 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 transmission effected in response to a 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 an application data unit is accepted by the agent for transmission. The send token binding parameter is the same as that supplied with the Send.request, and the send token can be supplied to refer to that 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 - March 2005 [Page 12]
Internet Draft Bundle Protocol Specification September 2004 2.5.12 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 established via 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. The registration token binding parameter is the same as that supplied with the Register.request, and the registration token can be supplied to refer to that registration. Effect on Receipt: The effect on receipt of RegistrationToken.indication by a Bundling application is undefined. Additional Comments: None. 3. Bundle Message Format The DTN protocols use a chained header format reminiscent of IPv6 headers. Each bundle consists of at least a primary bundle header and a dictionary header. Other header types can be chained after the dictionary header to support additional functionality such as authentication, bundle fragmentation, etc. This section describes the format of the different bundle headers. Rules for processing bundle headers appear in section 4 of this document. K. Scott and S. Burleigh Expires - March 2005 [Page 13]
Internet Draft Bundle Protocol Specification September 2004 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. | +--------------------+------+---------------------------------------+ | Dictionary | 0x02 | Contains string text corresponding | | header | | to the string numbers used in the | | | | primary header. | +--------------------+------+---------------------------------------+ | Reserved | 0x03 | Reserved for future use. | +--------------------+------+---------------------------------------+ | Reserved | 0x04 | Reserved for future use. | +--------------------+------+---------------------------------------+ | Bundle Payload | 0x05 | Identifies actual bundle content. | +--------------------+------+---------------------------------------+ | Reserved | 0x06 | Reserved for future use. | +--------------------+------+---------------------------------------+ | Bundle | 0x07 | Used to assure the authenticity | | authentication | | of the bundle. | +--------------------+------+---------------------------------------+ | Payload security | 0x08 | Used to assure the integrity and | | | | (optionally) authenticity of the | | | | payload. | +--------------------+------+---------------------------------------+ | Bundle Fragment | 0x09 | This bundle is a fragment of a | | | | larger one. | +--------------------+------+---------------------------------------+ | All other values reserved for future use. | +--------------------+------+---------------------------------------+ K. Scott and S. Burleigh Expires - March 2005 [Page 14]
Internet Draft Bundle Protocol Specification September 2004 The format of the various headers is shown in Figure 2 below. Primary Bundle Header +----------------+----------------+----------------+----------------+ | Version | Next Header | COS Flags | Pyld security | +----------------+----------------+----------------+----------------+ | Destination | Source | Report-to | Custodian | +----------------+----------------+----------------+----------------+ | | + Creation Timestamp (8 bytes) + | | +---------------------------------+---------------------------------+ | Expiration Time | +----------------+----------------+---------------------------------+ Dictionary Header +----------------+----------------+----------------+----------------+ | Next Header | String count | String records (variable) + +-------------------------------------------------------------------+ Bundle Fragment Header +----------------+----------------+----------------+----------------+ | Next Header | Length of original bundle payload (4 bytes) +----------------+----------------+----------------+----------------+ | Offset of this bundle fragment (4 bytes) +----------------+--------------------------------------------------+ | -----------------+ Bundle Authentication Header +----------------+----------------+----------------+----------------+ | Next Header | Length | Auth. information (variable) +----------------+----------------+----------------+----------------+ Payload Security Header +----------------+----------------+----------------+----------------+ | Next Header | Length | Security information (variable) +----------------+----------------+----------------+----------------+ K. Scott and S. Burleigh Expires - March 2005 [Page 15]
Internet Draft Bundle Protocol Specification September 2004 Bundle Payload Header +----------------+----------------+----------------+----------------+ | Payload class | Length of bundle payload (4 bytes) +----------------+----------------+----------------+----------------+ | | +----------------+ | | Bundle Payload (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 exceptions to this rule are the primary bundle header, which must appear before any other bundle sub- headers, and the payload header, which if present must be the last sub-header in the bundle. 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. The payload header begins with a 1-byte payload class that indicates whether the payload consists of administrative records (see section 5) or non-administrative application data. All multi-byte fields are transmitted in network byte order. 3.2 Tuples Communicating entities in the DTN are referred to via name tuples, also known as communication endpoint IDs (see section 2.1). A name tuple is an ordered pair of variable-length octet arrays. The first octet array of a name tuple is termed the "routing part" or "region ID". It is a sequence of US ASCII characters encoded using the punycode transfer encoding syntax documented in RFC 3492, with reference to RFCs 3490 and 3491. Simply put, a region ID is a dotted string where the sequence of characters between any pair of dots - or preceding the first dot, or in the entire string if the string contains no dots - must not contain any character that is illegal in a domain name as defined by RFC 1035, but may specifically begin with the reserved internationalization prefix "ùxn" indicating the scheme by which the remaining ASCII characters in the sequence may be translated to Unicode. K. Scott and S. Burleigh Expires - March 2005 [Page 16]
Internet Draft Bundle Protocol Specification September 2004 The second octet array of a name tuple is termed the "administrative part" of the endpoint ID. It may be encoded in any of three possible ways: o A single 8-bit integer, which is to be interpreted in a region-specific manner. o A single 16-bit integer, which is to be interpreted in a region-specific manner. o An absolute URI, as defined in RFC 2396. If the first character of a region ID is a dot, then the ensuing sequence of characters preceding the next dot identifies the "name invariance family" (NIF) to which the named region belongs; any DTN endpoint that is identified by administrative-part "X" within any region that is a member of NIF "Q" is guaranteed to be identified by X within every other region that is a member of Q. The routing part of a DTN name tuple must be globally parsable throughout the DTN. The administrative part is opaque outside of the indicated region, but must be parsable anywhere in that region. For economy in bundle transmission, redundancy in the representation of tuples is minimized by the use of "string numbers" in the primary bundle header. The distinct octet arrays that serve as the routing and administrative parts of the tuples identifying a bundle's destination, source, report-to endpoint, and current custodian are enumerated in the string records of the dictionary header; the tuples themselves are represented in the primary bundle header by ordered pairs of 4-bit "string numbers" that reference those string records. A string number is an ordinal reference to a string record, i.e., string number zero is a reference to the first string record in the dictionary header, string number 1 is a reference to the second string record, etc. Each tuple representation in the primary bundle header is a single byte comprising two string numbers: the 4 high- order bits identify the string record whose text is the routing part (region identifier) of the tuple, while the 4 low-order bits identify the string record whose text is the administrative part of the tuple. 3.3 Primary Bundle Header The primary bundle header contains the basic information needed to route bundles to their destinations. The fields 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 0x03 of the bundling protocol. K. Scott and S. Burleigh Expires - March 2005 [Page 17]
Internet Draft Bundle Protocol Specification September 2004 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. Class of Service Flags. The COS Flags byte consists of a 1-bit custody switch followed by three (3) bits of priority and four (4) bits of delivery record request flags. If the custody bit is 1 then the sender requests custodial transfer of the bundle. The three-bit priority field indicates the bundle's priority, with higher values being of higher priority. The interpretation of the delivery record request flags is as follows. Table 2: Delivery Record Request Flag Meanings +---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 0000 | No delivery records requested. | +---------+--------------------------------------------+ | 0001 | Request custody transfer reporting. | +---------+--------------------------------------------+ | 0010 | Request reporting of bundle reception. | +---------+--------------------------------------------+ | 0100 | Request reporting of bundle forwarding. | +---------+--------------------------------------------+ | 1000 | Request end-to-end return receipt. | +---------+--------------------------------------------+ Payload Security. The Payload Security byte consists of one bit indicating whether or not the payload is encrypted, two bits of payload integrity flags, and five bits reserved for future use. The encryption bit is a Boolean value; it is set to 1 if and only if the payload is encrypted in a key system in which both the source and destination application endpoints' bundle agents are participants. The payload integrity flags indicate whether or not a Payload Security header is present in the bundle and, if so, whether that header serves to assure bundle authenticity or only bundle integrity; the nature of the information in the Payload Security header (e.g., the hash algorithm used) is encoded within the header. The interpretation of the payload integrity flags is as follows. K. Scott and S. Burleigh Expires - March 2005 [Page 18]
Internet Draft Bundle Protocol Specification September 2004 Table 3: Payload Integrity Flag Meanings +---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 00 | No bundle integrity or authentication. | +---------+--------------------------------------------+ | 01 | Bundle integrity is supported. | +---------+--------------------------------------------+ | 10 | Bundle authentication is supported. | +---------+--------------------------------------------+ Destination. This 1-byte field contains the two 4-bit string numbers for the Region ID (routing part) and administrative part of the tuple identifying the destination endpoint. Source. A 1-byte field containing the two 4-bit string numbers for the Region ID (routing part) and administrative part of the tuple identifying the source endpoint. Report-To. A 1-byte field containing the two 4-bit string numbers for the Region ID (routing part) and administrative part of the tuple identifying the report-to endpoint. Current custodian. A 1-byte field containing the two 4-bit string numbers for the Region ID (routing part) and administrative part of the tuple identifying the current custodian endpoint. 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 value of this field MUST be set to zero on send and ignored on receipt if the custody switch in the class of service (above) is zero. Creation Timestamp. The creation timestamp is an 8-byte field containing the time the bundle payload was accepted for transmission by the source bundle agent, formatted as an NTP timestamp[4]. 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 original (non-fragmentary) bundle in the system. Note that this implies that a bundle agent MUST NOT accept for transmission two K. Scott and S. Burleigh Expires - March 2005 [Page 19]
Internet Draft Bundle Protocol Specification September 2004 or more payloads during a time interval bounded by two successive NTP timestamps. 3.4 Bundle Payload Header The fields of the bundle payload header are: Payload Class. The Payload Class field is a 1-byte field that indicates the nature of the payload. The field contains 0x01 if the payload consists of one or more Bundling administrative records (see section 5) and 0x00 otherwise. Length. A 4-byte field indicating the total length, in bytes, of the payload. 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 application data carried by this bundle. 3.5 Bundle Authentication Header The fields of the bundle 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. A 1-byte field indicating the total length, in bytes, of the authentication information. Authentication information. The authentication information is the result of generating a hash over the entire bundle (excluding the bundle authentication header itself), then running the hash through a signature algorithm - e.g., sign using sender's private key. Bundle authentication information is generated and checked on a hop-by-hop basis, between neighboring bundle agents along the end-to-end route of the bundle, to contain unauthorized use of delay tolerant network assets. 3.6 Payload Security Header The fields of the payload security 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 security information. K. Scott and S. Burleigh Expires - March 2005 [Page 20]
Internet Draft Bundle Protocol Specification September 2004 Security information. The security information is the result of generating a hash over the entire payload, then optionally running the hash through a signature algorithm - e.g., sign using source's private key. Payload security information is generated and checked on an end-to-end basis, between the source and destination communication endpoints' bundle agents, to assure the integrity and (optionally) authenticity of the delivered payload. 3.7 Bundle Fragment Header A "bundle fragment" is a bundle whose payload is some part of the payload of a larger "original" bundle; the payload of a bundle fragment is identified by its offset from the beginning of the original bundle's payload. Bundle fragment headers are present in all bundle fragments. 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's payload within the original bundle's payload. Note: As described in section 6, the "convergence layer" transport mechanisms underlying bundling are required to provide to bundle nodes the length of each bundle received. The length of a received bundle payload may be computed by subtracting the sum of the lengths of the bundle's headers from this reported bundle length. Reactive fragmentation is required when, and only when, this computed payload length is less than the payload length declared in the bundle's payload header. 3.8 Dictionary Header The fields of the dictionary 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. String Count. A 1-byte field indicating the number of string records in this header. String Records. This is a variable-length field comprising some number (indicated in the String Count) of concatenated string K. Scott and S. Burleigh Expires - March 2005 [Page 21]
Internet Draft Bundle Protocol Specification September 2004 record structures. Each string record structure has this format: +----------------+----------------+----------------+----------------+ | Length | String text (variable) + +-------------------------------------------------------------------+ The fields of the string record structure are: Length. A 1-byte field indicating the total length, in bytes, of the string text. String text. The text of the octet array to which the sending bundle agent refers when citing this string record's ordinal position within the string records field of the dictionary header. 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. o The dictionary record must immediately follow the primary header. o There can be at most one header of each other type per bundle. o If a payload header is present, it must be the last header in the bundle. o Rules regarding the order of appearance of other header types have not yet been established. 4. Bundle Processing There are currently no provisions for multipoint delivery of bundle payloads. 4.1 Bundle transmission requests The steps in processing a Send.request primitive are: 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. Requests that meet the policy criteria shall result in the return of SendToken.indications; those that do not shall result in the return of SendError.indications. Step 2: If the request is accepted, then an outbound bundle is created and processing proceeds from Step 5 of section 4.2. 4.2 Bundles received from other bundle agents K. Scott and S. Burleigh Expires - March 2005 [Page 22]
Internet Draft Bundle Protocol Specification September 2004 Note that whenever an administrative record (bundle status report or custodial signal) is generated in response to receipt of a bundle that is a fragment of some original bundle, the administrative record MUST contain the Fragment flag and the fragment offset and fragment length fields. All administrative records are sent as the payloads of bundles. Bundles containing custodial signals MUST be sent with the CoS flag requesting custodial delivery set, except when the payload of the referenced bundle is itself a custodial signal. The steps in processing a bundle received from another bundle agent are: Step 1: Bundle Authentication: The bundle must first be authenticated as described in section 3.13 of [2], in one of two ways: either (a) the authenticity of the bundle must have been asserted by the convergence layer or (b) the bundle must contain a Bundle Authentication header whose signature is valid according to the certificate of the sending bundle agent. The purpose of this authentication is to protect the bundle transmission infrastructure, not to provide security services to bundle applications. If the authentication fails then the bundle MUST be discarded and processed no further; in this case a bundle status report indicating the authentication failure MAY be generated, destined for the receiving bundle agent's own administration endpoint. Step 2: Generate a bundle reception status report, if requested. If the bundle's class of service requests that a bundle reception status report be generated when the bundle is received, a bundle reception status report MUST be generated, destined for the bundle's report-to endpoint ID. Step 3: Bundle custody transfer. If the bundle's 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, then it MUST take the following actions: o If for any reason the agent elects to discard the bundle altogether, the agent MUST generate a "Failed" custodial signal for the bundle, destined for the agent administration endpoint of the bundle's current custodian (the bundle agent that most recently took custody of the bundle); the custodial signal MUST contain a reason code explaining the failure of custody transfer. The bundle MUST then be discarded and processed no further. K. Scott and S. Burleigh Expires - March 2005 [Page 23]
Internet Draft Bundle Protocol Specification September 2004 o If the bundle is not discarded and its destination tuple matches one of the bundle agent's interfaces, the agent MUST generate a "Succeeded" custodial signal for the bundle, destined for the agent administration endpoint of the bundle's current custodian; the reason code in the signal MUST be "Delivery to application by non-custodian". o If the bundle is not discarded and its destination tuple does not match any of the bundle agent's interfaces, then when forwarding the bundle the agent MUST NOT assert a new current custodian for the bundle, i.e., it MUST NOT change the agent administration endpoint ID that is encoded as the bundle's current custodian. If the agent elects to take custody of the bundle, then it takes the following actions: o If the bundle's class of service indicates that custody transfer reporting is requested, a bundle status report indicating that the current agent is taking custody of the bundle MUST be generated, destined for the report-to endpoint ID of the bundle. If a bundle reception status report was generated above, this additional status report SHOULD be appended to the payload of the bundle in which that status report is sent. o The agent MUST generate a "Succeeded" custodial signal for the bundle, destined for the agent administration endpoint of the bundle's current custodian; the reason code in the signal MUST be "Acceptance of custody". o The bundle agent MUST modify the current custodian ID, changing that identifier to the agent's own administration endpoint ID. This may entail the insertion of new string records into the bundle's dictionary header and, possibly, the removal of string records to which there is no longer any reference in the bundle's primary header. o The bundle agent MAY set a custody transfer timer as an alternate means of initiating the procedures described in 4.6 below. The value of the retransmission timer interval is up to the bundle agent. o The bundle agent MUST keep a copy of the bundle until it can be discarded in accord with the procedures described in Step 4 below or section 4.6 below, and this copy SHOULD be in persistent storage if at all possible. Step 4: Test for bundle expiration. 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. If the bundle K. Scott and S. Burleigh Expires - March 2005 [Page 24]
Internet Draft Bundle Protocol Specification September 2004 has expired then it MUST be discarded and processed no further; if the bundle's class of service requests custodial transfer and the local bundle agent is now the bundle's current custodian, then a bundle status report indicating TTL expiration MUST be generated, destined for the bundle's report-to endpoint ID. Step 5: Dispatch the bundle. If the bundle's destination tuple matches one of the bundle agent's interfaces, processing proceeds from Step 1 of section 4.3; otherwise, processing proceeds from Step 1 of section 4.4. 4.3 Local bundle delivery The steps described here are carried out ONLY if the bundle's destination tuple matches one of the bundle agent's interfaces. Step 1: Reassembly. If the received bundle is a fragment of a larger bundle, its payload MUST be combined with the payloads of the rest of the fragments that make up the entire original bundle before the bundle content can be further processed. Identification and processing of bundle fragments is discussed in section 4.5 below. Step 2: If one or more applications have registered with the bundle agent with the bundle's destination communication endpoint ID, the original bundle content (payload) SHALL be delivered to each such application in a Data.indication when either (a) the corresponding registration is in - or enters - a period of passive bundle reception or (b) the application uses a Poll.request to initiate active bundle reception. If the bundle's destination endpoint ID is the bundle agent's own administration endpoint ID, then the administrative record contained in the bundle's payload is processed as described in section 4.6 below. Step 3: If the bundle's class of service requests that an end-to-end return receipt be sent, such a receipt MUST be generated, destined for the bundle's report-to endpoint ID, as soon as the bundle content has been delivered to at least one application. Note that this return receipt only states that the bundle payload has been delivered to an application, not that any application has processed the content. 4.4 Bundle forwarding The steps described here are carried out ONLY if the bundle's destination tuple does not match any of the bundle agent's interfaces. Step 1: Determine next hop for bundle. K. Scott and S. Burleigh Expires - March 2005 [Page 25]
Internet Draft Bundle Protocol Specification September 2004 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 identifier. The information in the administrative part of the bundle's destination endpoint identifier is NOT used at this time. The agent determines the next hop bundle agent to which the bundle will be transmitted and 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 bundle agents serving as intermediate point(s) in the region. Step 2: Forward the bundle. At this point the bundle agent can schedule the bundle for transmission via an appropriate convergence layer adapter. Step 3: Generate a bundle forwarding status report if requested. If the bundle's class of service requests that a bundle forwarding status report be generated when the bundle is forwarded, a bundle forwarding status report MUST be generated, destined for the bundle's report-to endpoint ID, when the convergence layer announces that the bundle has been transmitted. 4.5 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. Bundles MAY also be reassembled from fragments by other bundle agents on the route to the final destination, relieving the ultimate destination bundle agent of this responsibility. 4.5.1 Bundle Fragmentation Bundle fragments are themselves bundles and are individually routable. When breaking a bundle into fragments, the following SHALL be true: o All fragments MUST contain the same headers as the original bundle, other than the payload header. In particular, the creation timestamps in the primary headers 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 original bundle. This allows the destination K. Scott and S. Burleigh Expires - March 2005 [Page 26]
Internet Draft Bundle Protocol Specification September 2004 to associate the bundle fragments with a single original bundle. o In addition to the original headers, each bundle fragment MUST contain a fragment header identifying the fragmentary payload's position within the original payload and the length of the original (unfragmented) bundle's payload. Note that there is only one 'level' of fragmentation (as in IP fragmentation). o When original bundle transmission is terminated before the entire payload has been transmitted, the truncated bundle arriving at the receiving bundle agent is not well-formed and cannot be forwarded until it has been transformed into a bundle fragment. Upon forwarding this truncated bundle the receiving bundle agent MUST insert a fragment header, with offset zero, indicating the length of the original bundle's payload and MUST change the payload length in the payload header to the actual length of the payload being forwarded. o When transmission of a fragment is terminated before the fragment's entire payload has been transmitted, the truncated bundle arriving at the receiving bundle agent is again not well-formed. Upon forwarding this truncated bundle the receiving bundle agent MUST retain its fragment header, with offset and original payload length unchanged, and MUST change the payload length in the payload header to the actual length of the payload being forwarded. o Whenever transmission of any bundle is terminated before the bundle's entire payload has been transmitted, the sending bundle agent MUST divide the bundle into two fragmentary bundles: The transmitted fragment, whose payload's length is the number of octets of payload data that the receiving bundle agent is *known* to have received at the moment transmission was terminated. The retained fragment, whose payload's length is equal to the transmitted bundle's payload length less the length of the transmitted fragment's payload. The headers of both fragmentary bundles MUST be identical to the headers of the transmitted bundle except that: If the transmitted bundle was itself a fragment, then the offset in the fragment header of the new retained fragment bundle must be the sum of the payload offset of the transmitted bundle and the length of the transmitted fragment's payload. K. Scott and S. Burleigh Expires - March 2005 [Page 27]
Internet Draft Bundle Protocol Specification September 2004 Otherwise, new fragment headers must be inserted into both the transmitted and retained fragment bundles. Original payload length in each fragment header must be the length of the payload of the transmitted bundle; offset in the fragment header of the transmitted fragment must be zero; offset in the fragment header of the retained fragment must be the length of the transmitted fragment's payload. After fragmentation, the fragments are individually forwarded as distinct bundles: the receiving bundle agent MUST forward the fragment that it received and the sending bundle agent MUST forward its retained fragment. A bundle agent MAY fragment a bundle prior to transmission. In this case, the first fragment MUST contain a fragment header with offset zero. 4.5.2 Bundle Reassembly Each bundle fragment contains a fragment header. The fragment header contains the original bundle's payload length as well as the fragment's payload's offset within the original payload. The fragment's bundle payload header contains the length of the current fragmentary payload. This information is enough for the receiving bundle agent to reconstruct the original payload from the fragments. 4.6 Custodial Retransmission and Release Upon receipt of a custodial signal, the bundle agent may need to fragment the referenced bundle retroactively (in concept if not in fact). This is because some forwarding agent one or more hops downstream from the custodian may have fragmented the bundle, in which case the fragment offset and/or length noted in the signal issued by some further downstream forwarding agent may differ from the fragment offset and/or length (if any) in the bundle that is in the agent's custody. As a result, the bundle agent may temporarily find itself the custodian of two or even three distinct fragmentary bundles in place of the single bundle for which it originally had taken custody; processing of the signal may thereupon terminate the agent's custody of one of these fragmentary bundles. The manner in which this conceptual retroactive fragmentation is accomplished is an implementation matter. Upon receipt of a "Succeeded" custodial signal, the bundle agent MAY release resources allocated to the referenced bundle. Upon receipt of a "Failed" custodial signal, the action taken by the bundle agent is implementation-dependent and may depend on the reason code in the signal. For example, receipt of a "Failed" signal with the "Depleted storage" reason code might cause the bundle to be re- forwarded, possibly on a different route; receipt of a "Failed" K. Scott and S. Burleigh Expires - March 2005 [Page 28]
Internet Draft Bundle Protocol Specification September 2004 signal with the "Redundant transmission" reason code might cause the bundle agent to release resources allocated to the referenced bundle and to revise its algorithm for computing custody transfer timer intervals. Upon expiration of a custody transfer timer: If the bundle itself has expired then it MUST be discarded and processed no further; a bundle status report indicating TTL expiration MUST be generated, destined for the bundle's report-to endpoint ID. Otherwise, the action taken by the bundle agent is implementation- dependent as in the case of receipt of a "Failed" custodial signal. Note, though, that the action taken in this event is not informed by a reason code. 5. Administrative Payloads Administrative payloads are application data units that help to implement some features of bundling, although they are not part of the Bundling protocol itself. Some are sent to the agent administration endpoints of bundle agents, rather than to Bundling application endpoints. An administrative bundle payload comprises one or more administrative records. Two types of administrative records have been defined to date: bundle status reports and custodial signals. Every administrative record consists of an eight-bit record type code, followed by record content in type-specific format. Record type codes are defined as follows: Table 4: Administrative Record Type Codes +---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 0x01 | Bundle status report. | +---------+--------------------------------------------+ | 0x02 | Custodial signal. | +---------+--------------------------------------------+ | (other) | Reserved for future use. | +---------+--------------------------------------------+ The contents of the various types of administrative records are described below. 5.1 Bundle Status Reports One of the delivery options that senders can request is 'bundle K. Scott and S. Burleigh Expires - March 2005 [Page 29]
Internet Draft Bundle Protocol Specification September 2004 status reports.' These reports are intended to provide information about how bundles are progressing through the system, including notices of receipt, TTL expiration, forwarding, custody transfer, and final delivery. Status reports have the following format. Bundle Status Report 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 of bundle 'X' (8 bytes, if +----------------+ + present) +----------------+----------------+----------------+ | Time of Forwarding of bundle 'X' (8 bytes, if +----------------+ present) + +----------------+----------------+----------------+ | Time of Delivery of bundle 'X' (8 bytes, if +----------------+ + present) +----------------+----------------+----------------+ | Time of Deletion of bundle 'X' (8 bytes, if +----------------+ + present) + +----------------+----------------+----------------+ | Region length | Region ID of +----------------+----------------+ + X's source endpoint (variable) / + +----------------+---------------------------------+ / | Admin. Length | Administrative part of +----------------+----------------+ + X's source endpoint (variable) / + +----------------+---------------------------------| / | +----------------+ K. Scott and S. Burleigh Expires - March 2005 [Page 30]
Internet Draft Bundle Protocol Specification September 2004 The fields in a bundle status report are: Status Flags. A 1-byte field containing the following flags: Table 5: 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 | Reporting node has delivered the bundle. | +---------+--------------------------------------------+ | 0x10 | Bundle's TTL expired at reporting node. | +---------+--------------------------------------------+ | 0x20 | Bundle was found to be inauthentic. | +---------+--------------------------------------------+ | 0x40 | Unused. | +---------+--------------------------------------------+ | 0x80 | Report is for a bundle fragment; fragment | | | offset and length fields are present. | +---------+--------------------------------------------+ Fragment offset. If the bundle fragment bit is set in the status flags, then the offset of the payload of the bundle that caused the status report to be generated (within the original payload) is included here. This offset, together with the bundle ID of the original bundle, uniquely identifies this bundle fragment. Fragment length. If the bundle fragment bit is set in the status flags, then the length of the payload of the subject bundle is included here. 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 bundle-received 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 bundle-forwarded 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 K. Scott and S. Burleigh Expires - March 2005 [Page 31]
Internet Draft Bundle Protocol Specification September 2004 NTP timestamp. Time of Delivery (if present). If the bundle-delivered bit is set in the status flags, then a timestamp indicating the time at which the bundle was delivered to the application by the reporting node is included here. The timestamp is 8 bytes long, formatted as an NTP timestamp. Time of Deletion (if present). If the TTL-expired bit or the authentication-failed bit is set in the status flags, then a timestamp indicating the time at which the bundle was discarded by the reporting node is included here. The timestamp is 8 bytes long, formatted as an NTP timestamp. Region length. The length in bytes of the region ID (routing part) of the tuple identifying the application endpoint which was the source of the bundle that caused the status report to be generated. The combination of the reported bundle's send timestamp and source tuple constitutes the bundle identifier. This, together with the fragment offset if present, uniquely identifies the subject bundle to the reportee. Region ID text. The text of the region ID (routing part) of the tuple identifying the subject bundle's source endpoint. Administrative part length. The length in bytes of the administrative part of the tuple identifying the subject bundle's source endpoint. Administrative part text. The text of the administrative part of the tuple identifying the subject bundle's source endpoint. The action that the report-to addressee takes on receipt of a bundle status report is application-specific. 5.2 Custodial Signals Custodial signals are administrative records that effect custodial operations. They are sent to the administration endpoints corresponding to bundle agents that are the custodians of bundles. Custodial signals have the following format. K. Scott and S. Burleigh Expires - March 2005 [Page 32]
Internet Draft Bundle Protocol Specification September 2004 Custodial Signal regarding bundle 'X': +----------------+----------------+----------------+----------------+ | Status Flags | Reason code | Fragment offset (4 bytes, if +----------------+----------------+----------------+----------------+ present) | Fragment length (4 bytes, if ----------------+---------------------------------+-----------------+ present) | Copy of bundle X's Send +----------------+----------------+ + Timestamp (8 bytes) + +----------------+----------------+ | Time of signal (8 bytes) +----------------+----------------+ + + +----------------+----------------+ | Region length | Region ID of +----------------+----------------+----------------+ + X's source endpoint (variable) / + +---------------------------------+ / | Admin. Length | Administrative +----------------+----------------+----------------+ + part of X's source endpoint (variable) / + +----------------+----------------+ / | +----------------+----------------+ K. Scott and S. Burleigh Expires - March 2005 [Page 33]
Internet Draft Bundle Protocol Specification September 2004 The fields in a custodial signal are: Status Flags. A 1-byte field containing the following flags: Table 6: Status Flags for Custodial Signals +---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 0x01 | Custody transfer succeeded. | +---------+--------------------------------------------+ | 0x02 | Unused. | +---------+--------------------------------------------+ | 0x04 | Unused. | +---------+--------------------------------------------+ | 0x08 | Unused. | +---------+--------------------------------------------+ | 0x10 | Unused. | +---------+--------------------------------------------+ | 0x20 | Unused. | +---------+--------------------------------------------+ | 0x40 | Unused. | +---------+--------------------------------------------+ | 0x80 | Report is for a bundle fragment; fragment | | | offset and length fields are present. | +---------+--------------------------------------------+ Reason code. A 1-byte field explaining the value of the "Custody transfer succeeded" flag in the status flags byte. Reason codes are defined as follows: Table 7: Custodial Signal Reason Codes +---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 0x01 | Acceptance of custody. | +---------+--------------------------------------------+ | 0x02 | Delivery to application by non-custodian. | +---------+--------------------------------------------+ | 0x03 | Redundant transmission (reception by the | | | agent that is already current custodian). | +---------+--------------------------------------------+ | 0x04 | Depleted storage. | +---------+--------------------------------------------+ | 0x05 | No known route to destination from here. | +---------+--------------------------------------------+ | 0x06 | No timely contact with next node on route.| +---------+--------------------------------------------+ | (other) | Reserved for future use. | +---------+--------------------------------------------+ K. Scott and S. Burleigh Expires - March 2005 [Page 34]
Internet Draft Bundle Protocol Specification September 2004 Fragment offset. If the bundle fragment bit is set in the status flags, then the offset of the payload of the bundle that caused the custodial signal to be generated (within the original payload) is included here. This offset, together with the bundle ID of the original bundle, uniquely identifies this bundle fragment. Fragment length. If the bundle fragment bit is set in the status flags, then the length of the payload of the subject bundle is included here. This length, together with the fragment offset, is used to track aggregated transfer of custody of the original bundle. Send Timestamp For Reported Bundle. A copy of the send timestamp of the bundle to which the signal applies. Time of Signal. A timestamp indicating the time at which the signal was issued. The timestamp is 8 bytes long, formatted as an NTP timestamp. Region length. The length in bytes of the region ID (routing part) of the tuple identifying the application endpoint which was the source of the bundle to which the signal applies. The combination of the reported bundle's send timestamp and source tuple constitutes the bundle identifier. This, together with the fragment offset if present, uniquely identifies the subject bundle to the receiving custodian. Region ID text. The text of the region ID (routing part) of the tuple identifying the subject bundle's source endpoint. Administrative part length. The length in bytes of the administrative part of the tuple identifying the subject bundle's source endpoint. Administrative part text. The text of the administrative part of the tuple identifying the subject bundle's source endpoint. 6. Services Required of the Convergence Layer 6.1 The Convergence Layer The successful operation of the end-to-end Bundling protocol depends on the operation of underlying protocols at what is termed the "convergence layer"; these protocols accomplish point-to-point communication between bundle agents. A wide variety of protocols may serve this purpose, so long as they provide a defined minimal set of services to Bundling. This convergence layer service specification enumerates those services. K. Scott and S. Burleigh Expires - March 2005 [Page 35]
Internet Draft Bundle Protocol Specification September 2004 6.2 Summary of Convergence Layer Services Each protocol at the convergence layer SHALL provide the following services to Bundling: a) transmitting a bundle to a remote bundle agent identified by administration endpoint ID; b) delivering a bundle that was transmitted by an identified remote bundle agent. 6.3 Summary of Primitives 6.3.1 Requests The convergence layer service SHALL consume the following request primitives: a) Transmit.request 6.3.2 Indications The convergence layer service SHALL deliver the following indication primitives: a) Transmit-Report.indication b) Bundle.indication 6.4 Summary of Parameters NOTE - The availability and use of parameters for each primitive are indicated in section 6.5, where optional parameters are identified with square brackets [thus]. The following definitions apply. 6.4.1 Receiving Bundle Agent Endpoint ID The receiving bundle agent administration endpoint ID parameter shall uniquely identify the administration endpoint of the bundle agent to which a bundle is to be sent. 6.4.2 Sending Bundle Agent Endpoint ID The sending bundle agent administration endpoint ID parameter shall uniquely identify the administration endpoint of the bundle agent from which a bundle was sent. 6.4.3 Bundle The bundle parameter shall indicate the location of a bundle, in the format described in section 3, that has been conveyed or is to be K. Scott and S. Burleigh Expires - March 2005 [Page 36]
Internet Draft Bundle Protocol Specification September 2004 conveyed by the convergence layer protocol. 6.4.4 Bundle length The bundle length parameter shall indicate the length of a bundle that is to be conveyed by the convergence layer protocol. 6.4.5 Bundle authenticity The bundle authenticity parameter shall indicate the convergence protocol's assessment of the authenticity of a received bundle, i.e., whether or not the bundle was indeed sent by the known bundle agent who claimed to have sent it and (if it was) whether or not it was altered after transmission. The value of this parameter shall be one of the following: o Bundle authenticity is asserted. o Bundle authenticity is denied. o Bundle authenticity is unknown. 6.4.6 Transmit length The transmit length parameter shall indicate the number of bytes of payload data that are *known* to have received by the designated receiving bundle agent in the course of the data transmission procedures undertaken by the convergence layer protocol in response to a Transmit.request primitive. 6.5 Convergence Layer Service Primitives 6.5.1 TRANSMIT.REQUEST The Transmit.request primitive shall be used by Bundling to request transmission of a bundle to a neighboring bundle agent. Semantics: Transmit.request shall provide parameters as follows: Transmit.request ( receiving bundle agent endpoint ID, bundle length, bundle) When Generated: Transmit.request MAY be generated by Bundling at any time. Effect on Receipt: Receipt of Transmit.request shall cause the convergence layer protocol to initiate data transmission procedures. In addition, the convergence layer protocol shall deliver a Transmit- Report.indication to Bundling when it has concluded its transmission of the bundle. Additional Comments: The convergence layer adapter is responsible for translating the receiving bundle agent endpoint ID into an appropriate convergence-layer protocol address for transmission. K. Scott and S. Burleigh Expires - March 2005 [Page 37]
Internet Draft Bundle Protocol Specification September 2004 6.5.2 TRANSMIT-REPORT.INDICATION The Transmit-Report.indication primitive shall be used by the convergence layer protocol to report to Bundling on the results of processing a Transmit.request primitive. Semantics: Transmit-Report.indication shall provide parameters as follows: Transmit-Report.indication ( receiving bundle agent endpoint ID, bundle length, bundle, transmit length) When Generated: Transmit-Report.indication SHALL be generated upon the conclusion of data transmission initiated in response to a Transmit.request primitive. The transmit length reported in the indication will be less than the bundle length in (and only in) the event that transmission of the bundle was truncated for some reason peculiar to the convergence layer protocol. Effect on Receipt: Receipt of Transmit-Report.indication SHALL cause the subject bundle to be reactively fragmented as described in section 4.5.1 if and only if transmit length is less than bundle payload length. Otherwise the effect on receipt of Transmit- Report.indication by Bundling is undefined. Additional Comments: None. 6.5.3 BUNDLE.INDICATION The Bundle.indication primitive shall be used by the convergence layer protocol to deliver a received bundle to Bundling for processing. Semantics: Bundle.indication shall provide parameters as follows: Bundle.indication ( sending bundle agent endpoint ID, bundle authenticity, bundle, transmit length) When Generated: Bundle.indication SHALL be generated on arrival of a bundle sent from a remote bundle agent. Effect on Receipt: Receipt of Bundle.indication shall cause Bundling to process the received bundle as described in section 4.2 and (as applicable) section 4.5.1. Additional Comments: The convergence layer adapter is responsible for translating the convergence-layer protocol address of the sender into the sender's bundle agent endpoint ID. Sending bundle agent endpoint K. Scott and S. Burleigh Expires - March 2005 [Page 38]
Internet Draft Bundle Protocol Specification September 2004 ID is required for bundle authentication purposes, e.g., consulting the bundle agent's pre-distributed security certificate to verify the signature on Bundle Authentication header information. 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, July 2004 [3] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial", Warthman Associates, available from http://www.dtnrg.org [4] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992 Acknowledgements The authors gratefully acknowledge the contributions of Dr. Vint Cerf of MCI, Dr. Kevin Fall of Intel Corporation, Adrian Hooke and Leigh Torgerson of the Jet Propulsion Laboratory, Howard Weiss of SPARTA, Inc., and Robert Durst of The MITRE Corporation. Author's Addresses Dr. Keith L. Scott Scott C. Burleigh The MITRE Corporation Jet Propulsion Laboratory 7515 Colshire Drive 4800 Oak Grove Drive McLean, VA 22102 M/S: 179-206 Telephone +1 (703) 883-6547 Pasadena, CA 91109-8099 FAX +1 (703) 883-7142 Telephone +1 (818) 393-3353 Email kscott@mitre.org FAX +1 (818) 354-1075 Email Scott.Burleigh@jpl.nasa.gov Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay Tolerant Networking Research Group (DTNRG) web site is located at http://www.dtnrg.org. K. Scott and S. Burleigh Expires - March 2005 [Page 39]
Internet Draft Bundle Protocol Specification September 2004 Copyright Notice Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Release Statement By submitting this Internet-Draft, the authors accept the provisions of Section 4 of RFC 3667. K. Scott and S. Burleigh Expires - March 2005 [Page 40]
