http://stupid.domain.name/ietf/

One document matched: draft-irtf-dtnrg-bundle-spec-03.txt

Differences from draft-irtf-dtnrg-bundle-spec-02.txt

Internet Draft Bundle Protocol Specification July 2005

Delay Tolerant Networking Research Group K. Scott
Internet Draft The MITRE Corporation
<draft-irtf-dtnrg-bundle-spec-03.txt>
July 2005 S. Burleigh
Expires: January 2006 Jet Propulsion Laboratory

Bundle Protocol Specification

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of BCP
79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This 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).

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 - January 2006 [Page 1]
Internet Draft Bundle Protocol Specification July 2005

Table of Contents

1. Introduction..........................................3
2. Service Description...................................5
2.1 Definitions...........................................5
2.2 Services offered by bundle protocol agents............8
2.3 Summary of Primitives.................................9
2.3.1 Requests..............................................9
2.3.2 Indications...........................................9
2.4 Summary of Parameters.................................9
2.4.1 Destination endpoint ID...............................9
2.4.2 Source endpoint ID....................................9
2.4.3 Report-to endpoint ID.................................9
2.4.4 Priority.............................................10
2.4.5 Delivery Options.....................................10
2.4.6 Lifespan.............................................10
2.4.7 Transmission Token...................................10
2.4.8 Application Data Unit................................10
2.4.9 Registration Token...................................10
2.4.10 Delivery Failure Action..............................10
2.4.11 Bundle creation time.................................11
2.5 Bundle Protocol Service Primitives...................11
2.5.1 TRANSMIT.REQUEST.....................................11
2.5.2 CANCEL.REQUEST.......................................12
2.5.3 REGISTER.REQUEST.....................................12
2.5.4 START-DELIVERY.REQUEST...............................13
2.5.5 STOP-DELIVERY.REQUEST................................13
2.5.6 CHANGE-REGISTRATION.REQUEST..........................14
2.5.7 DEREGISTER.REQUEST...................................14
2.5.8 POLL.REQUEST.........................................14
2.5.9 DATA.INDICATION......................................15
2.5.10 TRANSMITERROR.INDICATION.............................15
2.5.11 TRANSMISSION.INDICATION..............................16
2.5.12 REGISTRATION.INDICATION..............................16
3. Bundle Format........................................16
3.1 Canonical Bundle Header Format.......................17
3.2 Header Processing Flags..............................17
3.3 Bundle Processing Flags..............................17
3.4 Self-Delimiting Numeric Values (SDNV)................17
3.5 Endpoint IDs.........................................19
3.6 Formats of Mandatory Bundle Headers..................20
3.6.1 Primary Bundle Header................................22
3.6.2 Bundle Payload Header................................25
4. Bundle Processing....................................25
4.1 Generation of administrative records.................25
4.2 Bundle transmission requests.........................26
4.3 Bundle dispatching...................................27
4.4 Bundle forwarding....................................27
4.4.1 Forwarding Contraindicated...........................28
4.4.2 Forwarding Failed....................................28
4.5 Bundle expiration....................................29

K. Scott and S. Burleigh Expires - January 2006 [Page 2]
Internet Draft Bundle Protocol Specification July 2005

4.6 Bundle reception.....................................29
4.7 Local bundle delivery................................30
4.8 Bundle Fragmentation.................................31
4.9 Application Data Unit Reassembly.....................32
4.10 Custody transfer.....................................32
4.10.1 Custody acceptance...................................32
4.10.2 Custody release......................................33
4.11 Custody transfer success.............................33
4.12 Custody transfer failure.............................33
4.13 Bundle deletion......................................34
4.14 Discarding a bundle..................................34
5. Administrative record processing.....................34
5.1 Administrative records...............................34
5.1.1 Bundle Status Reports................................35
5.1.2 Custody Signals......................................38
5.2 Generation of administrative records.................41
5.3 Reception of custody signals.........................41
6. Services Required of the Convergence Layer...........41
6.1 The Convergence Layer................................41
6.2 Summary of Convergence Layer Services................41
6.3 Summary of Primitives................................42
6.3.1 Requests.............................................42
6.3.2 Indications..........................................42
6.4 Summary of Parameters................................42
6.4.1 Receiving Endpoint ID................................42
6.4.2 Bundle...............................................42
6.4.3 Bundle length........................................42
6.4.4 Send result..........................................43
6.5 Convergence Layer Service Primitives.................43
6.5.1 SEND.REQUEST.........................................43
6.5.2 SEND-REPORT.INDICATION...............................43
6.5.3 BUNDLE.INDICATION....................................44
7. Security Considerations..............................44
8. IANA Considerations..................................44
9. Normative References.................................44
10. Informative References...............................44

1. Introduction

This document describes version 4 of the Delay Tolerant
Networking (DTN) "bundle" protocol (BP). 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, BP sits at the application layer of some number of
constituent internets, forming a store-and-forward overlay network.
Key capabilities of BP include:

o Custody-based retransmission
o Ability to cope with intermittent connectivity

K. Scott and S. Burleigh Expires - January 2006 [Page 3]
Internet Draft Bundle Protocol Specification July 2005

o Ability to take advantage of scheduled, predicted, and
opportunistic connectivity (in addition to continuous
connectivity)
o Late binding of overlay network endpoint identifiers to
constituent internet addresses

For descriptions of these capabilities and the rationale for the DTN
architecture, see [2]. [3] contains a tutorial-level overview of DTN
concepts.

BP's location within the standard protocol stack is as shown in
Figure 1. BP 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 termed a "convergence layer adapter".
Figure 1 shows three distinct transport and network protocols
(denoted T1/N1, T2,N2, and T3/N3).

+-----------+ +-----------+
| BP app | | BP app |
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BP v | | ^ BP v | | ^ BP v | | ^ BP |
+---------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-+ +-^---------+
| >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ |
+-----------+ +------------+ +-------------+ +-----------+

Figure 1: The bundle protocol sits at the application layer of the
Internet model.

This document describes the format of the protocol data units (called
bundles) passed between entities participating in BP communications.
The entities are referred to as "bundle nodes". This document does
not address:

o Operations in the convergence layer adapters that bundle nodes
use to transport data through specific types of internet.
(However, the document does discuss the services that must be
provided by each adapter at the convergence layer.)

o The bundle routing algorithm.

o Mechanisms for populating the routing or forwarding information

K. Scott and S. Burleigh Expires - January 2006 [Page 4]
Internet Draft Bundle Protocol Specification July 2005

bases of bundle nodes.

2. Service Description

2.1 Definitions

Bundle - - A bundle is a protocol data unit of the DTN bundle protocol.
Multiple instances of the same bundle (the same unit of DTN protocol
data) might exist concurrently in different parts of a network -
possibly in different representations - in the memory local to one or
more bundle nodes and/or in transit between nodes. In the context of
the operation of a bundle node, a bundle is an instance of some
bundle in the network that is in that node's local memory.

Bundle payload - - A bundle payload (or simply "payload") is the
application data whose conveyance to the bundle's destination is the
purpose for the transmission of a given bundle. The terms "bundle
content", "bundle payload", and "payload" are used interchangeably in
this document. The "nominal" payload for a bundle forwarded in
response to a bundle transmission request is the application data
unit whose location is provided as a parameter to that request. The
nominal payload for a bundle forwarded in response to reception of
that bundle is the payload of the received bundle.

Fragment - - A fragment is a bundle whose content is a fragmentary
payload. A fragmentary payload is either the first N bytes or the
last N bytes of some other payload - - either a nominal payload or a
fragmentary payload - - of length M, such that 0 < N < M.

Bundle node - - A bundle node (or, in the context of this document,
simply a "node") is any entity that can send and/or receive bundles.
In the most familiar case a bundle node is instantiated as a single
process running on a general-purpose computer, but in general the
definition is meant to be broader; a bundle node might alternatively
be a thread, an object in an object-oriented operating system, a
special-purpose hardware device, etc. Each bundle node has three
conceptual components, defined below: a "bundle protocol agent", a
set of zero or more "convergence layer adapters", and an "application
agent".

Bundle protocol agent - - The bundle protocol agent (BPA) of a node is
the node component that offers the BP service interface and executes
the procedures of the Bundle Protocol. The manner in which it does
so is wholly an implementation matter. For example, BPA
functionality might be coded into each node individually; it might be
implemented as a shared library that is used in common by any number
of bundle nodes on a single computer; it might be implemented as a
daemon whose services are invoked via inter-process or network
communication by any number of bundle nodes on one or more computers;
it might be implemented in hardware.

K. Scott and S. Burleigh Expires - January 2006 [Page 5]
Internet Draft Bundle Protocol Specification July 2005

Convergence layer adapters - - A convergence layer adapter (CLA) sends
and receives bundles on behalf of the BPA, utilizing the services of
some 'native' internet protocol that is supported in one of the
internets within which the node is functionally located. The manner
in which a CLA sends and receives bundles is wholly an implementation
matter, exactly as described for the BPA.

Application agent - - The application agent (AA) of a node is the node
component that utilizes the BP service interface, presenting requests
and receiving indications, to effect communication for some purpose.
The application agent in turn has two elements, an administrative
element and an application-specific element. The application-
specific element of an AA constructs, requests transmission of,
accepts delivery of, and processes application-specific application
data units; the only interface between the BPA and the application-
specific element of the AA is the BP service interface. The
administrative element of an AA constructs and requests transmission
of administrative records (status reports and custody signals), and
it accepts delivery of and processes any custody signals that the
node receives; in addition to the BP service interface, there is a
(conceptual) private control interface between the BPA and the
administrative element of the AA that enables each to direct the
other to take action under specific circumstances. In the case of a
node that serves simply as a "router" in the overlay network, the AA
may have no application-specific element at all; the application-
specific elements of other nodes' AAs may perform arbitrarily complex
application functions, perhaps even offering multiplexed DTN
communication services to a number of other applications. As with
the BPA, the manner in which the AA performs its functions is wholly
an implementation matter; in particular, the administrative element
of an AA might be built into the library or daemon or hardware that
implements the BPA, and the application-specific element of an AA
might be implemented either in software or in hardware.

Bundle endpoint - - A bundle endpoint (or simply "endpoint") is a set
of zero or more bundle nodes that all identify themselves for BP
purposes by some single text string, called a "bundle endpoint ID"
(or, in this document, simply "endpoint ID"; endpoint IDs are
described in detail in 3.5 below). In the most familiar case a
bundle endpoint comprises a single bundle node (and in fact some
endpoints are not permitted to comprise multiple nodes, as discussed
below), but in general this definition too is meant to be broader.
For example, the motes in a sensor network might constitute a set of
bundle nodes that identify themselves by a single common endpoint ID
and thus form a single bundle endpoint. **Note** too that a given
bundle node might identify itself by multiple endpoint IDs and thus
be a member of multiple bundle endpoints.

Forwarding - When the bundle protocol agent of a node determines that
a bundle must be "forwarded" to an endpoint, it causes the bundle to
be sent to all of the nodes that the bundle protocol agent currently

K. Scott and S. Burleigh Expires - January 2006 [Page 6]
Internet Draft Bundle Protocol Specification July 2005

believes are in the "minimum reception group" of that endpoint. The
minimum reception group of an endpoint may be any one of the
following: (a) ALL of the nodes registered in an endpoint that is
permitted to contain multiple nodes (in which case forwarding to the
endpoint is functionally similar to "multicast" operations in the
Internet, though possibly very different in implementation); (b) ANY
N of the nodes registered in an endpoint that is permitted to contain
multiple nodes, where N is in the range from zero to the cardinality
of the endpoint (in which case forwarding to the endpoint is
functionally similar to "anycast" operations in the Internet); (c)
THE SOLE NODE registered in an endpoint that is not permitted to
contain more than one node (in which case forwarding to the endpoint
is functionally similar to "unicast" operations in the Internet).
The nature of the minimum reception group for a given endpoint can be
determined from the endpoint's ID (again, see 3.5 below): for some
endpoint ID "schemes", the nature of the minimum reception group is
fixed - in a manner that is defined by the scheme - for all endpoints
identified under the scheme; for other schemes, the nature of the
minimum reception group is indicated by some lexical feature of the
"scheme-specific part" of the endpoint ID, in a manner that is
defined by the scheme.

Registration - - A registration is the state machine characterizing a
given node's membership in a given endpoint. Any single registration
must at any time be in one of two states (discussed later): Active,
Passive. Any number of registrations may be concurrently associated
with a given endpoint, and any number of registrations may be
concurrently associated with a given node.

Delivery - - Upon reception, the processing of a bundle that has been
sent to a given node depends on whether or not the receiving node is
registered in the bundle's destination endpoint; if it is, then the
bundle is "delivered" to the node's application agent subject to the
registration characterizing the node's membership in the destination
endpoint. A bundle is considered to have been delivered at a node
subject to a registration as soon as a Data.indication service
primitive containing the bundle's payload has been issued to the
node's application agent in a manner consistent with the state of
that registration and, as applicable, the registration's delivery
failure action.

Deliverability, Abandonment - - A bundle is considered "deliverable"
subject to a registration if and only if (a) the bundle's destination
endpoint is the endpoint with which the registration is associated,
(b) the bundle has not yet been delivered subject to this
registration, and (c) delivery of the bundle subject to this
registration has not been abandoned. To "abandon" delivery of a
bundle subject to a registration is simply to declare it no longer
deliverable subject to that registration; normally only
registrations' registered delivery failure actions cause deliveries
to be abandoned.

K. Scott and S. Burleigh Expires - January 2006 [Page 7]
Internet Draft Bundle Protocol Specification July 2005

Deletion, Discarding - - A bundle protocol agent "discards" a bundle by
simply ceasing all operations on the bundle and functionally erasing
all references to it; the specific procedures by which this is
accomplished are an implementation matter. Bundles are discarded
silently, i.e., the discarding of a bundle does not result in
generation of an administrative record or issuance of a service
interface indication. "Retention constraints" are elements of bundle
state that prevent a bundle from being discarded; a bundle cannot be
discarded while it has any retention constraints. A bundle protocol
agent "deletes" a bundle in response to some anomalous condition by
notifying the bundle's report-to endpoint of the deletion (provided
such notification is warranted; see 4.13 for details) and then
arbitrarily removing all of the bundle's retention constraints,
enabling the bundle to be discarded.

Transmission - - A transmission is a sustained effort by a node's
bundle protocol agent to cause a bundle to be sent to all nodes in
the minimum reception set of some endpoint (which may be the bundle's
destination or may be some intermediate forwarding endpoint) in
response to a transmission request issued by the node's application
agent. Any number of transmissions may be concurrently undertaken by
the bundle protocol agent of a given node.

Custody - - To "accept custody" upon forwarding a bundle is to commit
to retaining a copy of the bundle - possibly re-forwarding the bundle
when the necessity to do so is determined - until custody of that
bundle is "released". Custody of a bundle is released when either
(a) notification is received that some other node has accepted
custody of the same bundle, (b) notification is received that the
bundle has been delivered at some node in the bundle's delivery
endpoint, or (c) the bundle is explicitly deleted for some reason,
such as lifetime expiration. To "refuse custody" of a bundle is to
decide not to accept custody of the bundle. A "custodial node" of a
bundle is a node that has accepted custody of the bundle and has not
yet released that custody. A "custodian" of a bundle is an endpoint
whose membership includes at least one of the bundle's custodial
nodes.

2.2 Services offered by bundle protocol agents

The bundle protocol agent of each node is expected to provide the
following services to the node's application agent:

a) transmitting a bundle to an identified bundle endpoint;
b) canceling a transmission;
c) switching a registration between active and passive state;
d) polling a registration that is in passive state;
e) delivering a received bundle.

K. Scott and S. Burleigh Expires - January 2006 [Page 8]
Internet Draft Bundle Protocol Specification July 2005

2.3 Summary of Primitives

The list of primitives specified here is neither exhaustive or
exclusive. That is, supplementary DTN protocol specifications
(including, but not restricted to, the Bundle Security Protocol) may
expect BP implementations conforming to those protocols to offer
additional primitives.

2.3.1 Requests

The bundle protocol is expected to consume the following request
primitives:

a) Transmit.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 bundle protocol is expected to issue the following indication
primitives:

a) Data.indication;
b) TransmitError.indication
c) Transmission.indication
d) Registration.indication

2.4 Summary of Parameters

NOTE - The availability and use of parameters for each primitive
are indicated in section 2.5. The following definitions apply.

2.4.1 Destination endpoint ID

The destination endpoint ID parameter identifies the bundle endpoint
containing the nodes at which the bundle is to be delivered.

2.4.2 Source endpoint ID

The source endpoint ID parameter identifies the bundle endpoint
containing the node from which the bundle was initially transmitted.

2.4.3 Report-to endpoint ID

The report-to endpoint ID parameter identifies the bundle endpoint to
which any bundle status reports pertaining to the bundle should be

K. Scott and S. Burleigh Expires - January 2006 [Page 9]
Internet Draft Bundle Protocol Specification July 2005

transmitted.

2.4.4 Priority

The priority parameter indicates the urgency with which the bundle is
to be forwarded and delivered. Its value is one of the following:
o Bulk
o Normal
o Expedited

2.4.5 Delivery Options

The delivery options parameter indicates what optional procedures
must be followed when forwarding and delivering the bundle. Its
value is a combination of zero or more of the following:
o Custody transfer required
o Report when bundle received
o Report when bundle custody accepted
o Report when bundle forwarded
o Report when bundle delivered (a.k.a. return receipt requested)
o Report when bundle deleted

2.4.6 Lifespan

The lifespan parameter indicates the length of time, following the
initial transmission of a bundle, after which bundle nodes need no
longer retain or forward the bundle. The sum of the bundle's
creation time and lifespan is its delivery deadline, the moment at
which it is expected to be deleted from the DTN network if it has not
already been delivered at all nodes in the minimum reception set of
its destination endpoint.

2.4.7 Transmission Token

The transmission token parameter identifies a transmission, enabling
it to be distinguished from all other transmissions.

2.4.8 Application Data Unit

The application data unit parameter indicates the location (in memory
or non-volatile storage, a local implementation matter) of the
application data conveyed by the bundle.

2.4.9 Registration Token

The registration token parameter identifies a registration, enabling
it to be distinguished from all other registrations.

2.4.10 Delivery Failure Action

The delivery failure action parameter indicates what action is to be

K. Scott and S. Burleigh Expires - January 2006 [Page 10]
Internet Draft Bundle Protocol Specification July 2005

taken when a bundle that is deliverable subject to the registration
is received at a time when the registration is in the Passive state.
Its value is one of the following:
o Defer delivery of the bundle subject to this registration until
(a) this bundle is the least recently received of all bundles
currently deliverable subject to this registration and (b)
either the registration is polled or else the registration is
in active state.
o Abandon delivery of the bundle subject to this registration.
o Defer delivery as above and, in addition, immediately execute a
specified procedure, where the expression of the procedure to
be executed is a matter of local implementation.

2.4.11 Bundle creation time

The bundle creation time indicates the time, at 1-second granularity,
at which the Transmit.request primitive was received that resulted in
the creation of this bundle. This is the time that appears in the
high-order 4 bytes of the Creation Timestamp discussed in 3.6.1
below.

2.5 Bundle Protocol Service Primitives

The list of parameters specified here for each BP primitive is
neither exhaustive or exclusive. That is, supplementary DTN protocol
specifications (including, but not restricted to, the Bundle Security
Protocol) may expect BP implementations conforming to those protocols
to provide additional parameters with specified primitives.

2.5.1 TRANSMIT.REQUEST

The Transmit.request primitive requests transmission of a bundle to a
destination endpoint.

Semantics: Transmit.request provides parameters as follows:
Transmit.request(source endpoint ID,
destination endpoint ID,
report-to endpoint ID,
priority,
delivery options,
lifespan,
application data unit,
transmission token)

When Presented: Transmit.request may be presented at any time.

Effect on Receipt: Receipt of Transmit.request causes the BPA to
follow the transmission request procedure described in section 4.2;
this will normally result in issuance of a Transmission.indication.
That indication will include the transmission token provided with the
Transmit.request primitive, enabling the AA to monitor and control

K. Scott and S. Burleigh Expires - January 2006 [Page 11]
Internet Draft Bundle Protocol Specification July 2005

the state of the transmission.

Additional Comments: None.

2.5.2 CANCEL.REQUEST

The Cancel.request primitive requests that a bundle transmission
previously initiated in response to a Transmit.request be canceled.

Semantics: Cancel.request provides parameters as follows:
Cancel.request ( transmission token)

When Presented: Cancel.request for a given transmission may be
presented at any time after the BPA has issued a
Transmission.indication indicating initiation of that transmission.
A Cancel.request should be presented if the AA determines that the
referenced transmission must be terminated for some reason.

Effect on Receipt: Receipt of Cancel.request causes the BPA to delete
the bundle created upon initiation of the indicated transmission for
the reason "transmission canceled": the bundle deletion procedure
defined in 4.13 must be followed.

Additional Comments: If the subject bundle has already been
discarded, the request has no effect.

2.5.3 REGISTER.REQUEST

The Register.request primitive requests that the node be declared a
member of a specified endpoint and that received bundles destined for
that endpoint be delivered, under specified conditions.

Semantics: Register.request provides parameters as follows:
Register.request( delivery failure action,
registration token,
destination endpoint ID)

When Presented: Register.request may be presented at any time.

Effect on Receipt: Receipt of Register.request causes the BPA to
initiate a registration, resulting in issuance of a
Registration.indication. The indication includes the registration
token provided with the Register.request primitive, enabling the AA
to monitor and control the state of the registration. The indicated
registration is initially in the Passive state. Whenever the
registration is in the Passive state, the indicated delivery failure
action is to be performed whenever the node receives a bundle that is
deliverable subject to this registration.

Additional Comments: Multiple nodes may be registered - in fact, a
single node may be registered multiple times - at the same endpoint.

K. Scott and S. Burleigh Expires - January 2006 [Page 12]
Internet Draft Bundle Protocol Specification July 2005

Where this is the case, the delivery rules specified for each
individual registration must be observed with regard to bundle
delivery subject to that registration.

Implementations may require that an expiration time additionally be
specified when Register.request is presented, to enable conservation
of resources by automatic termination of registrations as their
timers expire.

2.5.4 START-DELIVERY.REQUEST

The Start-delivery.request primitive requests that the state of the
specified registration be changed from Passive to Active.

Semantics: Start-delivery.request provides parameters as follows:
Start-delivery.request( registration token)

When Presented: Start_delivery.request may be presented at any time
when the indicated registration is in the Passive state.

Effect on Receipt: Receipt of Start-delivery.request causes the state
of the registration to change from Passive to Active. While the
state of a registration is Active, reception of a bundle that is
deliverable subject to this registration causes the bundle to be
delivered automatically as soon as it is the least recently received
bundle that is currently deliverable subject to the registration.

Additional Comments: None.

2.5.5 STOP-DELIVERY.REQUEST

The Stop-delivery.request primitive requests that the state of the
specified registration be changed from Active to Passive.

Semantics: Stop-delivery.request provides parameters as follows:
Stop-delivery.request( registration token)

When Presented: Stop-delivery.request may be presented at any time
when the indicated registration is in the Active state.

Effect on Receipt: Receipt of Stop-delivery.request causes the state
of the registration to change from Active to Passive. While the
state of a registration is Passive, reception of a bundle that is
deliverable subject to this registration causes delivery of the
bundle to be abandoned or deferred in accord with the registration's
current delivery failure action; in the latter case it also causes
the current user-specified delivery failure action, if any, to be
performed.

Additional Comments: None.

K. Scott and S. Burleigh Expires - January 2006 [Page 13]
Internet Draft Bundle Protocol Specification July 2005

2.5.6 CHANGE-REGISTRATION.REQUEST

The Change-registration.request primitive amends the measures to be
taken when a bundle that is deliverable subject to the specified
registration is received by the associated node at a time when the
registration is in the Passive state.

Semantics: Change-registration.request provides parameters as
follows:
Change-registration.request( registration token,
delivery failure action)

When Presented: Change-registration.request may be presented at any
time.

Effect on Receipt: Receipt of Change-registration.request causes the
indicated registrationÆs current delivery failure action to be
superseded such that, from this time onward, the indicated delivery
failure action is invoked whenever a bundle that is deliverable
subject to this registration is received at a time when the
registration is in the Passive state.

Additional Comments: None.

2.5.7 DEREGISTER.REQUEST

The Deregister.request primitive requests that a registration
previously initiated in response to a Register.request be terminated.

Semantics: Deregister.request provides parameters as follows:
Deregister.request( registration token)

When Presented: Deregister.request may be presented at any time.

Effect on Receipt: Receipt of Deregister.request terminates the
indicated registration, causing the node no longer to be a member of
the endpoint with which the indicated registration is associated. At
this time all delivery of bundles subject to this registration is
abandoned.

Additional Comments: Implementations are free to recover any
resources allocated to the delivery of bundles subject to the
terminated registration.

2.5.8 POLL.REQUEST

The Poll.request primitive explicitly requests delivery of a bundle
whose delivery was deferred.

Semantics: Poll.request provides parameters as follows:
Poll.request( registration token)

K. Scott and S. Burleigh Expires - January 2006 [Page 14]
Internet Draft Bundle Protocol Specification July 2005

When Presented: Poll.request may be presented at any time when the
indicated registration is in the Passive state.

Effect on Receipt: Receipt of Poll.request causes immediate delivery
of the least recently received bundle that is deliverable subject to
the indicated registration.

Additional Comments: None.

2.5.9 DATA.INDICATION

The Data.indication primitive effects the delivery of a bundle.

Semantics: Data.indication provides parameters as follows:
Data.indication( source endpoint ID,
destination endpoint ID,
report-to endpoint ID,
priority,
delivery options,
lifespan,
application data unit)

When Issued: Data.indication is issued whenever a bundle is
delivered.

Effect on Receipt: The effect on receipt of a Data.indication whose
application data unit is a custody signal causes the custody signal
reception procedures detailed in section 5.3 to be followed. Beyond
this, the effect on receipt of Data.indication is undefined.

Additional Comments: As noted above, delivery of a bundle subject to
a registration may be initiated either in response to a Poll.request
primitive (when the registration is in the Passive state) or
automatically upon delivery of all previously received deliverable
bundles (when the registration is in the Active state).

2.5.10 TRANSMITERROR.INDICATION

The TransmitError.indication primitive delivers information about
bundle transmission requests that are rejected.

Semantics: TransmitError.indication provides parameters as follows:
TransmitError.indication( transmission token)

When Issued: TransmitError.indication is issued when a
Transmit.request primitive is rejected.

Effect on Receipt: The effect on receipt of TransmitError.indication
is undefined.

K. Scott and S. Burleigh Expires - January 2006 [Page 15]
Internet Draft Bundle Protocol Specification July 2005

Additional Comments: None.

2.5.11 TRANSMISSION.INDICATION

The Transmission.indication primitive notifies the application agent
that a bundle transmission has been initiated in response to a
particular Transmit.request primitive.

Semantics: Transmission.indication provides parameters as follows:
Transmission.indication ( transmission token)

When Issued: Transmission.indication is issued when a requested
bundle transmission is initiated. The transmission token parameter
is the same as that supplied with the antecedent Transmit.request
primitive.

Effect on Receipt: The effect on receipt of Transmission.indication
is undefined.

Additional Comments: None.

2.5.12 REGISTRATION.INDICATION

The Registration.indication primitive notifies the application agent
that a registration has been initiated in response to a particular
Register.request primitive.

Semantics: Registration.indication provides parameters as follows:
Registration.indication ( registration token)

When Issued: RegistrationToken.indication is issued when a requested
registration is initiated. The registration token parameter is the
same as that supplied with the antecedent Register.request primitive.

Effect on Receipt: The effect on receipt of
RegistrationToken.indication is undefined.

Additional Comments: None.

3. Bundle Format

Each bundle is a concatenated sequence of at least two bundle header
structures. The first header in the sequence must be a primary
bundle header. Additional bundle protocol headers of other types may
follow the primary header to support extensions to the Bundle
Protocol, such as the Bundle Security Protocol. The last header in
the sequence must be a payload header. No bundle may have more than
one primary bundle header, and no bundle may have more than one
payload header.

K. Scott and S. Burleigh Expires - January 2006 [Page 16]
Internet Draft Bundle Protocol Specification July 2005

3.1 Canonical Bundle Header Format

Every bundle header of every type other than the primary bundle
header comprises the following elements, in this order:
o Header type code, expressed as an 8-bit unsigned binary
integer.
o Header processing control flags, a set of eight bit-flag
values.
o Header data length, an unsigned integer expressed as an SDNV
(explained below).
o Header-type-specific data fields, whose format and order are
type-specific and whose aggregate length in octets is the value
of the header data length field. All multi-byte header-type-
specific data fields are represented in network byte order.

3.2 Header Processing Flags

The following Boolean processing control flags are present in the
header processing control flags byte of every bundle header other
than the primary bundle header of each bundle:

00000001 - Header must be replicated in every fragment.
00000010 - Transmit status report if header can't be processed.
00000100 - Discard bundle if header can't be processed.
00001000 - Reserved for future use.
00010000 - Reserved for future use.
00100000 - Reserved for future use.
01000000 - Reserved for future use.
10000000 - Reserved for future use.

3.3 Bundle Processing Flags

The following Boolean processing control flags are present only in
the bundle processing control flags byte of the primary bundle header
of each bundle:

00000001 - Bundle is a fragment.
00000010 - Application data unit is an administrative record.
00000100 - Bundle must not be fragmented.
00001000 - Reserved for future use.
00010000 - Reserved for future use.
00100000 - Reserved for future use.
01000000 - Reserved for future use.
10000000 - Reserved for future use.

3.4 Self-Delimiting Numeric Values (SDNV)

The design of the bundle protocol attempts to reconcile minimal
consumption of transmission bandwidth with:
o extensibility to address requirements not yet identified, and
o scalability across a wide range of network scales and payload

K. Scott and S. Burleigh Expires - January 2006 [Page 17]
Internet Draft Bundle Protocol Specification July 2005

sizes.

A key strategic element in the design is the use of self-delimiting
numeric values (SDNVs). The SDNV encoding scheme is closely adapted
from the Abstract Syntax Notation One [ASN1] scheme for encoding
Object Identifier Arcs. An SDNV is a numeric value encoded in N
octets, the last of which has its most significant bit (MSB) set to
zero; the MSB of every other octet in the SDNV must be set to 1. The
value encoded in an SDNV is the unsigned binary number obtained by
concatenating into a single bit string the 7 least significant bits
of each octet of the SDNV.

The following examples illustrate the encoding scheme for various
hexadecimal values.

0xABC : 1010 1011 1100
is encoded as
{100 1010 1} {0 011 1100}
= 10010101 00111100

0x1234 : 0001 0010 0011 0100
= 1 0010 0011 0100
is encoded as
{10 1 0010 0} {0 011 0100}
= 10100100 00110100

0x4234 : 0100 0010 0011 0100
= 100 0010 0011 0100
is encoded as
{1000000 1} {1 00 0010 0} {0 011 0100}
= 10000001 10000100 00110100

0x7F : 0111 1111
= 111 1111
is encoded as
{0 111 1111}
= 01111111

Note: Care must be taken to make sure that the value to be encoded is
(in concept) padded with high-order zero bits to make its bitwise
length a multiple of 7 before encoding. Also note that, while there
is no theoretical limit on the size of an SDNV field, the overhead of
the SDNV scheme is 1/8-th of the bitwise length of the value to be
encoded. In order to encode an 64-bit numeric value, an SDNV field
of 9 octets is required. 128 bits of overhead would be consumed in
encoding a 1024-bit RSA encryption key directly in an SDNV.

An SDNV can be used to represent both very large and very small
integer values. However, SDNV is clearly not the best way to
represent every numeric value. For example, an SDNV is a poor way to
represent an integer whose value typically falls in the range 128 to

K. Scott and S. Burleigh Expires - January 2006 [Page 18]
Internet Draft Bundle Protocol Specification July 2005

255. In general, though, we believe that SDNV representation of
numeric values in bundle headers yields the smallest bundle header
sizes without sacrificing scalability.

3.5 Endpoint IDs

The destinations of bundles are bundle endpoints, identified by text
strings termed "endpoint IDs" (see section 2.1). Each endpoint ID
conveyed in any bundle header takes the form of a Uniform Resource
Identifier (URI; [RFC3986]). As such, each endpoint ID can be
characterized as having this general structure:

As used for the purposes of the bundle protocol, neither the length
of a scheme name nor the length of an SSP may exceed 1023 bytes.

Bundle headers cite a number of endpoint IDs for various purposes of
the bundle protocol. Many, though not necessarily all, of the
endpoint IDs referred to in the headers of a given bundle are
conveyed in the "dictionary" byte array in the bundle's primary
header. This array is simply the concatenation of any number of
null-terminated scheme names and SSPs.

"Endpoint ID references" are used to cite endpoint IDs that are
contained in the dictionary; all endpoint ID citations in the primary
bundle header are endpoint ID references, and other bundle headers
may contain endpoint ID references as well. Each endpoint ID is an
ordered pair of 16-bit unsigned integers:

o The offset, within the dictionary, of the first character of
the referenced endpoint ID's scheme name.

o The offset, within the dictionary, of the first character of
the referenced endpoint ID's SSP.

This encoding enables a degree of header compression: when the source
and report-to of a bundle are the same endpoint, for example, the
text of that endpoint's ID may be cited twice yet appear only once in
the dictionary.

The scheme identified by the <scheme name> in an endpoint ID is a set
of syntactic and semantic rules that fully explain how to parse and
interpret the SSP. The set of allowable schemes is effectively
unlimited. Two schemes are defined by the present document:

o The base scheme "bp0", whose SSPs are all of this form:

//<host identifier>[:<port number>][/<application tag>]

<host identifier> may be either a DNS name or the dotted string

K. Scott and S. Burleigh Expires - January 2006 [Page 19]
Internet Draft Bundle Protocol Specification July 2005

representation of an IP address. <application tag>, where
present, may be any ASCII string. The convergence-layer
protocol to use in forwarding a bundle to an endpoint
identified by an endpoint ID conforming to this scheme is
determined by consulting a forwarding information base, as is
the port number on which to exercise that protocol (except
where the port number is explicitly declared in the SSP). An
endpoint identified by a "bp0" endpoint ID may contain at most
one node.

o The "none" scheme, which is used only in the null endpoint ID
"none:.". The forwarding of a bundle to the null endpoint is
never contraindicated, and the minimum reception set for the
null endpoint is the empty set.

Note that, although the endpoint IDs conveyed in bundle headers are
expressed as URIs, implementations of the BP service interface may
support expression of endpoint IDs in some internationalized manner
(e.g., IRIs; see RFC 3987) in Transmit.request and Data.indication
primitives.

3.6 Formats of Mandatory Bundle Headers

This section describes the formats of the two mandatory headers found
in every bundle. Rules for processing these headers appear in
section 4 of this document.

Note that the list of BP headers specified here is neither exhaustive
or exclusive. That is, supplementary DTN protocol specifications
(including, but not restricted to, the Bundle Security Protocol) may
require that BP implementations conforming to those protocols
construct and process additional headers.

Table 1: Bundle Header Type Codes
+--------------------+------+---------------------------------------+
| Header | Type | Comment |
+====================+======+=======================================+
+--------------------+------+---------------------------------------+
| Bundle Payload | 0x01 | Contains bundle content. |
+--------------------+------+---------------------------------------+
| All other values reserved for future use. |
+--------------------+------+---------------------------------------+

K. Scott and S. Burleigh Expires - January 2006 [Page 20]
Internet Draft Bundle Protocol Specification July 2005

The format of the two mandatory headers is shown in Figure 2 below.

Figure 2: Bundle header formats.
Notes:

(*) The header length field of the Primary Bundle Header is an SDNV
and is therefore variable-length. A one-octet SDNV is shown here for
convenience in representation.

(**) The dictionary length field of the Primary Bundle Header is an

K. Scott and S. Burleigh Expires - January 2006 [Page 21]
Internet Draft Bundle Protocol Specification July 2005

SDNV and is therefore variable-length. A four-octet SDNV is shown
here for convenience in representation.

(***) The fragment offset field of the Primary Bundle Header is
present only if the Fragment flag in the header's processing flags
byte is set to 1. It is an SDNV and is therefore variable-length; a
four-octet SDNV is shown here for convenience in representation.

(****) The total application data unit length field of the Primary
Bundle Header is present only if the Fragment flag in the header's
processing flags byte is set to 1. It is an SDNV and is therefore
variable-length; a four-octet SDNV is shown here for convenience in
representation.

(*****) The header length field of the Payload Header is an SDNV and
is therefore variable-length. A two-octet SDNV is shown here for
convenience in representation.

3.6.1 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 bundle
protocol that constructed this header. The present document
describes version 0x04 of the bundle protocol.

Bundle Processing Control Flags. The Bundle Processing Control Flags
field is a 1-byte field that contains the bundle processing
control flags discussed in section 3.3 above.

Class of Service Flags. The COS Flags byte consists of a 1-bit
custody transfer required switch followed by two (2) bits of
priority and five (5) bits of delivery record request flags.
If the custody transfer required switch is 1 then the sending
node requests that the receiving node accept custody of the
bundle. The two-bit priority field indicates the bundle's
priority, with higher values being of higher priority: 00 =
bulk, 01 = normal, 10 = expedited, 11 is reserved for future
use. The interpretation of the delivery record request flags
is as follows.

K. Scott and S. Burleigh Expires - January 2006 [Page 22]
Internet Draft Bundle Protocol Specification July 2005

Table 2: Delivery Record Request Flag Meanings

+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 00000 | No delivery records requested. |
+---------+--------------------------------------------+
| 00001 | Request reporting of bundle reception. |
+---------+--------------------------------------------+
| 00010 | Request custody acceptance reporting. |
+---------+--------------------------------------------+
| 00100 | Request reporting of bundle forwarding. |
+---------+--------------------------------------------+
| 01000 | Request reporting of bundle delivery. |
+---------+--------------------------------------------+
| 10000 | Request reporting of bundle deletion. |
+---------+--------------------------------------------+

Header Length. The Header Length field is an SDNV that contains the
aggregate length of all remaining fields of the header.

Destination Scheme Offset. The Destination Scheme Offset field
contains the offset within the dictionary byte array of the
scheme name of the endpoint ID of the bundle's destination.

Destination SSP Offset. The Destination SSP Offset field contains
the offset within the dictionary byte array of the scheme-
specific part of the endpoint ID of the bundle's destination.

Source Scheme Offset. The Source Scheme Offset field contains the
offset within the dictionary byte array of the scheme name of
the endpoint ID of the bundle's nominal source.

Source SSP Offset. The Source SSP Offset field contains the offset
within the dictionary byte array of the scheme-specific part
of the endpoint ID of the bundle's nominal source.

Report-to Scheme Offset. The Report-to Scheme Offset field contains
the offset within the dictionary byte array of the scheme name
of the ID of the endpoint to which status reports pertaining
to the forwarding and delivery of this bundle are to be
transmitted.

Report-to SSP Offset. The Report-to SSP Offset field contains the
offset within the dictionary byte array of the scheme-specific
part of the ID of the endpoint to which status reports
pertaining to the forwarding and delivery of this bundle are
to be transmitted.

Custodian Scheme Offset. The "current custodian endpoint ID" of a
primary bundle header identifies an endpoint whose membership

K. Scott and S. Burleigh Expires - January 2006 [Page 23]
Internet Draft Bundle Protocol Specification July 2005

includes the node that most recently accepted custody of the
bundle upon forwarding this bundle header. The Custodian
Scheme Offset field contains the offset within the dictionary
byte array of the scheme name of the current custodian
endpoint ID.

Custodian SSP Offset. The Destination SSP Offset field contains the
offset within the dictionary byte array of the scheme-specific
part of the current custodian endpoint ID.

Creation Timestamp. The creation timestamp is an 8-byte field that,
together with the source endpoint ID and (if applicable) the
fragment offset, serves to identify the bundle. The high-
order four bytes of the timestamp are the bundle's creation
time, a time value - expressed in seconds since the start of
the year 2000 - containing the time that the application data
unit of which this bundle's payload is a part (possibly all)
was received for initial transmission by the source node's
bundle protocol agent. The low-order four bytes of the
timestamp are the latest value (as of the time the ADU was
received) of a monotonically increasing positive integer
counter managed by the source node's bundle protocol agent
that is reset to zero whenever the current time advances by
one second.

Lifetime. The four-byte lifetime field indicates the time at which
the bundle's payload will no longer be useful, encoded as a
number of seconds past the creation time. When the current
time is greater than the creation time plus the lifetime, the
bundle may be deleted from the network.

Dictionary Length. The Dictionary Length field is an SDNV that
contains the length of the dictionary byte array.

Dictionary. The Dictionary field is an array of bytes formed by
concatenating the null-terminated scheme names and SSPs of all
endpoint IDs referenced by any fields in this Primary Header
together with, potentially, other endpoint IDs referenced by
fields in other TBD DTN protocol headers. Its length is given
by the value of the Dictionary Length field.

Fragment Offset. If the Bundle Processing Control Flags of this
Primary header indicate that the bundle is a fragment, then
the Fragment Offset field is an SDNV indicating the offset
from the start of the original application data unit at which
the bytes comprising the payload of this bundle were located.
If not, then the Fragment Offset field is omitted from the
header.

Total Application Data Unit Length. If the Bundle Processing Control
Flags of this Primary header indicate that the bundle is a

K. Scott and S. Burleigh Expires - January 2006 [Page 24]
Internet Draft Bundle Protocol Specification July 2005

fragment, then the Total Application Data Unit Length field is
an SDNV indicating the total length of the original
application data unit of which this bundle's payload is a
part. If not, then the Total Application Data Unit Length
field is omitted from the header.

3.6.2 Bundle Payload Header

The fields of the bundle payload header are:

Header Type. The Header Type field is a 1-byte field that indicates
the type of the header. Header types are listed in Table 1
above.

Header Processing Control Flags. The Header Processing Control Flags
field is a 1-byte field that contains the header processing
control flags discussed in section 3.2 above.

Header Length. The Header Length field is an SDNV that contains the
aggregate length of all remaining fields of the header - - which
is to say, the length of the bundle's payload.

Payload. The application data carried by this bundle.

4. Bundle Processing

The bundle processing procedures mandated in this section and in
section 5 govern the operation of the Bundle Protocol Agent and the
Application Agent administrative element of each bundle node. They
are neither exhaustive or exclusive. That is, supplementary DTN
protocol specifications (including, but not restricted to, the Bundle
Security Protocol) may require that additional measures be taken at
specified junctures in these procedures. Such additional measures
shall not override or supersede the mandated bundle protocol
procedures, except that they may in some cases make these procedures
moot by requiring, for example, that implementations conforming to
the supplementary protocol terminate the processing of a given
incoming or outgoing bundle due to a fault condition recognized by
that protocol.

4.1 Generation of administrative records

All initial transmission of bundles is in response to bundle
transmission requests presented by nodes' application agents. When
required to "generate" an administrative record (a bundle status
report or a custody signal), the bundle protocol agent itself is
responsible for causing a new bundle to be transmitted, conveying
that record. In concept, the bundle protocol agent discharges this
responsibility by directing the administrative element of the node's
application agent to construct the record and request its
transmission as detailed in section 5 below; in practice, the manner

K. Scott and S. Burleigh Expires - January 2006 [Page 25]
Internet Draft Bundle Protocol Specification July 2005

in which administrative record generation is accomplished is an
implementation matter, provided the constraints noted in section 5
are observed.

Notes on administrative record terminology:

a. A "bundle reception status report" is a bundle status report with
the "reporting node received bundle" flag set to 1.

b. A "custody acceptance status report" is a bundle status report
with the "reporting node accepted custody of bundle" flag set to 1.

c. A "bundle forwarding status report" is a bundle status report with
the "reporting node forwarded the bundle" flag set to 1.

d. A "bundle delivery status report" is a bundle status report with
the "reporting node delivered the bundle" flag set to 1.

e. A "bundle deletion status report" is a bundle status report with
the "reporting node deleted the bundle" flag set to 1.

f. A "Succeeded" custody signal is a custody signal with the "custody
transfer succeeded" flag set to 1.

g. A "Failed" custody signal is a custody signal with the "custody
transfer succeeded" flag set to zero.

h. The "current custodian" of a bundle is the endpoint identified by
the current custodian endpoint ID in the bundle's primary header.

4.2 Bundle transmission requests

The steps in processing a Transmit.request primitive are:

Step 1: The source endpoint ID provided with the request must be
either the ID of an endpoint of which the node is a member or else
the null endpoint ID "none:.". If the request fails to satisfy
this condition or any implementation-specific transmission request
policy that is in effect, a TransmitError.indication must be
issued to the application agent and processing of the
Transmit.request must terminate. Otherwise, transmission of the
bundle is initiated and processing proceeds from Step 2.

Step 2: A Transmission.indication must be issued to the application
agent.

Step 3: An outbound bundle must be created per the parameters of the
Transmit.request primitive, with current custodian endpoint ID set
to the null endpoint ID "none:." and with the retention constraint
"Dispatch pending".

K. Scott and S. Burleigh Expires - January 2006 [Page 26]
Internet Draft Bundle Protocol Specification July 2005

Step 4: Processing proceeds from Step 1 of section 4.3.

4.3 Bundle dispatching

The steps in dispatching a bundle are:

Step 1: If the bundle's destination endpoint is an endpoint of which
the node is a member, the bundle delivery procedure defined in 4.7
must be followed.

Step 2: Processing proceeds from Step 1 of section 4.4.

4.4 Bundle forwarding

The steps in forwarding a bundle are:

Step 1: The retention constraint "Forward pending" must be added to
the bundle, and the bundle's "Dispatch pending" retention
constraint must be removed.

Step 2: The bundle protocol agent must determine whether or not
forwarding is contraindicated for any of the reasons listed in
Table 5. In particular:

o The bundle protocol agent must determine which endpoint to
forward the bundle to. The bundle protocol agent may choose
either to forward the bundle directly to its destination
endpoint (if possible) or else to forward the bundle to some
other endpoint for further forwarding. The manner in which
this decision is made may depend on the scheme name in the
destination endpoint ID but in any case is beyond the scope of
this document. If the agent finds it impossible to select an
endpoint to forward the bundle to, then forwarding is
contraindicated for the reason "destination endpoint ID
unintelligible".

o Provided the bundle protocol agent succeeded in selecting an
endpoint to forward the bundle to, the bundle protocol agent
must select the convergence layer adapter(s) whose services
will enable the node to send the bundle to the nodes of the
minimum reception group of the selected endpoint. The manner
in which the appropriate convergence layer adapters are
selected may depend on the scheme name in the destination
endpoint ID but in any case is beyond the scope of this
document. If the agent finds it impossible to select
convergence layer adapters to use in forwarding this bundle,
then forwarding is contraindicated for the reason "destination
endpoint ID unintelligible".

Step 3: If forwarding of the bundle is determined to be
contraindicated for any of the reasons listed in Table 5, then the

K. Scott and S. Burleigh Expires - January 2006 [Page 27]
Internet Draft Bundle Protocol Specification July 2005

Forwarding Contraindicated procedure defined in 4.4.1 must be
followed; the remaining steps of section 4 are skipped at this
time. Otherwise, (a) if the bundle's custody transfer required
switch (in the class of service field) is set to 1 then the
custody transfer procedure defined in section 4.10 must be
followed; (b) processing proceeds from Step 4.

Step 4: The bundle protocol agent must invoke the services of the
selected convergence layer adapter(s) in order to effect the
sending of the bundle to the nodes of the minimum reception group
of the selected endpoint. Determining the time at which the
bundle is to be sent by each convergence layer adapter is an
implementation matter.

Step 5: When all selected convergence layer adapters have informed
the bundle protocol agent that they have concluded their data
sending procedures with regard to this bundle:

o If the "request reporting of bundle forwarding" flag in the
bundle's class of service field is set to 1, then a bundle
forwarding status report must be generated, destined for the
bundle's report-to endpoint ID.

o The bundle's "Forward pending" retention constraint must be
removed.

4.4.1 Forwarding Contraindicated

The steps in responding to contraindication of forwarding for some
reason are:

Step 1: The bundle protocol agent must determine whether or not to
declare failure in forwarding the bundle for this reason. Note -
this decision is likely to be influenced by the reason for which
forwarding is contraindicated.

Step 2: If forwarding failure is declared, then the Forwarding Failed
procedure defined in 4.4.2 must be followed. Otherwise, (a) if
the bundle's custody transfer required switch (in the class of
service field) is set to 1 then the custody transfer procedure
defined in section 4.10 must be followed; (b) when - at some
future time - the forwarding of this bundle ceases to be
contraindicated, processing proceeds from Step 4 of 4.4.

4.4.2 Forwarding Failed

The steps in responding to a declaration of forwarding failure for
some reason are:

Step 1: If the bundle's custody transfer required switch (in the
class of service field) is set to 1, the bundle protocol agent

K. Scott and S. Burleigh Expires - January 2006 [Page 28]
Internet Draft Bundle Protocol Specification July 2005

must generate a "Failed" custody signal for the bundle, destined
for the bundle's current custodian; the custody signal must
contain a reason code corresponding to the reason for which
forwarding was determined to be contraindicated. (Note that
discarding the bundle will not delete it from the network, since
the current custodian still has a copy.)

Step 2: If the bundle's destination endpoint is an endpoint of which
the node is a member, then the bundle's "Forward pending"
retention constraint must be removed. Otherwise the bundle must
be deleted: the bundle deletion procedure defined in 4.13 must be
followed, citing the reason for which forwarding was determined to
be contraindicated.

4.5 Bundle expiration

A bundle expires when the current time is greater than the bundle's
creation time plus its lifetime as specified in the primary bundle
header. Bundle expiration may occur at any point in the processing
of a bundle. When a bundle expires, the bundle protocol agent must
delete the bundle for the reason "lifetime expired": the bundle
deletion procedure defined in 4.13 must be followed.

4.6 Bundle reception

The steps in processing a bundle received from another node are:

Step 1: The retention constraint "Dispatch pending" must be added to
the bundle.

Step 2: If the "request reporting of bundle reception" flag in the
bundle's class of service field is set to 1, then a bundle
reception status report with reason code "No additional
information" must be generated, destined for the bundle's report-
to endpoint ID.

Step 3: If any header in the bundle cannot be processed:

o If the header processing flags in the header indicate that a
status report must be generated in this event, then a bundle
reception status report with reason code "Header
unintelligible" must be generated, destined for the bundle's
report-to endpoint ID.

o If the header processing flags in that header indicate that
the bundle must be discarded in this event, then the bundle
protocol agent must delete the bundle for the reason "Header
unintelligible": the bundle deletion procedure defined in 4.13
must be followed. Otherwise, processing proceeds from Step 4.

Step 4: If the bundle's custody transfer required switch (in the

K. Scott and S. Burleigh Expires - January 2006 [Page 29]
Internet Draft Bundle Protocol Specification July 2005

class of service field) is set to 1 and the bundle has the same
source endpoint ID, creation timestamp, and fragment offset as
another bundle that (a) has not been discarded and (b) currently
has the retention constraint "Custody accepted", then the bundle
protocol agent must generate a "Failed" custody signal for this
bundle with reason code "Redundant reception", destined for this
bundle's current custodian, and must also remove this bundle's
"Dispatch pending" retention constraint. Otherwise, processing
proceeds from Step 5.

Step 5: Processing proceeds from Step 1 of section 4.3.

4.7 Local bundle delivery

The steps in processing a bundle that is destined for an endpoint of
which this node is a member are:

Step 1: If the received bundle is a fragment, the application data
unit reassembly procedure described in 4.9 must be followed. If
this procedure results in reassembly of the entire original
application data unit, processing of this bundle (whose
fragmentary payload has been replaced by the reassembled
application data unit) proceeds from Step 2; otherwise the
retention constraint "Reassembly pending" must be added to the
bundle and all remaining steps of this procedure are skipped.

Step 2: For each of the node's current registrations whose endpoint
ID matches the destination endpoint ID of the bundle:

o If the registration is in the Active state, then the bundle
must be delivered subject to this registration - - that is, a
Data.indication primitive containing the bundle's payload must
be issued to the application agent - - as soon as all previously
received bundles deliverable subject to this registration have
been delivered.

o If the registration is in the Passive state, then the
registration's delivery failure action must be taken (see
2.4.10 above).

Step 3: If the "request reporting of bundle delivery" flag in the
bundle's class of service field is set to 1, then a bundle
delivery status report must be generated, destined for the
bundle's report-to endpoint ID, as soon as the bundle has been
delivered subject to at least one registration. Note that this
status report only states that the payload has been delivered to
the application agent, not that the application agent has
processed that payload.

Step 4: If the bundle's custody transfer required switch (in the
class of service field) is set to 1, the bundle protocol agent

K. Scott and S. Burleigh Expires - January 2006 [Page 30]
Internet Draft Bundle Protocol Specification July 2005

must generate a "Succeeded" custody signal for the bundle,
destined for the bundle's current custodian. The reason code in
the signal must be "Delivery to application by non-custodian".

4.8 Bundle Fragmentation

It may at times be necessary for bundle protocol agents to reduce the
sizes of bundles in order to forward them. This might be the case,
for example, if the endpoint to which a bundle is to be forwarded is
accessible only via intermittent contacts and no upcoming contact is
long enough to enable the forwarding of the entire bundle.

The size of a bundle can be reduced by "fragmenting" the bundle. To
fragment a bundle whose payload is of size M is to replace it with
two "fragments" - - new bundles with the same source endpoint ID and
creation timestamp as the original bundle - - whose payloads are the
first N and the last (M - - N) bytes of the original bundle's payload,
where 0 < N < M. Note that fragments may themselves be fragmented,
so fragmentation may in effect replace the original bundle with more
than two fragments. (However, there is only one 'level' of
fragmentation, as in IP fragmentation.)

Any bundle whose primary header's bundle processing flags do NOT
indicate that it must not be fragmented MAY be fragmented at any
time, for any purpose, at the discretion of the bundle protocol
agent.

Fragmentation shall be constrained as follows:

o The concatenation of the payloads of all fragments produced by
a fragmentation must always be identical to the payload of the
bundle that was fragmented. Note that the payloads of
fragments resulting from different fragmentation episodes, in
different parts of the network, may be overlapping subsets of
the original bundle's payload.

o The header processing flags of each header of each fragment
must be modified to indicate that the bundle is a fragment, and
both fragment offset and total application data unit length
must be provided at the end of each fragment's primary bundle
header.

o All fragments must contain the same headers as the original
bundle, except that (a) the primary headers of the fragments
will differ from that of the fragmented bundle as noted above,
(b) the payload headers of fragments will differ from that of
the fragmented bundle, and (c) any header whose header
processing flags do NOT indicate that the header must be
replicated in every fragment should be replicated only in the
fragment whose fragment offset is zero.

K. Scott and S. Burleigh Expires - January 2006 [Page 31]
Internet Draft Bundle Protocol Specification July 2005

4.9 Application Data Unit Reassembly

If the concatenation - - as informed by fragment offsets and payload
lengths - of the payloads of all previously received fragments with
the same source endpoint ID and creation timestamp as this fragment,
together with the payload of this fragment, forms a byte array whose
length is equal to the total application data unit length in the
fragment's primary header, then:

o This byte array - - the reassembled application data unit - - must
replace the payload of this fragment.

o The "Reassembly pending" retention constraint must be removed
from every other fragment whose payload is a subset of the
reassembled application data unit.

Note: reassembly of application data units from fragments occurs at
destination endpoints as necessary; an application data unit MAY also
be reassembled at some other endpoint on the route to the
destination.

4.10 Custody transfer

The decision as to whether or not to accept custody of a bundle is an
implementation matter which may involve both resource and policy
considerations; however, if the node is not currently a member of any
endpoint whose maximum cardinality is 1 (i.e., the node is not
registered under the ID of some endpoint that is not permitted to
contain multiple nodes) then custody must be refused. If the bundle
protocol agent elects to accept custody of the bundle, then it must
follow the custody acceptance procedure defined in 4.10.1.

4.10.1 Custody acceptance

The retention constraint "Custody accepted" must be added to the
bundle.

If the "request custody acceptance reporting" flag in the bundle's
class of service field is set to 1, a custody acceptance status
report must be generated, destined for the report-to endpoint ID of
the bundle. However, if a bundle reception status report was
generated for this bundle (step 1 of 4.6) then this report should be
generated by simply turning on the "Reporting node accepted custody
of bundle" flag in that earlier report's status flags byte.

The bundle protocol agent must generate a "Succeeded" custody signal
for the bundle, destined for the bundle's current custodian. The
reason code in the signal must be "Acceptance of custody".

The bundle protocol agent must assert the new current custodian for
the bundle. It does so by changing the current custodian endpoint

K. Scott and S. Burleigh Expires - January 2006 [Page 32]
Internet Draft Bundle Protocol Specification July 2005

ID in the bundle's primary header to the endpoint ID of one of the
endpoints of maximum cardinality 1 in which the node is registered.
This may entail appending that endpoint ID's null-terminated scheme
name and SSP to the dictionary byte array in the bundle's primary
header.

The bundle protocol agent may set a custody transfer countdown timer
for this bundle; upon expiration of this timer prior to expiration
of the bundle itself and prior to custody transfer success for this
bundle, the custody transfer failure procedure detailed in section
4.12 must be followed. The manner in which the countdown interval
for such a timer is determined is an implementation matter.

The bundle should be retained in persistent storage if possible.

4.10.2 Custody release

When custody of a bundle is released, the "Custody accepted"
retention constraint must be removed from the bundle and any custody
transfer timer that has been established for this bundle must be
destroyed.

4.11 Custody transfer success

Upon receipt of a "Succeeded" custody signal at a node that is a
custodial node of the bundle identified in the custody signal, the
bundle protocol agent must determine whether or not this signal,
together with all other previously received "Succeeded" signals for
the same bundle (if any), demonstrates that custody of this bundle
has been successfully transferred; the manner in which this
determination is made is an implementation matter. If the BPA
determines that custody has indeed been successfully transferred,
then custody of the node must be released in accord with the
procedures described in 4.10.2.

4.12 Custody transfer failure

Upon receipt of a "Failed" custody signal at a node that is a
custodial node of the bundle identified in the custody signal, the
action taken by the bundle protocol agent is implementation-dependent
and may depend on the nature of the failure. For example, if custody
transfer failure was inferred from expiration of a custody transfer
timer or was asserted by a "Failed" custody signal with the "Depleted
storage" reason code, the bundle protocol agent might choose to re-
forward the bundle, possibly on a different route (section 4.4).
Receipt of a "Failed" custody signal with the "Redundant reception"
reason code, on the other hand, might cause the bundle protocol agent
to handle the failure in the same way as a custody transfer success
(4.11) and to revise its algorithm for computing countdown intervals
for custody transfer timers.

K. Scott and S. Burleigh Expires - January 2006 [Page 33]
Internet Draft Bundle Protocol Specification July 2005

4.13 Bundle deletion

The steps in deleting a bundle are:

Step 1: If the retention constraint "Custody accepted" currently
prevents this bundle from being discarded, then:

o Custody of the node is released in accord with the procedures
described in 4.10.2.

o A bundle deletion status report citing the reason for deletion
must be generated, destined for the bundle's report-to
endpoint ID.

Otherwise, if the "request reporting of bundle deletion" flag in
the bundle's class of service field is set to 1, then a bundle
deletion status report citing the reason for deletion must be
generated, destined for the bundle's report-to endpoint ID.

Step 2: All of the bundle's retention constraints must be removed.

4.14 Discarding a bundle

As soon as a bundle has no remaining retention constraints it may be
discarded.

5. Administrative record processing

5.1 Administrative records

Two types of administrative records have been defined to date: bundle
status reports and custody 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 | Custody signal. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+

The contents of the various types of administrative records are
described below.

K. Scott and S. Burleigh Expires - January 2006 [Page 34]
Internet Draft Bundle Protocol Specification July 2005

5.1.1 Bundle Status Reports

The transmission of 'bundle status reports' under specified
conditions is an option that can be invoked when a Transmit.request
primitive is presented. These reports are intended to provide
information about how bundles are progressing through the system,
including notices of receipt, custody transfer, forwarding, final
delivery, and deletion. They are transmitted to the Report-to
endpoints of bundles.

Status reports have the following format.

Bundle Status Report for bundle 'X':

+----------------+----------------+----------------+----------------+
| Status Flags | Reason code | Fragment offset (*) (if
+----------------+----------------+----------------+----------------+
present) | Fragment length (**) (if present) |
+----------------+----------------+----------------+----------------+
|
+ 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) +
|
+----------------+----------------+----------------+----------------+
|
+ Copy of bundle X's Creation Timestamp (8 bytes) +
|
+----------------+----------------+----------------+----------------+
| Length of X's source endpoint ID (***) | Source
+----------------+---------------------------------+ +
endpoint ID of bundle X (variable) |
+----------------+----------------+----------------+----------------+

Notes:

(*) The Fragment Offset field, if present, is an SDNV and is
therefore variable-length. A three-octet SDNV is shown here for
convenience in representation.

K. Scott and S. Burleigh Expires - January 2006 [Page 35]
Internet Draft Bundle Protocol Specification July 2005

(**) The Fragment Length field, if present, is an SDNV and is
therefore variable-length. A three-octet SDNV is shown here for
convenience in representation.

(***) The source endpoint ID length field is an SDNV and is
therefore variable-length. A three-octet SDNV is shown here for
convenience in representation.

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 received bundle. |
+---------+--------------------------------------------+
| 0x02 | Reporting node accepted custody of bundle.|
+---------+--------------------------------------------+
| 0x04 | Reporting node forwarded the bundle. |
+---------+--------------------------------------------+
| 0x08 | Reporting node delivered the bundle. |
+---------+--------------------------------------------+
| 0x10 | Reporting node deleted the bundle. |
+---------+--------------------------------------------+
| 0x20 | Unused. |
+---------+--------------------------------------------+
| 0x40 | Unused. |
+---------+--------------------------------------------+
| 0x80 | Report is for a fragment; fragment |
| | offset and length fields are present. |
+---------+--------------------------------------------+

Reason code. A 1-byte field explaining the value of the flags in the
status flags byte. The list of status report reason codes
provided here is neither exhaustive nor exclusive;
supplementary DTN protocol specifications (including, but not
restricted to, the Bundle Security Protocol) may define
additional reason codes. Status report reason codes are
defined as follows:

K. Scott and S. Burleigh Expires - January 2006 [Page 36]
Internet Draft Bundle Protocol Specification July 2005

Table 5: Status Report Reason Codes

+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x00 | No additional information. |
+---------+--------------------------------------------+
| 0x01 | Lifetime expired. |
+---------+--------------------------------------------+
| 0x02 | Reserved for future use. |
+---------+--------------------------------------------+
| 0x03 | Transmission canceled. |
+---------+--------------------------------------------+
| 0x04 | Depleted storage. |
+---------+--------------------------------------------+
| 0x05 | Destination endpoint ID unintelligible. |
+---------+--------------------------------------------+
| 0x06 | No known route to destination from here. |
+---------+--------------------------------------------+
| 0x07 | No timely contact with next node on route.|
+---------+--------------------------------------------+
| 0x08 | Header unintelligible. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+

Fragment offset. If the bundle fragment bit is set in the status
flags, then the offset (within the original application data
unit) of the payload of the bundle that caused the status
report to be generated is included here.

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.

Time of Receipt (if present). If the bundle-received bit or custody-
accepted bit is set in the status flags, then a timestamp
indicating the time at which the indicated event occurred at
the reporting endpoint is included here. The timestamp is 8
bytes long, formatted as a POSIX timespec.

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 at the reporting endpoint
is included here. The timestamp is 8 bytes long, formatted as
a POSIX timespec.

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 first delivered at the reporting endpoint

K. Scott and S. Burleigh Expires - January 2006 [Page 37]
Internet Draft Bundle Protocol Specification July 2005

is included here. The timestamp is 8 bytes long, formatted as
a POSIX timespec.

Time of Deletion (if present). If the bundle-deleted bit is set in
the status flags, then a timestamp indicating the time at
which the bundle was deleted at the reporting endpoint is
included here. The timestamp is 8 bytes long, formatted as a
POSIX timespec.

Creation Timestamp of Subject Bundle. A copy of the creation
timestamp of the bundle that caused the status report to be
generated.

Length of Source Endpoint ID. The length in bytes of the source
endpoint ID of the bundle that caused the status report to be
generated.

Source Endpoint ID text. The text of the source endpoint ID of the
bundle that caused the status report to be generated.

5.1.2 Custody Signals

Custody signals are administrative records that effect custody
transfer operations. They are transmitted to the endpoints that are
the current custodians of bundles.

Custody signals have the following format.

Custody Signal regarding bundle 'X':

Notes:

(*) The Fragment Offset field, if present, is an SDNV and is

K. Scott and S. Burleigh Expires - January 2006 [Page 38]
Internet Draft Bundle Protocol Specification July 2005

therefore variable-length. A three-octet SDNV is shown here for
convenience in representation.

(**) The Fragment Length field, if present, is an SDNV and is
therefore variable-length. A three-octet SDNV is shown here for
convenience in representation.

(***) The source endpoint ID length field is an SDNV and is
therefore variable-length. A three-octet SDNV is shown here for
convenience in representation.

The fields in a custody signal are:

Status Flags. A 1-byte field containing the following flags:

Table 6: Status Flags for Custody Signals

+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x01 | Custody transfer succeeded. |
+---------+--------------------------------------------+
| 0x02 | Unused. |
+---------+--------------------------------------------+
| 0x04 | Unused. |
+---------+--------------------------------------------+
| 0x08 | Unused. |
+---------+--------------------------------------------+
| 0x10 | Unused. |
+---------+--------------------------------------------+
| 0x20 | Unused. |
+---------+--------------------------------------------+
| 0x40 | Unused. |
+---------+--------------------------------------------+
| 0x80 | Signal pertains to a 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:

K. Scott and S. Burleigh Expires - January 2006 [Page 39]
Internet Draft Bundle Protocol Specification July 2005

Table 7: Custody Signal Reason Codes

+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x00 | No additional information. |
+---------+--------------------------------------------+
| 0x01 | Acceptance of custody. |
+---------+--------------------------------------------+
| 0x02 | Delivery to application by non-custodian. |
+---------+--------------------------------------------+
| 0x03 | Redundant reception (reception by a node |
| | that is a custodial node for this bundle).|
+---------+--------------------------------------------+
| 0x04 | Depleted storage. |
+---------+--------------------------------------------+
| 0x05 | Destination endpoint ID unintelligible. |
+---------+--------------------------------------------+
| 0x06 | No known route to destination from here. |
+---------+--------------------------------------------+
| 0x07 | No timely contact with next node on route.|
+---------+--------------------------------------------+
| 0x08 | Header unintelligible. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+

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.

Time of Signal. A timestamp indicating the time at which the signal
was issued. The timestamp is 8 bytes long, formatted as a
POSIX timespec.

Creation Timestamp of Subject Bundle. A copy of the creation
timestamp of the bundle to which the signal applies.

Length of Source Endpoint ID. The length in bytes of the source
endpoint ID of the bundle to which the signal applied.

Source Endpoint ID text. The text of the source endpoint ID of the
bundle to which the signal applies.

K. Scott and S. Burleigh Expires - January 2006 [Page 40]
Internet Draft Bundle Protocol Specification July 2005

5.2 Generation of administrative records

Whenever the application agent's administrative element is directed
by the bundle protocol agent to generate an administrative record
with reference to some bundle, the following procedure must be
followed:

Step 1: The administrative record must be constructed. If the
referenced bundle is a fragment, the administrative record must
have the Fragment flag set and must contain the fragment offset
and fragment length fields; the value of the fragment offset field
must be the value of the referenced bundle's fragment offset, and
the value of the fragment length field must be the length of the
referenced bundle's payload.

Step 2: A Transmit.request primitive, requesting transmission of the
administrative record, must be presented to the bundle protocol
agent.

5.3 Reception of custody signals

For each received custody signal that has the Custody Transfer
Succeeded flag set to 1, the administrative element of the
application agent must direct the bundle protocol agent to follow the
custody transfer success procedure in 4.11.

For each received custody signal that has the Custody Transfer
Succeeded flag set to 0, the administrative element of the
application agent must direct the bundle protocol agent to follow the
custody transfer failure procedure in 4.12.

6. Services Required of the Convergence Layer

6.1 The Convergence Layer

The successful operation of the end-to-end bundle protocol depends on
the operation of underlying protocols at what is termed the
"convergence layer"; these protocols accomplish point-to-point
communication between nodes. A wide variety of protocols may serve
this purpose, so long as each convergence layer protocol adapter
provides a defined minimal set of services to the bundle protocol
agent. This convergence layer service specification enumerates those
services.

6.2 Summary of Convergence Layer Services

Each convergence layer protocol adapter is expected to provide the
following services to the bundle protocol agent:

a) sending a bundle to all bundle nodes in the minimum reception
set of the endpoint identified by a specified endpoint ID that

K. Scott and S. Burleigh Expires - January 2006 [Page 41]
Internet Draft Bundle Protocol Specification July 2005

are reachable via the convergence layer protocol;

b) delivering to the bundle protocol agent a bundle that was sent
by a remote bundle node via the convergence layer protocol.

The convergence layer service interface specified here is neither
exhaustive nor exclusive. That is, supplementary DTN protocol
specifications (including, but not restricted to, the Bundle Security
Protocol) may expect convergence layer adapters which serve BP
implementations conforming to those protocols to offer additional
primitives and/or provide additional parameters with the listed
primitives.

6.3 Summary of Primitives

6.3.1 Requests

The convergence layer service is expected to consume the following
request primitives:

a) Send.request

6.3.2 Indications

The convergence layer service is expected to deliver the following
indication primitives:

a) Send-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. The following definitions apply.

6.4.1 Receiving Endpoint ID

The receiving endpoint ID parameter identifies the endpoint
containing the node(s) to which a bundle is to be sent. Note: this
endpoint is not necessarily the final destination of the bundle.

6.4.2 Bundle

The bundle parameter indicates the location of a bundle, in the
format described in section 3, that has been conveyed or is to be
conveyed by the convergence layer protocol.

6.4.3 Bundle length

The bundle length parameter indicates the length of a bundle that has
been conveyed or is to be conveyed by the convergence layer protocol.

K. Scott and S. Burleigh Expires - January 2006 [Page 42]
Internet Draft Bundle Protocol Specification July 2005

6.4.4 Send result

The send result parameter indicates in an implementation-specific
manner the results of processing a Send.request.

6.5 Convergence Layer Service Primitives

6.5.1 SEND.REQUEST

The Send.request primitive requests the sending of a bundle to the
nodes in the minimum reception set of a neighboring endpoint.

Semantics: Send.request provides parameters as follows:
Send.request( receiving endpoint ID,
bundle length,
bundle)

When Presented: Send.request may be presented by the bundle protocol
agent at any time.

Effect on Receipt: Receipt of Send.request is expected to cause the
convergence layer protocol adapter to initiate data sending
procedures; the manner in which it does so may depend on the scheme
name in the receiving endpoint ID. In addition, the convergence
layer adapter is expected to issue a Send-Report.indication to the
bundle protocol agent when it has concluded those procedures.

Additional Comments: None.

6.5.2 SEND-REPORT.INDICATION

The Send-Report.indication primitive reports to the bundle protocol
agent on the results of processing a Send.request primitive.

Semantics: Send-Report.indication provides parameters as follows:
Send-Report.indication ( receiving endpoint ID,
bundle length,
bundle,
send result)

When Issued: Send-Report.indication is expected to be issued upon the
conclusion of the data sending procedures initiated in response to a
Send.request primitive.

Effect on Receipt: The effect on receipt of Send-Report.indication is
undefined.

Additional Comments: None.

K. Scott and S. Burleigh Expires - January 2006 [Page 43]
Internet Draft Bundle Protocol Specification July 2005

6.5.3 BUNDLE.INDICATION

The Bundle.indication primitive delivers a received bundle to the
bundle protocol agent.

Semantics: Bundle.indication provides parameters as follows:
Bundle.indication ( bundle length,
bundle)

When Issued: Bundle.indication is expected to be issued on arrival of
a bundle sent from a remote node.

Effect on Receipt: Receipt of Bundle.indication causes the bundle
protocol agent to process the received bundle as described in section
4.6.

Additional Comments: None.

7. Security Considerations

Security in the bundle protocol is the subject of the Bundle Security
Protocol specification [5]. Inclusion of the Bundle Security
Protocol in any Bundle Protocol implementation is RECOMMENDED. Use
of the Bundle Security Protocol in Bundle Protocol operations is
OPTIONAL.

8. IANA Considerations

The new Uniform Resource Identifier schemes "bp0" and "none", defined
by the Bundle Protocol, will need to be documented.

9. Normative References

[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3978, March 2005.

[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.

[RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifier (URI): Generic Syntax", STD 66, RFC 3986, Jan 2005.

10. 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

K. Scott and S. Burleigh Expires - January 2006 [Page 44]
Internet Draft Bundle Protocol Specification July 2005

[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

[5] S. Symington, et. al., "Bundle Security Protocol Specification,"
draft-irtf-dtnrg-bundle-security-00.txt, June 2005

Acknowledgements

The authors gratefully acknowledge the contributions of Dr. Vint Cerf
of MCI, Dr. Kevin Fall and Michael Demmer of Intel Corporation,
Adrian Hooke and Leigh Torgerson of the Jet Propulsion Laboratory,
Howard Weiss of SPARTA, Inc., Dr. Stephen Farrell of Trinity College
Dublin, and Robert Durst and Susan Symington 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.

Copyright (C) The Internet Society (2005). 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

K. Scott and S. Burleigh Expires - January 2006 [Page 45]
Internet Draft Bundle Protocol Specification July 2005

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 - January 2006 [Page 46]

PAFTECH AB 2003-2026

2026-04-23 23:33:13