CCSDS Bundle Protocol Specification
CCSDS Bundle Protocol Specification
A concept paper for consideration by the CCSDS Space Internetworking Standards Delay
Tolerant Networking Working Group
Revision History
20090804
Initial draft.
20090921
General comments and graphics update
Table of Contents
1
INTRODUCTION .............................................................................................................................................3
1.1
Purpose and Scope ...............................................................................................................................3
1.2
APPLICABILITY .......................................................................................................................................3
1.3
RATIONALE............................................................................................................................................3
1.4
ORGANIZATION OF THIS RECOMMENDATION .....................................................................................3
1.5
HOW TO READ THIS DOCUMENT .........................................................................................................3
1.6
CONVENTIONS AND DEFINITIONS ........................................................................................................3
1.6.1
Definitions ......................................................................................................................................3
1.7
REFERENCES..........................................................................................................................................6
2
OVERVIEW .....................................................................................................................................................7
2.1
Implementation Architectures .............................................................................................................8
2.2
Services Required of the Convergence Layers......................................................................................9
3
Service Description ......................................................................................................................................10
3.1
Services at the User Interface.............................................................................................................10
The services provided by the bundle protocol shall be made available to Bundle Protocol users and include the
following: .....................................................................................................................................................10
3.2
Summary of Primitives........................................................................................................................10
3.2.1
The Bundling service shall consume the following request primitives: .......................................10
3.2.2
The Bundling service shall deliver the following indication primitives: .......................................10
3.3
Summary of Parameters .....................................................................................................................10
3.3.1
Destination Communications endpoint ID ...................................................................................10
3.3.2
Source Communications endpoint ID ..........................................................................................11
3.3.3
Report-To Communications endpoint ID .....................................................................................11
3.3.4
IsSingleton endpoint ID ................................................................................................................11
3.3.5
Class of Service Parameter ...........................................................................................................11
3.3.6
Delivery Options Parameter .........................................................................................................11
3.3.7
Lifetime parameter ......................................................................................................................11
3.3.8
Application Data Unit Parameter .................................................................................................11
3.3.9
Local Bundle ID.............................................................................................................................12
3.4
Bundling Service Primitives ................................................................................................................13
CCSDS 0.1
1/32
CCSDS Bundle Protocol Specification
3.4.1
Register.request ...........................................................................................................................13
3.4.2
Deregister.request .......................................................................................................................14
3.4.3
ChangeRegistrationState.request ................................................................................................15
3.4.4
Send.request ................................................................................................................................16
3.4.5
Cancel.request .............................................................................................................................17
3.4.6
Poll.request ..................................................................................................................................18
3.4.7
LocalBundleID.indication .............................................................................................................19
3.4.8
BundleDelivery.indication ............................................................................................................20
4
Bundle Processing .......................................................................................................................................21
5
Administrative Record Processing...............................................................................................................21
6
Bundle Message Format..............................................................................................................................22
6.1
Self-Delimiting Numeric Values (SDNVs) ............................................................................................22
6.2
Primary Bundle Block..........................................................................................................................22
6.2.1
Bundle Processing Control Flags ..................................................................................................22
6.2.2
Primary Bundle Header Fields ......................................................................................................24
6.3
Block Processing Control Flags ...........................................................................................................25
6.4
Bundle Payload Block .........................................................................................................................26
6.5
Canonical Bundle Block Format ..........................................................................................................27
7
Security Considerations...............................................................................................................................29
Appendix – TBD/TBR list ......................................................................................................................................30
1. TBD1-1
1.1 Introduction .....................................................................................................................30
2. TBR1-1 1.4 Organization of this Recommendation................................................................................30
3. TBR1-2 1.5 How to read this document .................................................................................................30
4. TBR1-3 1.7 References ...........................................................................................................................30
5. TBR3-1 3.3.4 IsSingletonEID ...................................................................................................................30
6. TBR3-2 3.4.5.6 Additional Comments ....................................................................................................30
7. TBD4-0 4.0 Bundle Processing ................................................................................................................30
8. TBD5-0 5.0 Administrative Record Processing .......................................................................................30
9. TDB6-0 6.0 Bundle Message Format ......................................................................................................30
10. TBD6-1 6.1 SDNVs ...................................................................................................................................30
11. TBR6-2 6.2.2 Primary Bundle Headers Fields .........................................................................................30
12. TBD6-3 6.2.2 Primary Bundle Headers Fields .........................................................................................30
Appendix – RFC5050 ............................................................................................................................................31
CCSDS 0.1
2/32
CCSDS Bundle Protocol Specification
1 INTRODUCTION
1.1 Purpose and Scope
The purpose of this Recommendation is to define the services and protocols that support Delay Tolerant Networking
(DTN) based on the Bundle Protocol of RFC 5050 [B1], the full text of which is provided as an appendix to this document
(TBD1-1). Except as specifically noted in the body of this document, the appendix takes precedence in cases of
inconsistency or ambiguity between the body of this document and the appendix. This definition will allow independent
implementations of the protocols and allow interoperability between space assets and between space and ground
networks.
This Recommendation is intended to be applied to all systems that claim conformance to the CCSDS DTN protocol.
1.2 APPLICABILITY
This Recommendation is designed to be applicable to any kind of space mission or infrastructure which is
communication resource poor and is subject to long latencies and/or temporary network partitions, regardless of
complexity. It is intended that this Recommendation become a uniform standard among all CCSDS Agencies. In addition
this specification exists to support various internetworking protocols both onboard and in transit between ground and
space based assets.
1.3 RATIONALE
The CCSDS believes it is important to document the rationale underlying the recommendations chosen, so that future
evaluations of proposed changes or improvements will not lose sight of previous decisions. The concept and rationale
for the use of a bundle protocol in space links may be found in references [B3] and [B4].
1.4 ORGANIZATION OF THIS RECOMMENDATION
[TBR1-1]
1.5 HOW TO READ THIS DOCUMENT
[TBR1-2]
1.6 CONVENTIONS AND DEFINITIONS
1.6.1
Definitions
1.6.1.1 Definitions from Open Systems Interconnection (OSI) Service Definition Conventions
This Recommendation makes use of a number of terms defined in reference [6]. The use of those terms in this
Recommendation shall be interpreted in a generic sense, i.e., in the sense that those terms are generally applicable to
any of a variety of technologies that provide for the exchange of information between real systems. Those terms are:




Indication;
Primitive;
Request;
Response.
CCSDS 0.1
3/32
CCSDS Bundle Protocol Specification
1.6.1.2 Terms Defined in This Recommendation
Bundle - A bundle is a protocol data unit of the DTN bundle protocol. Each bundle comprises a sequence of two or
more "blocks" of protocol data, which serve various purposes. 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 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 generalpurpose 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 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 Section 4.4 below). The special case of an endpoint that never
contains more than one node is termed a "singleton" endpoint; every bundle node must be a member of at least one
singleton endpoint. Singletons are the most familiar sort of endpoint, but in general the endpoint notion is meant to be
broader. For example, the nodes 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.
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.
Bundle protocol agent (BPA) - The bundle protocol agent of a node is the node component that offers the BP services
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.
Application agent (AA) - The application agent (AA) of a node is the node component that utilizes the BP services 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
CCSDS 0.1
4/32
CCSDS Bundle Protocol Specification
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.
Convergence layer adapters (CLA) - A convergence layer adapter 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.
Custody - To "accept custody" upon forwarding a bundle is to commit to retaining a copy of the bundle -- possibly reforwarding the bundle when necessary -- until custody of that bundle is "released". Custody of a bundle whose
destination is a singleton endpoint 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 the (sole) node
registered in the bundle's destination endpoint; or (c) the bundle is explicitly deleted for some reason, such as lifetime
expiration. The condition(s) under which custody of a bundle whose destination is not a singleton endpoint may be
released are not defined in this specification. 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 a singleton endpoint whose sole member is one of the bundle's custodial nodes.
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. "Retention constraints" are elements of the bundle state that prevent a bundle from being discarded; a bundle
cannot be discarded while it has any unsatisfied 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 Section 5.13 for details) and then arbitrarily removing all of the bundle's retention
constraints, enabling the bundle to be discarded.
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, and if the payload of the bundle is nonfragmentary (possibly as a result of successful payload reassembly from fragmentary payloads, including the original
payload of the received bundle), then the bundle is normally "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 the application data unit that is the payload of the bundle,
together with the value of the bundle's "Acknowledgement by application is requested" flag and any other relevant
metadata (an implementation matter), has been presented 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.
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 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
CCSDS 0.1
5/32
CCSDS Bundle Protocol Specification
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); or (c) THE SOLE NODE registered in a singleton endpoint (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 Section 4.4 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.
Fragment - A fragment is a bundle whose payload block contains 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.
Registration - A registration is the state machine characterizing a given node's membership in a given endpoint. 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. Any single registration must at any time be in one of two states: Active or
Passive. A registration always has an associated "delivery failure action", the action that is to be taken when a bundle
that is "deliverable" (see below) subject to that registration is received at a time when the registration is in the Passive
state. Delivery failure action must be one of the following:
•
•
defer "delivery" (see below) 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 the Active state; or
"abandon" (see below) delivery of the bundle subject to this registration.
An additional implementation-specific delivery deferral procedure may optionally be associated with the registration.
While the state of a registration is Active, reception of a bundle that is deliverable subject to this registration must cause
the bundle to be delivered automatically as soon as it is the least recently received bundle that is currently deliverable
subject to the registration. While the state of a registration is passive, reception of a bundle that is deliverable subject
to this registration must cause delivery of the bundle to be abandoned or deferred as mandated by the registration's
current delivery failure action; in the latter case, any additional delivery deferral procedure associated with the
registration must also be performed.
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 group 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.
1.7 REFERENCES
[B1] S. Burleigh and K. Scott. Bundle Protocol Specification. RFC 5050, November 2007.
[B2] Procedures Manual for the Consultative Committee for Space Data Systems. CCSDS A00.0-Y-9. Yellow
Book. Issue 9. Washington, D.C.: CCSDS, November 2003.
[B3] DRAFT SIS-DTN Green Book, CCSDS nnnnn-G. [Not yet published.TBR1-3]
[B4] V. Cerf et. al., "Delay-Tolerant Network Architecture", RFC 4838, April 2007.
CCSDS 0.1
6/32
CCSDS Bundle Protocol Specification
2 OVERVIEW
Delay Tolerant Networking (DTN) is an end-to-end network service providing communications in and/or through
environments characterized by:




Intermittent connectivity which limits resource availability
Variable delays which may be large and irregular
High bit error rates
Asymmetric and simplex links
To provide the end-to-end network services the DTN protocols, also known as bundle protocols, sit above the link or
transport layers of the constituent internets, forming a store-and-forward overlay network. Key capabilities of the
bundling protocols include:





Ability to cope with intermittent connectivity
Ability to take advantage of scheduled and opportunistic connectivity (in addition to ‘always up’ connectivity)
Custody Transfer
End-to-end security
Late binding of names to addresses
For descriptions of these capabilities and rationale for the DTN architecture, see [B3].
Figure 1: The bundling protocols sit at or above the link layer.
The bundle protocols sit above the link or transport layers of networks as shown in Figure 1. Figure shows the Bundle
Protocol above the transport layer in a TCP/IP implementation on the right. For a space borne application
communicating over CCSDS, the Bundle Protocol would be over the link layer. Bundling uses the ‘native’ local protocols
for communications within a given network. The interface between the common bundle protocol and a specific
internetwork protocol suite is known as a convergence layer.
This document describes the format of the messages (called bundles) passed between entities participating in bundle
communications. The entities are referred to as bundle nodes, and the applications executing the bundle protocols are
called bundle daemons. This document does not address:
CCSDS 0.1
7/32
CCSDS Bundle Protocol Specification
The convergence layers that bundle daemons used to transport data through a specific Internet, or the bundle daemon
to convergence layer API.
The bundle routing algorithm or mechanisms for populating the routing or forwarding information bases of bundle
nodes.
2.1 Implementation Architectures
The definitions above are intended to enable the bundle protocol’s operations to be specified in a manner that
minimizes bias toward any particular implementation architecture. A graphical representation of a bundle node
following the above definition is:
Bundle Node
Application
Agent
CL Adaptor
Bundle Protocol
Agent
CL Adaptor
CL Adaptor
Figure 2: Graphical representation of a bundle node.
Note here that there is ONE application agent per conceptual bundle node. That application may register in multiple
endpoints (may provide multiple endpoint identifiers to the bundle protocol agent, requesting delivery of bundles to any
of those endpoints).
To illustrate the range of interoperable implementation models that might conform to this specification, four example
architectures are briefly described below.
1. Bundle protocol application server
A single bundle protocol application server, constituting a single bundle node, runs as a daemon process on
each computer. The daemon's functionality includes all functions of the bundle protocol agent, all
convergence layer adapters, and both the administrative and application-specific elements of the application
agent. The application-specific element of the application agent functions as a server, offering bundle protocol
service over a local area network: it responds to remote procedure calls from application processes (on the
same computer and/or remote computers) that need to communicate via the bundle protocol. The server
supports its clients by creating a new (conceptual) node for each one and registering each such node in a
client-specified endpoint. The conceptual nodes are managed by the server function as clients' bundle
protocol service access points.
2. Peer application nodes
Any number of bundle protocol application processes, each one constituting a single bundle node, run in adhoc fashion on each computer. The functionality of the bundle protocol agent, all convergence layer adapters,
CCSDS 0.1
8/32
CCSDS Bundle Protocol Specification
and the administrative element of the application agent is provided by a library to which each node process is
dynamically linked at run time. The application-specific element of each node's application agent is nodespecific application code.
3. Sensor network nodes
Each node of the sensor network is the self-contained implementation of a single bundle node. All functions
of the bundle protocol agent, all convergence layer adapters, and the administrative element of the
application agent are implemented in simplified form in Application-Specific Integrated Circuits (ASICs), while
the application-specific element of each node's application agent is implemented in a programmable
microcontroller. Forwarding is rudimentary: all bundles are forwarded on a hard-coded default route.
4. Dedicated bundle router
Each computer constitutes a single bundle node that functions solely as a high-performance bundle forwarder.
Many standard functions of the bundle protocol agent, the convergence layer adapters, and the administrative
element of the application agent are implemented in ASICs, but some functions are implemented in a highspeed processor to enable reprogramming as necessary. The node's application agent has no applicationspecific element. Substantial non-volatile storage resources are provided, and arbitrarily complex forwarding
algorithms are supported.
2.2 Services Required of the Convergence Layers
Each convergence layer protocol adapter is expected to provide the following services to the bundle protocol agent:
•
sending a bundle to all bundle nodes in the minimum reception group of the endpoint identified by a specified
endpoint ID that are reachable via the convergence layer protocol; and
•
delivering a bundle to the bundle protocol agent 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 [BSP]) may expect convergence
layer adapters that serve BP implementations conforming to those protocols to provide additional services.
CCSDS 0.1
9/32
CCSDS Bundle Protocol Specification
3 Service Description
3.1 Services at the User Interface
The services provided by the bundle protocol shall be made available to Bundle Protocol users and include
the following:
a)
inititiate a registration (registering a node in an endpoint);
b)
terminate a registration;
c)
switch a registration between Active and Passive states;
d)
transmit a bundle to an identified bundle endpoint;
e)
cancel a transmission;
f)
poll a registration that is in the passive state;
g)
deliver a received bundle.
The DTN entity shall be implemented such that virtually any number of transactions may be conducted concurrently in
various stages of transmission or reception at a single DTN entity.
NOTE – To clarify: the implementation must be able to accept a primitive, and thereupon initiate a new transaction,
prior to the completion of previously initiated transactions. The requirement for concurrent transaction support
therefore does not necessarily imply that the implementation must be able to begin initial transmission of data for one
transaction while initial transmission of file data for one or more other transactions is still in progress. (But neither is
support for this functional model precluded.)
3.2 Summary of Primitives
3.2.1 The Bundling service shall consume the following request primitives:
Register.request
Deregister.request
ChangeRegistrationState.request
Send.request
Cancel.request
Poll.request
3.2.2 The Bundling service shall deliver the following indication primitives:
LocalBundleID.indication
BundleDelivery.indication
3.3 Summary of Parameters
NOTE
–
The availability and use of parameters for each primitive are enumerated in section 3.4, where optional
parameters are identified with square brackets [thus]. The following definitions apply.
3.3.1 Destination Communications endpoint ID
The destination communications endpoint ID parameter identifies the communications endpoint to which the bundle is
to be sent. One can think of a DTN communications endpoint as an application, but in general the definition is meant to
CCSDS 0.1
10/32
CCSDS Bundle Protocol Specification
be broader. For example, elements of a sensor network might register with a local bundle agent to receive information
about certain topics of interest. A communications endpoint could thus refer to a process running on a general-purpose
processor, a special-purpose hardware device, an object in an object-oriented operating system, etc.
3.3.2 Source Communications endpoint ID
The source communications endpoint ID parameter shall uniquely identify the communications endpoint from which the
bundle was sent.
3.3.3 Report-To Communications endpoint ID
The report-to communications endpoint ID parameter shall identify the communications endpoint to which any bundle
status reports pertaining to the bundle, including end-to-end acknowledgments, should be sent.
3.3.4 IsSingleton endpoint ID
TBR3-1
3.3.5 Class of Service Parameter
The class of service parameter shall indicate which class of standard procedures shall be followed when transmitting and
delivering the bundle. Its value shall be one of the following:



Bulk
Normal
Expedited
3.3.6 Delivery Options Parameter
The delivery options parameter shall indicate what optional procedures shall additionally be followed when transmitting
and delivering the bundle. Its value shall be a combination of zero or more of the following:







Custody transfer
Do-not-fragment
End-to-end return receipt
Deletion receipt
Delivery records for bundle received events
Delivery records for bundle transmitted events
Delivery records for custody taken events
3.3.7 Lifetime parameter
The lifetime parameter shall indicate the length of time, following initial creation time of a bundle, after which bundling
agents may discard the bundle. The sum of the bundle’s transmission time and lifetime is its delivery deadline, the
moment at which it may be deleted from the network if it has not already been delivered to its destination
communications endpoint.
3.3.8 Application Data Unit Parameter
The application data unit parameter shall indicate the location (in memory or non-volatile storage, a local
implementation matter) of the application data conveyed by the bundle.
CCSDS 0.1
11/32
CCSDS Bundle Protocol Specification
3.3.9 Local Bundle ID
The Local Bundle ID parameter identifies a particular bundle within the context of a given bundle agent. This is provided
to the user of the bundle service on submitting a bundle for transmission so that the user may later reference that
bundle in other requests, such as cancellation. The form of this identifier is entirely implementation-specific and should
not be confused with the global Bundle ID field used to uniquely identify bundles in the network.
CCSDS 0.1
12/32
CCSDS Bundle Protocol Specification
3.4 Bundling Service Primitives
3.4.1
Register.request
3.4.1.1 Function
The Register.request primitive shall be used to notify the Bundling agent of the start of a period of passive bundle
reception.
3.4.1.2 Semantics
Register.request shall provide parameters as follows:
Register.request
(delivery failure action,
destination communications endpoint id)
3.4.1.3 When Generated
Register.request may be generated by any Bundling application at any time.
3.4.1.4 Effect on Receipt
Receipt of Register.request shall cause the Bundling agent to deliver to the Bundling application any bundles
destined for the application that (a) arrived in the past and were deferred or (b) arrive during the new period of passive
bundle reception.
3.4.1.5 Additional Comments
Only one registration can be active for a given application and a given endpoint identifier at a time. That is, a given
application may not register the same destination communications endpoint ID multiple times.
CCSDS 0.1
13/32
CCSDS Bundle Protocol Specification
3.4.2
Deregister.request
3.4.2.1 Function
The Deregister.request primitive shall be used to notify the Bundling agent of the end of a period of active or
passive bundle reception.
3.4.2.2 Semantics
Deregister.request shall provide parameters as follows:
Deregister.request
(destination communications endpoint id)
3.4.2.3 When Generated
Deregister.request may be generated by any Bundling application at any time when the application has an active
registration.
3.4.2.4 Effect on Receipt
Receipt of Deregister.request shall cause the Bundling agent to dispatch any subsequently arriving bundles
destined for the registered endpoint in accord with the delivery failure action specified by the most recent
Register.request primitive issued by this application for that endpoint.
3.4.2.5 Additional Comments
Multiple applications may be members of the same endpoint. One application deregistering from the endpoint does not
affect other applications’ delivery or delivery failure behavior.
CCSDS 0.1
14/32
CCSDS Bundle Protocol Specification
3.4.3
ChangeRegistrationState.request
3.4.3.1 Function
The ChangeRegistrationState.request primitive shall be used to notify the Bundling agent of a desired change in
the bundle reception state.
3.4.3.2 Semantics
ChangeRegistrationState.request shall provide parameters as follows:
ChangeRegistrationState.request
(destination communications endpoint id,
registrationState)
3.4.3.3 When Generated
ChangeRegistrationState.request may be generated by any Bundling application at any time when it has one or
more active registrations.
3.4.3.4 Effect on Receipt
Receipt of ChangeRegistrationState.request shall cause the Bundling agent to change the state of the
registration to the requested state, if possible.
3.4.3.5 Additional Comments
None.
CCSDS 0.1
15/32
CCSDS Bundle Protocol Specification
3.4.4
Send.request
3.4.4.1 Function
The Send.request primitive shall be used by the application to request transmission of an application data unit from
the source communications endpoint to a destination communications endpoint.
3.4.4.2 Semantics
Send.request shall provide parameters as follows:
Send.request
(source communications endpoint ID,
destination communications endpoint ID,
report-to communications endpoint ID,
class-of-service,
destination is a singleton,
delivery options,
lifetime,
application data unit)
3.4.4.3 When Generated
Send.request is generated by the source Bundling application at any time.
3.4.4.4 Effect on Receipt
Receipt of Send.request shall cause the Bundling agent to initiate bundle transmission procedures.
3.4.4.5 Additional Comments
None.
CCSDS 0.1
16/32
CCSDS Bundle Protocol Specification
3.4.5
Cancel.request
3.4.5.1 Function
The Cancel.request primitive shall be used by the application to request termination of transmission of an
application data unit for which the application previously requested transmission.
3.4.5.2 Semantics
Cancel.request shall provide parameters as follows:
Cancel.request (LocalBundleID)
3.4.5.3 When Generated
Cancel.request is generated by the application at any time after requesting transmission of a bundle.
3.4.5.4 Effect on Receipt
Receipt of Cancel.request shall cause the Bundling agent to stop attempting to transmit and to discard the target
bundle, if possible.
3.4.5.5 Additional Comments
If the bundle has already been transmitted, there is no obligation on the sending bundle agent to take any further
action. It is an implementation matter whether a bundle that is in the process of being transmitted when a
Cancel.request is received is terminated.
CCSDS 0.1
17/32
CCSDS Bundle Protocol Specification
3.4.6
Poll.request
3.4.6.1 Function
The Poll.request primitive shall be used by the application to request immediate delivery of a bundle to a
registration that is in the active mode.
3.4.6.2 Semantics
Poll.request shall provide parameters as follows:
Poll.request
(destination communications endpoint id)
3.4.6.3 When Generated
Poll.request is generated by the application at any time when a registration is in active mode.
3.4.6.4 Effect on Receipt
3.4.6.5 Additional Comments
TBR3-2
3.4.6.6 Function
The Poll.request primitive shall be used to request immediate delivery of a bundle.
3.4.6.7 Semantics
Poll.request shall provide parameters as follows:
Poll.request
(destination communications endpoint id)
3.4.6.8 When Generated
Poll.request is generated by any Bundling application at any time when not currently in a period of passive bundle
reception.
3.4.6.9 Effect on Receipt
Receipt of Poll.request shall cause the Bundling Agent to deliver to the Bundling application the least recently
received bundle, destined for the destination communications endpoint id, for which delivery was deferred.
3.4.6.10 Additional Comments
None.
CCSDS 0.1
18/32
CCSDS Bundle Protocol Specification
3.4.7
LocalBundleID.indication
3.4.7.1 Function
The LocalBundleID.indication primitive shall be used to provide the application a reference to a particular bundle
of which the application requested transmission.
3.4.7.2 Semantics
LocalBundleID.indication shall provide parameters as follows:
LocalBundleID.indication
(local bundle ID)
3.4.7.3 When Generated
LocalBundleID.indication shall be generated by a Bundle agent once it has consumed a send.request from the
application.
3.4.7.4 Effect on Receipt
The effect on receipt of LocalBundleID.indication by a Bundling application is undefined.
3.4.7.5 Additional Comments
On receiving this notice the sending application may, for example, release resources of its own that are allocated to the
application being transmitted, or remember the local bundle ID so that transmission can be canceled in the future if
necessary.
CCSDS 0.1
19/32
CCSDS Bundle Protocol Specification
3.4.8
BundleDelivery.indication
3.4.8.1 Function
The BundleDelivery.indication primitive shall be used to indicate to the bundle service user that a bundle has
been delivered to the application.
3.4.8.2 Semantics
BundleDelivery.indication shall provide parameters as follows:
BundleDelivery.indication
(header information,
Application data unit)
3.4.8.3 When Generated
BundleDelivery.indication shall be generated by a Bundle agent on reception of bundles destined for passive
registrations or in response to poll requests.
3.4.8.4 Affect on Receipt
Defined by the application
3.4.8.5 Additional Comments
None
CCSDS 0.1
20/32
CCSDS Bundle Protocol Specification
4 Bundle Processing
[TBD4-0]
Per section 5 of RFC5050.
5 Administrative Record Processing
[TBD5-0]
Per section 6 of RFC5050
CCSDS 0.1
21/32
CCSDS Bundle Protocol Specification
6 Bundle Message Format
[TBD6-0]
Effectively section 4 of RFC5050
6.1 Self-Delimiting Numeric Values (SDNVs)
[TBD6-1]
6.2 Primary Bundle Block
The DTN protocols use a chained header format reminiscent of IPv6 headers. Each bundle header consists of a number
of blocks, and contains at least a primary bundle block. Other blocks types can be chained after the primary block to
support additional functionality such as authentication, bundle identification of the transmitting endpoint, etc.
Figure 3: Primary Bundle Block Format.
6.2.1 Bundle Processing Control Flags
The bundle processing control flags field in the primary bundle block of each bundle is an SDNV; the value encoded in
this SDNV is a string of bits used to invoke selected bundle processing control features. The significance of the value in
each currently defined position of this bit string is described here. Note that in the figure and descriptions, the bit label
numbers denote position (from least significant ('0') to most significant) within the decoded bit string, and not within the
representation of the bits on the wire. This is why the descriptions in this section and the next do not follow standard
CCSDS 0.1
22/32
CCSDS Bundle Protocol Specification
RFC conventions with bit 0 on the left; if fields are added in the future, the SDNV will grow to the left, and using this
representation allows the references here to remain valid.
Bits 20-14
Status
Report
Bits 13-7
Class of
Service
Bits 6-0
General
Use
Processing Flags
Figure 4: Bundle Processing Control Flags Bit Layout
The bits in positions 0 through 6 are flags that characterize the bundle as follows:
0 -- Bundle is a fragment.
1 -- Application data unit is an administrative record.
2 -- Bundle must not be fragmented.
3 -- Custody transfer is requested.
4 -- Destination endpoint is a singleton.
5 -- Acknowledgement by application is requested.
6 -- Reserved for future use.
The bits in positions 7 through 13 are used to indicate the bundle's class of service. The bits in positions 7 and 8
constitute a two-bit priority field indicating the bundle's priority, with higher values being of higher priority: 00 = bulk,
01 = normal, 10 = expedited, 11 is reserved for future use. Within this field, bit 8 is the most significant bit. The bits in
positions 9 through 13 are reserved for future use and are represented as follows:
7 -8 -9 -10 -11 -12 -13 --
Least significant bit in priority field (bits 7 and 8).
Most significant bit in priority field (bits 7 and 8).
Reserved for future use.
Reserved for future use.
Reserved for future use.
Reserved for future use.
Reserved for future use.
The bits in positions 14 through 20 are status report request flags. These flags are used to request status reports as
follows:
14 -15 -16 -17 --
Request reporting of bundle reception.
Request reporting of custody acceptance.
Request reporting of bundle forwarding.
Request reporting of bundle delivery.
CCSDS 0.1
23/32
CCSDS Bundle Protocol Specification
18 -- Request reporting of bundle deletion.
19 -- Reserved for future use.
20 -- Reserved for future use.
If the bundle processing control flags indicate that the bundle's application data unit is an administrative record, then
the custody transfer requested flag must be zero and all status report request flags must be zero. If the custody transfer
requested flag is 1, then the sending node requests that the receiving node accept custody of the bundle. If the bundle's
source endpoint ID is "dtn:none" (see below), then the bundle is not uniquely identifiable and all bundle protocol
features that rely on bundle identity must therefore be disabled: the bundle's custody transfer requested flag must be
zero, the "Bundle must not be fragmented" flag must be 1, and all status report request flags must be zero.
6.2.2 Primary Bundle Header Fields
The primary bundle block contains the basic information needed to route bundles to their destinations. The fields of the
primary bundle block are:
Version: A 1-byte field indicating the version of the bundle protocol that constructed this block. The present document
describes version 0x06 of the bundle protocol.
Bundle Processing Control Flags: The Bundle Processing Control Flags field is an SDNV that contains the bundle
processing control flags discussed in Section [TBR6-2] above.
Block Length: The Block Length field is an SDNV that contains the aggregate length of all remaining fields of the block.
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, i.e., the endpoint containing the node(s) at which the
bundle is to be delivered.
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, i.e., the endpoint nominally containing the node from
which the bundle was initially transmitted.
Source SSP Offset: The Source SSP Offset field contains the offset within the dictionary byte array of the schemespecific 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 schemespecific 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 block identifies an endpoint whose
membership includes the node that most recently accepted custody of the bundle upon forwarding this bundle. The
CCSDS 0.1
24/32
CCSDS Bundle Protocol Specification
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 Custodian SSP Offset field contains the offset within the dictionary byte array of the schemespecific part of the current custodian endpoint ID.
Creation Timestamp: The creation timestamp is a pair of SDNVs that, together with the source endpoint ID and (if the
bundle is a fragment) the fragment offset and payload length, serve to identify the bundle. The first SDNV of the
timestamp is the bundle's creation time, while the second is the bundle's creation timestamp sequence number. Bundle
creation time is the time -- expressed in seconds since the start of the year 2000, on the Coordinated Universal Time
(UTC) scale -- at which the transmission request was received that resulted in the creation of the bundle. Sequence
count is the latest value (as of the time at which that transmission request was received) of a monotonically increasing
positive integer counter managed by the source node's bundle protocol agent that may be reset to zero whenever the
current time advances by one second. A source Bundle Protocol Agent must never create two distinct bundles with the
same source endpoint ID and bundle creation timestamp. The combination of source endpoint ID and bundle creation
timestamp therefore serves to identify a single transmission request, enabling it to be acknowledged by the receiving
application (provided the source endpoint ID is not "dtn:none").
Lifetime: The lifetime field is an SDNV that 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, bundle nodes need no longer retain or forward the bundle; 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 Block together with, potentially, other endpoint IDs
referenced by fields in other [TBD6-3] DTN protocol blocks. Its length is given by the value of the Dictionary Length field.
Fragment Offset: If the Bundle Processing Control Flags of this Primary block 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 block.
Total Application Data Unit Length: If the Bundle Processing Control Flags of this Primary block indicate that the
bundle is a 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 block.
6.3 Block Processing Control Flags
The block processing control flags field in every block other than the primary bundle block is an SDNV; the value
encoded in this SDNV is a string of bits used to invoke selected block processing control features. The significance of the
values in all currently defined positions of this bit string, in order from least significant position in the decoded bit string
(labeled '0') to most significant (labeled '6'), is described here.
CCSDS 0.1
25/32
CCSDS Bundle Protocol Specification
Bits 20-14
Status
Report
Bits 13-7
Class of
Service
Bits 6-0
0 – Block must be replicated in every format.
1 - Transmit status report if block can't be processed.
2 - Delete bundle if block can't be processed.
3 - Last block.
4 - Discard block if it can't be processed.
5 - Block was forwarded without being processed.
6 - Block contains an EID-reference field.
Payload Processing Flags
Figure 5: Payload Block Bundle Processing Control Flags Bit Layout
0 - Block must be replicated in every fragment.
1 - Transmit status report if block can't be processed.
2 - Delete bundle if block can't be processed.
3 - Last block.
4 - Discard block if it can't be processed.
5 - Block was forwarded without being processed.
6 - Block contains an EID-reference field.
For each bundle whose primary block's bundle processing control flags (see above) indicate that the bundle's
application data unit is an administrative record, the "Transmit status report if block can't be processed" flag in the block
processing flags field of every other block in the bundle must be zero.
The 'Block must be replicated in every fragment' bit in the block processing flags must be set to zero on all blocks that
follow the payload block.
6.4 Bundle Payload Block
Figure 6: Bundle Payload Block
CCSDS 0.1
26/32
CCSDS Bundle Protocol Specification
The fields of the bundle payload block are:
Block Type: The Block Type field is a 1-byte field that indicates the type of the block. For the bundle payload block, this
field contains the value 1.
Block Processing Control Flags: The Block Processing Control Flags field is an SDNV that contains the block processing
control flags discussed in Section 6.3 above.
Block Length: The Block Length field is an SDNV that contains the aggregate length of all remaining fields of the block which is to say, the length of the bundle's payload.
Payload: The Payload field contains the application data carried by this bundle.
Bundle payload blocks follow the canonical format of the previous section with the restriction that the 'block contains an
EID-reference field' bit of the block processing control flags is never set. The block body data for payload blocks is the
application data carried by the bundle.
6.5 Canonical Bundle Block Format
Every bundle block of every type other than the primary bundle block comprises the following fields, in this order:
1. Block type code, expressed as an 8-bit unsigned binary integer. Bundle block type code 1 indicates that the
block is a bundle payload block. Block type codes 192 through 255 are not defined in this specification and are
available for private and/or experimental use. All other values of the block type code are reserved for future
use.
2. Block processing control flags, an unsigned integer expressed as an SDNV. The individual bits of this integer are
used to invoke selected block processing control features.
3. Block EID reference count and EID references (optional). If and only if the block references EID elements in the
primary block's dictionary, the 'block contains an EID-reference field' flag in the block processing control flags is
set to 1 and the block includes an EID reference field consisting of a count of EID references expressed as an
SDNV followed by the EID references themselves. Each EID reference is a pair of SDNVs. The first SDNV of each
EID reference contains the offset of a scheme name in the primary block's dictionary, and the second SDNV of
each reference contains the offset of a scheme-specific part in the dictionary.
4. Block data length, an unsigned integer expressed as an SDNV. The Block data length field contains the
aggregate length of all remaining fields of the block, i.e., the block-type-specific data fields.
5. Block-type-specific data fields, whose format and order are type- specific and whose aggregate length in octets
is the value of the block data length field. All multi-byte block-type-specific data fields are represented in
network byte order.
Block Type
Block Processing Control Flags §
Block Length §
Block Body Data (Variable)
§ = SDNV
CCSDS 0.1
27/32
CCSDS Bundle Protocol Specification
Figure 7: Block Layout without EID Reference List
Block Type
Block Processing Control Flags §
EID Reference Count §
Reference Scheme 1 §
Reference SSP 1 §
Reference Scheme 2 §
Reference SSP 2 §
Block Length §
Block Body Data (Variable)
§ = SDNV
Figure 8: Block Layout Showing Two EID References
CCSDS 0.1
28/32
CCSDS Bundle Protocol Specification
7 Security Considerations
BSP reference here [TBR7.0]
CCSDS 0.1
29/32
CCSDS Bundle Protocol Specification
Appendix – TBD/TBR list
TBD/TBR
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
TBD1-1
TBR1-1
TBR1-2
TBR1-3
TBR3-1
TBR3-2
TBD4-0
TBD5-0
TDB6-0
TBD6-1
TBR6-2
TBD6-3
CCSDS 0.1
Section
1.1
1.4
1.5
1.7
3.3.4
3.4.5.6
4.0
5.0
6.0
6.1
6.2.2
6.2.2
30/32
Introduction
Organization of this Recommendation
How to read this document
References
IsSingletonEID
Additional Comments
Bundle Processing
Administrative Record Processing
Bundle Message Format
SDNVs
Primary Bundle Headers Fields
Primary Bundle Headers Fields
CCSDS Bundle Protocol Specification
Appendix – RFC5050
This appendix is provided in a separate file as a full text version of RFC55050, and is normative. RFC55050is also
available from http://www.rfc-editor.org/rfc/rfc5050.txt. In the case of inconsistencies between the above protocol
specification and this annex, this annex takes precedence.
CCSDS 0.1
31/32
CCSDS Bundle Protocol Specification
CCSDS 0.1
32/32