ISO 21323:2016

INTERNATIONAL ISO
STANDARD 21323
First edition
2016-11-15
Space data and information transfer
systems — Bundle protocol specification
Systèmes de transfert des données et informations spatiales —
Spécifications du protocole groupé CCSDS
Reference number
©
ISO 2016
©  ISO 2016
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any
means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
Ch. de Blandonnet 8  CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2. www.iso.org/directives
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received. www.iso.org/patents
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT)
see the following URL: Foreword - Supplementary information
ISO 21323 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as CCSDS
734.2-B-1, September 2015) and was adopted (without modifications except those stated in clause 2 of this
International Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee
SC 13, Space data and information transfer systems.
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of its members. The Committee meets periodically to address
data systems problems that are common to all participants, and to formulate sound technical
solutions to these problems. Inasmuch as participation in the CCSDS is completely
voluntary, the results of Committee actions are termed Recommended Standards and are
not considered binding on any Agency.
This Recommended Standard is issued by, and represents the consensus of, the CCSDS
members. Endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever a member establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommended Standard. Establishing such a standard
does not preclude other provisions which a member may develop.
o Whenever a member establishes a CCSDS-related standard, that member will
provide other CCSDS members with the following information:
-- The standard itself.
-- The anticipated date of initial operational capability.
-- The anticipated duration of operational service.
o Specific service arrangements shall be made via memoranda of agreement. Neither
this Recommended Standard nor any ensuing standard is a substitute for a
memorandum of agreement.
No later than five years from its date of issuance, this Recommended Standard will be
reviewed by the CCSDS to determine whether it should: (1) remain in effect without change;
(2) be changed to reflect the impact of new technologies, new requirements, or new
directions; or (3) be retired or canceled.
In those instances when a new version of a Recommended Standard is issued, existing
CCSDS-related member standards and implementations are not negated or deemed to be
non-CCSDS compatible. It is the responsibility of each member to determine when such
standards or implementations are to be modified. Each member is, however, strongly
encouraged to direct planning for its new standards and implementations towards the later
version of the Recommended Standard.
CCSDS 734.2-B-1 Page ii September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
FOREWORD
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. CCSDS has processes for identifying patent issues and for securing
from the patent holder agreement that all licensing policies are reasonable and non-
discriminatory. However, CCSDS does not have a patent law staff, and CCSDS shall not be
held responsible for identifying any or all such patent rights.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in
Organization and Processes for the Consultative Committee for Space Data Systems
(CCSDS A02.1-Y-4). Current versions of CCSDS documents are maintained at the CCSDS
Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be sent to the CCSDS
Secretariat at the e-mail address indicated on page i.
CCSDS 734.2-B-1 Page iii September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (FSA)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking and
Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– Electronics and Telecommunications Research Institute (ETRI)/Korea.
– European Organization for the Exploitation of Meteorological Satellites (EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– South African National Space Agency (SANSA)/Republic of South Africa.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– Swiss Space Office (SSO)/Switzerland.
– United States Geological Survey (USGS)/USA.
CCSDS 734.2-B-1 Page iv September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
DOCUMENT CONTROL
Document Title Date Status
CCSDS CCSDS Bundle Protocol September Original issue
734.2-B-1 Specification, Recommended 2015
Standard, Issue 1
CCSDS 734.2-B-1 Page v September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
CONTENTS
Section Page
1 INTRODUCTION . 1-1

1.1 PURPOSE . 1-1
1.2 SCOPE . 1-1
1.3 ORGANIZATION OF THIS RECOMMENDED STANDARD . 1-1
1.4 DEFINITIONS . 1-2
1.5 REFERENCES . 1-5

2 OVERVIEW . 2-1

2.1 GENERAL . 2-1
2.2 IMPLEMENTATION ARCHITECTURES . 2-3
2.3 SERVICES PROVIDED BY BP . 2-3
2.4 QUALITIES OF SERVICE NOT PROVIDED BY BP . 2-3

3 CCSDS PROFILE OF RFC 5050 . 3-1

3.1 GENERAL . 3-1
3.2 USE OF THE IPN NAMING SCHEME FOR ENDPOINT IDENTIFIERS . 3-1
3.3 BUNDLE PROTOCOL EXTENDED CLASS OF SERVICE . 3-1
3.4 USE OF TIME IN SECTION 6.1 OF RFC 5050 . 3-2
3.5 SANA REGISTRY CONSIDERATIONS . 3-2

4 SERVICE DESCRIPTION . 4-1

4.1 SERVICES AT THE USER INTERFACE . 4-1
4.2 SUMMARY OF PRIMITIVES . 4-1
4.3 SUMMARY OF PARAMETERS . 4-2
4.4 BP SERVICE PRIMITIVES . 4-5

5 SERVICES BP REQUIRES OF THE SYSTEM . 5-1

5.1 RELIABLE STORAGE REQUIREMENTS . 5-1
5.2 UNDERLYING COMMUNICATION SERVICE REQUIREMENTS . 5-1

6 CONFORMANCE REQUIREMENTS . 6-1

6.1 GENERAL REQUIREMENTS . 6-1
6.2 BUNDLE PROTOCOL REQUIREMENTS . 6-1

CCSDS 734.2-B-1 Page vi September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
CONTENTS (continued)
Section Page
ANNEX A PROTOCOL IMPLEMENTATION CONFORMANCE
STATEMENT PROFORMA (NORMATIVE) . A-1
ANNEX B CONVERGENCE LAYER ADAPTERS  (NORMATIVE) .B-1
ANNEX C EXTENDED CLASS OF SERVICE EXTENSION
SPECIFICATION  (NORMATIVE) . C-1
ANNEX D AGGREGATE CUSTODY SIGNAL SPECIFICATION
(NORMATIVE) . D-1
ANNEX E DELAY-TOLERANT PAYLOAD CONDITIONING
SPECIFICATION (NORMATIVE) .E-1
ANNEX F BP MANAGED INFORMATION (NORMATIVE) . F-1
ANNEX G SECURITY, SANA, AND PATENT CONSIDERATIONS
(INFORMATIVE) . G-1
ANNEX H INFORMATIVE REFERENCES (INFORMATIVE) . H-1
ANNEX I ABBREVIATIONS AND ACRONYMS  (INFORMATIVE) . I-1
Figure
1-1 Graphical Representation of a Bundle Node . 1-3
2-1 The Bundle Protocol Provides an End-to-End Delivery Service. 2-2
D-1 ACS Payload Block Definition . D-2
D-2 CTEB Block Definition . D-3
D-3 ACS Processing Flow . D-7

Table
A-1  PICS Notation . A-2
A-2  Symbols for PICS ‘Support’ Column . A-2
E-1  DPDU Header Fields . E-23
E-2  Topic Block Fields . E-24
E-3  Payload Record Fields . E-24
F-1  Bundle State Information . F-2
F-2  Error and Reporting Information . F-3
F-3  Registration Information . F-4
F-4  Node State Information . F-5

CCSDS 734.2-B-1 Page vii September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
1 INTRODUCTION
1.1 PURPOSE
This document defines a Recommended Standard for the CCSDS Bundle Protocol (BP),
based on the Bundle Protocol of RFC 5050 (reference [1]), which defines end-to-end
protocol, block formats, and abstract service descriptions for the exchange of messages
(bundles) that support Delay Tolerant Networking (DTN). BP provides Network Layer
service to applications allowing them to utilize BP’s capabilities:
– custody-based retransmission;
– ability to cope with intermittent connectivity;
– ability to take advantage of scheduled, predicted, and opportunistic connectivity (in
addition to continuous connectivity);
– notional data accountability with built-in status reporting.
1.2 SCOPE
This Recommended Standard is designed to be applicable to any kind of space mission or
infrastructure that is communication-resource poor and is subject to long latencies and/or
temporary network partitions, regardless of complexity. It is intended that this Recommended
Standard become a uniform standard among all CCSDS Agencies. In addition, this
specification exists to utilize the underlying service of various internetworking protocols
both onboard and in transit between ground and space-based assets.
This Recommended Standard is intended to be applied to all systems that claim conformance
to the CCSDS Bundle Protocol. It is agnostic to the choice of underlying transmission
protocol in that BP can function over AOS, Space Packet, Proximity-1 Space Link Protocol,
and various Internet and ground based protocols.
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 reference [H1].
1.3 ORGANIZATION OF THIS RECOMMENDED STANDARD
This Recommended Standard is organized as follows:
– Section 2 contains an overview of the Bundle Protocol and the references from which
it is derived.
– Section 3 contains the CCSDS modification to RFC 5050.
– Section 4 contains the service descriptions.
– Section 5 contains services BP requires of the system.
CCSDS 734.2-B-1 Page 1-1 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
– Section 6 contains conformance requirements.
– Annex A contains the Implementation Conformance Statement for the protocol.
– Annex B contains the Convergence Layer Adapters (CLAs).
– Annex C contains the Extended Class of Service specification.
– Annex D contains the Aggregate Custody Signal specification.
– Annex E contains the Delay Tolerant Payload Conditioning specification.
– Annex F contains BP managed information.
– Annex G contains Security, Space Assigned Numbers Authority (SANA), and Patent
Considerations.
– Annex H contains Informative References.
– Annex I contains abbreviations and acronyms used in this document.
1.4 DEFINITIONS
1.4.1 DEFINITIONS FROM OPEN SYSTEMS INTERCONNECTION (OSI)
SERVICE DEFINITION CONVENTIONS
This Recommended Standard makes use of a number of terms defined in reference [2]. As
used in this Recommended Standard those terms are to 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.
1.4.2 DEFINITIONS FROM OSI BASIC REFERENCE MODEL
This Recommended Standard makes use of a number of terms defined in reference [3]. As
used in this Recommended Standard those terms are to be understood 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:
– entity;
– Protocol Data Unit (PDU);
– service;
– Service Data Unit (SDU).
CCSDS 734.2-B-1 Page 1-2 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
1.4.3 DEFINITIONS FROM RFC 5050
1.4.3.1 Overview
This Recommended Standard makes use of a number of terms defined in reference [1].
Some of the definitions needed for section 2 of this document are reproduced here for
convenience.
A graphical representation of a bundle node is given in figure 1-1. A bundle node is any
entity that can send and/or receive bundles.
Each bundle node has three conceptual components described in more detail below: a
‘bundle protocol agent’, a set of zero or more ‘convergence layer adapters’, and an
‘application agent’. The major components are illustrated in figure 1-1 and include the
addition of storage for enqueued traffic and a Management Information Base (MIB) element.

Figure 1-1: Graphical Representation of a Bundle Node
It should be noted 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).
1.4.3.2 RFC 5050 Terms
bundle: A protocol data unit of the DTN Bundle Protocol.
NOTE – 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.
CCSDS 734.2-B-1 Page 1-3 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
bundle node (also simply ‘node’ or ‘BP node’): Any entity that can send and/or receive
bundles.
NOTE – 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, BPA: Node component that offers the BP services and executes the
procedures of the Bundle Protocol.
NOTE – The manner in which it does so is an implementation matter. BPA functionality
can be coded into individual nodes, as a shared library that is shared by any
number of bundle nodes on a single computer, as a daemon whose services are
invoked via inter-process or network communication by one or more bundle
nodes on one or more computers, or in hardware.
application agent, AA: Node component that utilizes the BP services to effect
communication for some purpose.
NOTE – The AA has an application-specific element and administrative element. The
application-specific element of an AA constructs, as defined in section 5 of RFC
5050, 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 as defined in section 6 of RFC 5050. 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. For 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 way 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.
convergence layer adapter, CLA: Adapter that sends and receives bundles on behalf of the
BPA.
CCSDS 734.2-B-1 Page 1-4 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
NOTE – A CLA enables the BPA to interact with an underlying data transport mechanism
such as a link or network to send and receive bundles. The manner in which a
CLA sends and receives bundles is an implementation matter and is unique to the
underlying transport mechanism. Therefore the BPA may utilize CLAs from a
number of different underlying transport mechanisms subject to the routing of
traffic.
1.5 REFERENCES
The following publications contain provisions which, through reference in this text,
constitute provisions of this document. At the time of publication, the editions indicated
were valid. All publications are subject to revision, and users of this document are
encouraged to investigate the possibility of applying the most recent editions of the
publications indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS publications.
[1] K. Scott and S. Burleigh. Bundle Protocol Specification. RFC 5050. Reston, Virginia:
ISOC, November 2007.
[2] Information Technology—Open Systems Interconnection—Basic Reference Model—
Conventions for the Definition of OSI Services. International Standard, ISO/IEC
10731:1994. Geneva: ISO, 1994.
[3] Information Technology—Open Systems Interconnection—Basic Reference Model: The
Basic Model. 2nd ed. International Standard, ISO/IEC 7498-1:1994. Geneva: ISO,
1994.
[4] S. Burleigh. Compressed Bundle Header Encoding (CBHE). RFC 6260. Reston,
Virginia: ISOC, May 2011.
[5] Space Assigned Numbers Authority (SANA). http://sanaregistry.org/.
[6] Licklider Transmission Protocol (LTP) for CCSDS. Issue 1. Recommendation for
Space Data System Standards (Blue Book), CCSDS 734.1-B-1. Washington, D.C.:
CCSDS, May 2015.
[7] L. Eggert and G. Fairhurst. Unicast UDP Usage Guidelines for Application Designers.
RFC 5405. Reston, Virginia: ISOC, November 2008.
[8] Encapsulation Service. Issue 2. Recommendation for Space Data System Standards
(Blue Book), CCSDS 133.1-B-2. Washington, D.C.: CCSDS, October 2009.
[9] M. Ramadas, S. Burleigh, and S. Farrell. Licklider Transmission Protocol—
Specification. RFC 5326. Reston, Virginia: ISOC, September 2008.
[10] M. Blanchet. Delay-Tolerant Networking Bundle Protocol IANA Registries. RFC 6255.
Reston, Virginia: ISOC, May 2011.
CCSDS 734.2-B-1 Page 1-5 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
2 OVERVIEW
2.1 GENERAL
Delay Tolerant Networking is an end-to-end network service providing communications in
and/or through environments characterized by one or more of the following:
– intermittent connectivity;
– variable delays, which may be large and irregular;
– high bit error rates;
– asymmetric and simplex links.
One core element of DTN is the BP. BP provides end-to-end network services, operating
above the data transport services provided by links or networks accessed via the CLAs, and
forming a store-and-forward network. Key capabilities of the Bundle Protocol include:
– ability to cope with intermittent connectivity;
– ability to take advantage of scheduled and opportunistic connectivity (in addition to
‘always up’ connectivity);
– custody transfer;
– hop-by-hop security (authentication of transmitting entity);
– end-to-end security (confidentiality, integrity) for data;
– late binding of names to addresses.
Reference [H1] contains descriptions of these capabilities and rationale for the DTN
architecture.
The Bundle Protocol uses the ‘native’ local protocols for communications within a given
network. The interface between the Bundle Protocol and a specific lower-layer protocol suite is
known as a convergence layer. Figure 2-1 shows an example configuration with the Bundle
Protocol and a convergence layer adaptor running above a transport protocol (intended to be
interpreted in the context of the Internet stack) on the left, and running directly over a Data
Link Layer on the right. The ‘CL B’ on the right could, for example, be the interface to the
Licklider Transmission Protocol with the ‘Link B1’ representing LTP running over one of the
CCSDS Data Link Layer protocols. Alternatively BP could be used to connect together two
internets that may exist, such as an on-orbit (or lunar) network and a ground network.
CCSDS 734.2-B-1 Page 2-1 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
Applications Applications
Bundle Bundle Bundle
CL A
Conv. Layer A
Transport A Trans A
CL B
Network A Network A Net A CL B
Link A1 Link A1 Link A2 Link An Link B1 Link B1
PhyA1 PhyA1 PhyA2 PhyAn PhyB1 PhyB1
An internet A link‐layer hop
Figure 2-1: The Bundle Protocol Provides an End-to-End Delivery Service
This document describes the format of the messages (called bundles) passed between nodes
participating in bundle communications. In addition, this document addresses endpoint
naming for the purpose of bundle header compression and describes how the protocol may be
extended to support new capabilities while maintaining compatibility with the base protocol.
This document does not address the bundle routing algorithm or mechanisms for populating
the routing or forwarding information bases of bundle nodes.
The IETF’s classification of the Bundle Protocol RFC as ‘experimental’ should be
considered in the context of deployment on the global Internet. In fact it is not viewed as an
Internet Standard nor is it proposed for any specific application. In the Internet, issues such
as scalability to millions of nodes, congestion control, and non-destructive coexistence with
other established protocols (in particular the Transmission Control Protocol [TCP]), are of
extreme importance. Because the Bundle Protocol has NOT been deployed on a scale of
thousands of nodes, and because the specification was the result of an effort by an Internet
Research Task Force (IRTF) working group, the protocol’s status for global deployment is
and should be experimental until it is determined to be suitable for deployment on Internet
scales. However, the applicability of the Bundle Protocol in the harsh environment of space
makes it an excellent technological innovation allowing multiple internetworking
environments to interact.
The SIS-DTN working group has carefully considered the protocol specified in RFC 5050 and
has determined that it is suitable for adoption, together with the modifications in section 3 of
this document, for use in CCSDS missions. In particular, CCSDS missions do not have the
same scalability issues as the Internet, and testing has demonstrated that the profile defined
in this document is suitable for CCSDS environments.
CCSDS 734.2-B-1 Page 2-2 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
2.2 IMPLEMENTATION ARCHITECTURES
There are many ways in which a bundle node can be instantiated. The following are some
examples:
– a single process running on a general-purpose computer;
– a thread running as a background process;
– an object in an object-oriented operating system;
– a special-purpose hardware device.
NOTE – No specific instantiation is defined or expected; these decisions are purely an
implementation issue.
2.3 SERVICES PROVIDED BY BP
BP provides a data transmission service to move ‘bundles’ (contiguous groups of octets) of
data from one BP node to another:
a) commencing a registration (registering a node in an endpoint);
b) terminating a registration;
c) switching a registration between Active and Passive states;
d) transmitting a bundle to an identified bundle endpoint;
e) canceling a transmission that has been requested;
f) polling a registration that is in the Passive state;
g) delivering a received bundle;
h) reporting bundle status.
2.4 QUALITIES OF SERVICE NOT PROVIDED BY BP
The Bundle Protocol as specified in this document does not provide the following services:
a) in-order delivery of bundles;
b) complete delivery of sequences of bundles.
These services may be provided by a layer above BP yet below the end-system applications.
These services can exist as shims. Such a shim provides the logic to accomplish the desired
functions and is inserted between BP and the Application Layer. This would leave the
existing network protocol stack intact. Such a layer is described in annex E of this
document.
CCSDS 734.2-B-1 Page 2-3 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
3 CCSDS PROFILE OF RFC 5050
3.1 GENERAL
This document adopts the Bundle Protocol as specified in Internet RFC 5050 (reference [1]),
with the constraints and exceptions specified in section 3 of this document.
3.2 USE OF THE IPN NAMING SCHEME FOR ENDPOINT IDENTIFIERS
3.2.1 Implementations shall support the ‘IPN’ naming scheme defined in section 2.1 of
RFC 6260, Compressed Bundle Header Encoding (CBHE) (reference [4]).
NOTE – The scheme-specific part of an IPN name consists of:
1) a sequence of ASCII numeric digits representing an integer in the range 1 to
2 −1, termed the ‘node number’ of the URI;
2) an ASCII period (‘.’) character;
3) a sequence of ASCII numeric digits representing an integer in the range 0 to
2 −1, termed the ‘service number’ of the URI.
3.2.2 The IPN node numbers used shall be assigned by SANA from the CCSDS CBHE
Node Number Registry.
3.2.3 The Service Numbers used shall be assigned by IANA / SANA from either the IANA
CBHE Service Numbers registry or the SANA CBHE Service Numbers Registry.
NOTES
1 CBHE is the compression mechanism enabled by the IPN naming scheme.
2 The SANA CBHE Node Number registry is a portion of the IANA registry that has
been delegated to SANA for management by CCSDS.
3.3 BUNDLE PROTOCOL EXTENDED CLASS OF SERVICE
plement the ‘Extended
Conformant implementations of the CCSDS Bundle Protocol shall im
Class of Service (ECOS)’ block defined in annex C.
NOTE – Spacecraft operations may require additional features beyond those identified in
RFC 5050. One such feature is the expansion of the bundle process control flags
designated as ‘class-of-service’. ECOS provides the capability to prioritize or
extend the service classes. Such uses include:
– the creation of emergency or critical traffic;
– expansion of traffic priorities reflective of a diverse user environment;
– special handling of bundles.
CCSDS 734.2-B-1 Page 3-1 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
3.4 USE OF TIME IN SECTION 6.1 OF RFC 5050
Where the spacecraft time system does not provide sufficient precision to support the
requirements of RFC 5050 section 6.1, the precision of the onboard system shall be used.
NOTE – Section 6.1 of RFC 5050 specifies that the time fields in administrative records
use seconds and nanoseconds since the start of year 2000. Spacecraft time
systems may not be able to provide meaningful values for the nanoseconds fields
of these entries. In such a case the administrative time field is required to
support the precision of the clock rate to the significant digits of the Command
and Data Handling (C&DH) subsystem and will not drive requirements on the
precision of the spacecraft clock.
3.5 SANA REGISTRY CONSIDERATIONS
3.5.1 CBHE NODE NUMBERS
3.5.1.1 General
SANA has established the registry
http://sanaregistry.org/r/bp_cbhe_node_numbers/bp_cbhe_node_numbers.html
to manage CBHE Node Number assignments. The registry shall be used to catalog agency-
managed BP CBHE Node Numbers and LTP engine IDs that are coincident.
NOTE – The purpose of this registry is to ensure uniqueness of BP CBHE Node Numbers
used in space missions.
3.5.1.2 Value Range for SANA BP CBHE Node Numbers
The value range for BP CBHE Node Numbers shall be as assigned by IANA.
3.5.1.3 SANA BP CBHE Node Number Registration Policy
The registration policy for the registry shall be: no engineering review required; request must
come from an identified CCSDS representative of a member, observer, or affiliate
organization.
NOTE – For missions utilizing LTP and BP protocols, requests to SANA should attempt to
utilize identical numbers for LTP Protocol Engine Identifiers and BP CBHE IPN
Node Numbers. This allows BP implementations to forego having a CBHE ID-to-
LTP Engine ID mapping table for those cases where they know that the two
identifiers are the same. Synchronizing the CBHE and LTP Engine identifiers is
purely an optimization to aid implementations and is not a requirement.
CCSDS 734.2-B-1 Page 3-2 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
3.5.2 CBHE SERVICE NUMBERS
3.5.2.1 General
SANA has established the registry
http://sanaregistry.org/r/bp_cbhe_service_numbers/bp_cbhe_service_numbers.html
to manage CBHE Service Number assignments. The registry shall be used by CCSDS to
catalog BP CBHE Service Numbers that denote different bundle services.
NOTE – The purpose of this registry is to ensure uniqueness of the CBHE Service
Numbers used in space missions.
3.5.2.2 Value Range for BP CBHE Service Numbers assigned via the SANA Registry
The value range for BP CBHE Service Numbers shall be as assigned by IANA.
3.5.2.3 CCSDS BP CBHE Service Numbers Registration Policy
The registration policy for the registry shall be: no engineering review required; request must
come from an identified CCSDS representative of a member, observer, or affiliate
organization.
CCSDS 734.2-B-1 Page 3-3 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
4 SERVICE DESCRIPTION
4.1 SERVICES AT THE USER INTERFACE
4.1.1 The services provided by the Bundle Protocol shall be made available to bundle
protocol users and include the following:
a) initiate 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.
4.1.2 The BP node shall be im
plemented such that virtually any number of transactions may
be conducted concurrently in various stages of transmission or reception at a single BP node.
NOTE – To clarify: the implementation needs to 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 needs to 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.)
4.2 SUMMARY OF PRIMITIVES
4.2.1 The BP service shall consume the following request primitives:
– Register.request;
– Deregister.request;
– ChangeRegistrationState.request;
– Send.request;
– Cancel.request;
– Poll.request.
4.2.2 The BP service shall deliver the following indication primitives:
– LocalBundleID.indication;
– BundleDelivery.indication.
CCSDS 734.2-B-1 Page 4-1 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
4.3 SUMMARY OF PARAMETERS
4.3.1 DESTINATION COMMUNICATIONS ENDPOINT ID
The destination communications endpoint ID parameter shall identify the communications
endpoint to which the bundle is to be sent.
NOTE – One can think of a DTN communications endpoint as an application, but in
general the definition is meant to be broader. For example, a single BPA (with a
single endpoint ID) could service other local nodes such as elements of a sensor
network using private protocols.
4.3.2 SOURCE COMMUNICATIONS ENDPOINT ID
The source communications endpoint ID parameter shall uniquely identify the
communications endpoint from which the bundle was sent.
4.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 are sent.
4.3.4 ISSINGLETONEID
The IsSingletonEID parameter shall be ‘True’ if the referenced Endpoint IDentifier (EID) is
a singleton, i.e., if there is at most one BP node that is a member of the endpoint identified.
4.3.5 CLASS-OF-SERVICE PARAMETER
4.3.5.1 The class-of-service parameter shall indicate which class of standard procedures is
to be followed when transmitting and delivering the bundle.
4.3.5.2 The value of the class-of-service parameter shall be one of the following:
– bulk;
– normal;
– expedited.
4.3.6 DELIVERY OPTIONS PARAMETER
4.3.6.1 The delivery options parameter shall indicate what optional procedures are
additionally to be followed when transmitting and delivering the bundle.
CCSDS 734.2-B-1 Page 4-2 September 2015
CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION
4.3.6.2 The value of the delivery options parameter shall be a combination of zero or more
of the following:
a) bundle is a fragment;
b) application data unit is an administrative record;
c) bundle must not be fragmented;
d) custody transfer is requested;
e) destination endpoint is a singleton;
f) acknowledgement by application is requested;
g) class of service;
h) request reporting of bundle reception;
i) request reporting of custody acceptance;
j) request reporting of bundle forwarding;
k) request reporting of bundle delivery;
l) request reporting of bundle deletion;
m) extended class of service.
4.3.7 LIFETIME PARAMETER
The lifetime parameter shall indicate the length of time, following initial creation time of a
bundle, after which bundle protocol agents may discard the bundle.
4.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.
4.3.9 LOCAL BUNDLE ID
The Local Bundle ID parameter shall identify a particul
...