One document matched: draft-irtf-dtnrg-bundle-spec-01.txt
Differences from draft-irtf-dtnrg-bundle-spec-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 09:02:22 |