CCSDS 734.2-R-1, CCSDS Bundle Protocol Specification (Red ...

Draft Recommendation forSpace Data System StandardsCCSDS BUNDLEPROTOCOLSPECIFICATIONDRAFT RECOMMENDED STANDARDCCSDS 734.2-R-1RED BOOKFebruary 2012

Draft Recommendation forSpace Data System StandardsCCSDS BUNDLEPROTOCOLSPECIFICATIONDRAFT RECOMMENDED STANDARDCCSDS 734.2-R-1RED BOOKFebruary 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONAUTHORITYIssue: Red Book, Issue 1Date: February 2012Location: Not Applicable(WHEN THIS RECOMMENDED STANDARD IS FINALIZED, IT WILL CONTAINTHE FOLLOWING STATEMENT OF AUTHORITY:)This document has been approved for publication by the Management Council of theConsultative Committee for Space Data Systems (CCSDS) and represents the consensustechnical agreement of the participating CCSDS Member Agencies. The procedure forreview and authorization of CCSDS documents is detailed in Organization and Processes forthe Consultative Committee for Space Data Systems (CCSDS A02.1-Y-3), and the record ofAgency participation in the authorization of this document can be obtained from the CCSDSSecretariat at the address below.This document is published and maintained by:CCSDS SecretariatSpace Communications and Navigation Office, 7L70Space Operations Mission DirectorateNASA HeadquartersWashington, DC 20546-0001, USACCSDS 734.2-R-1 Page i February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONSTATEMENT OF INTENT(WHEN THIS RECOMMENDED STANDARD IS FINALIZED, IT WILL CONTAINTHE FOLLOWING STATEMENT OF INTENT:)The Consultative Committee for Space Data Systems (CCSDS) is an organization officiallyestablished by the management of its members. The Committee meets periodically to addressdata systems problems that are common to all participants, and to formulate sound technicalsolutions to these problems. Inasmuch as participation in the CCSDS is completelyvoluntary, the results of Committee actions are termed Recommended Standards and arenot considered binding on any Agency.This Recommended Standard is issued by, and represents the consensus of, the CCSDSmembers. 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 inaccord with the relevant Recommended Standard. Establishing such a standarddoes not preclude other provisions which a member may develop.o Whenever a member establishes a CCSDS-related standard, that member willprovide 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. Neitherthis Recommended Standard nor any ensuing standard is a substitute for amemorandum of agreement.No later than five years from its date of issuance, this Recommended Standard will bereviewed 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 newdirections; or (3) be retired or canceled.In those instances when a new version of a Recommended Standard is issued, existingCCSDS-related member standards and implementations are not negated or deemed to benon-CCSDS compatible. It is the responsibility of each member to determine when suchstandards or implementations are to be modified. Each member is, however, stronglyencouraged to direct planning for its new standards and implementations towards the laterversion of the Recommended Standard.CCSDS 734.2-R-1 Page ii February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONFOREWORDThe CCSDS Bundle Protocol Specification is based on RFC 5050 (reference [1]) andnecessary extensions to support the Delay/Disruption Tolerant Networking (DTN) of spaceapplications. These include annex B, “Extended Class of Service Extension Specification,”and RFC 6260 Compressed Bundle Header Encoding (CBHE) (reference [4]). It represents anoverlay implementation that is extensible to many Link layer protocols to include the InternetProtocol. It supports interoperability between ground- and space-based operations and isresilient to the harsh environment which characterizes spacecraft operations from near Earthto Deep Space.Attention is drawn to the possibility that some of the elements of this document may be thesubject of patent rights. CCSDS shall not be held responsible for identifying any or all suchpatent rights.Through the process of normal evolution, it is expected that expansion, deletion, ormodification of this document may occur. This Recommended Standard is therefore subjectto CCSDS document management and change control procedures, which are defined in theProcedures Manual for the Consultative Committee for Space Data Systems. Currentversions 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 addressed to theCCSDS Secretariat at the address indicated on page i.CCSDS 734.2-R-1 Page iii February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONAt 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 e.V. (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 Trackingand 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.– CSIR Satellite Applications Centre (CSIR)/Republic of South Africa.– Danish National Space Center (DNSC)/Denmark.– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.– 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.– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.– Swedish Space Corporation (SSC)/Sweden.– United States Geological Survey (USGS)/USA.CCSDS 734.2-R-1 Page iv February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONPREFACEThis document is a draft CCSDS Recommended Standard. Its ‘Red Book’ status indicates thatthe CCSDS believes the document to be technically mature and has released it for formalreview by appropriate technical organizations. As such, its technical contents are not stable,and several iterations of it may occur in response to comments received during the reviewprocess.Implementers are cautioned not to fabricate any final equipment in accordance with thisdocument’s technical content.Recipients of this draft are invited to submit, with their comments, notification of anyrelevant patent rights of which they are aware and to provide supporting documentation.CCSDS 734.2-R-1 Page v February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONDOCUMENT CONTROLDocument Title Date StatusCCSDS734.2-R-1CCSDS Bundle ProtocolSpecification, Draft RecommendedStandard, Issue 1February2012Current draftCCSDS 734.2-R-1 Page vi February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONCONTENTSSectionPage1 INTRODUCTION .......................................................................................................... 1-11.1 PURPOSE ............................................................................................................... 1-11.2 SCOPE .................................................................................................................... 1-11.3 ORGANIZATION OF THIS RECOMMENDED STANDARD ........................... 1-11.4 DEFINITIONS ........................................................................................................ 1-21.5 REFERENCES ....................................................................................................... 1-52 OVERVIEW ................................................................................................................... 2-12.1 GENERAL .............................................................................................................. 2-12.2 IMPLEMENTATION ARCHITECTURES ........................................................... 2-22.3 SERVICES PROVIDED BY BP ............................................................................ 2-32.4 SERVICES NOT PROVIDED BY BP ................................................................... 2-33 CCSDS PROFILE OF RFC 5050 ................................................................................. 3-13.1 GENERAL .............................................................................................................. 3-13.2 COMPRESSED BUNDLE HEADER ENCODING .............................................. 3-13.3 BUNDLE PROTOCOL EXTENDED CLASS OF SERVICE ............................... 3-13.4 USE OF TIME IN SECTION 6.1 OF RFC 5050 ................................................... 3-13.5 SANA REGISTRY CONSIDERATIONS ............................................................. 3-23.6 AGENCY USE OF BP CBHE SERVICE NUMBERS .......................................... 3-43.7 USE OF AGGREGATION BY BUNDLE PROTOCOL ....................................... 3-44 SERVICE DESCRIPTION ........................................................................................... 4-14.1 SERVICES AT THE USER INTERFACE ............................................................ 4-14.2 SUMMARY OF PRIMITIVES .............................................................................. 4-14.3 SUMMARY OF PARAMETERS .......................................................................... 4-24.4 BUNDLING SERVICE PRIMITIVES .................................................................. 4-45 SERVICES BP REQUIRES OF THE SYSTEM ........................................................ 5-15.1 RELIABLE STORAGE REQUIREMENTS .......................................................... 5-15.2 UNDERLYING COMMUNICATION SERVICE REQUIREMENTS ................. 5-16 CONFORMANCE REQUIREMENTS ....................................................................... 6-16.1 GENERAL REQUIREMENTS .............................................................................. 6-16.2 BUNDLE PROTOCOL REQUIREMENTS .......................................................... 6-1CCSDS 734.2-R-1 Page vii February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONCONTENTS (continued)SectionPageANNEX A CONVERGENCE LAYER ADAPTERS (NORMATIVE) ...................... A-1ANNEX B EXTENDED CLASS OF SERVICE EXTENSIONSPECIFICATION (NORMATIVE) .............................................................B-1ANNEX C BP MANAGED INFORMATION (NORMATIVE) ................................. C-1ANNEX D PROTOCOL IMPLEMENTATION CONFORMANCESTATEMENT PROFORMA (NORMATIVE) .......................................... D-1ANNEX E SECURITY, SANA, AND PATENT CONSIDERATIONS(INFORMATIVE) ..........................................................................................E-1ANNEX F INFORMATIVE REFERENCES (INFORMATIVE) ............................... F-1ANNEX G ABBREVIATIONS AND ACRONYMS (INFORMATIVE) ................... G-1Figure1-1 Graphical Representation of a Bundle Node ................................................................ 1-32-1 The Bundling Protocols Sit at or above the Link Layer ............................................... 2-1Table3-1 CCSDS BP CBHE Node Number Registry .................................................................. 3-23-2 Initial CCSDS BP CBHE Service Number Registry .................................................... 3-4C-1 Bundle State Information ..............................................................................................C-2C-2 Error and Reporting Information ..................................................................................C-3C-3 Registration Information ...............................................................................................C-5C-4 CLA Information ..........................................................................................................C-7D-1 PICS Notation .............................................................................................................. D-2D-2 PICS Conditional Status Notation ............................................................................... D-2D-3 Symbols for PICS ‘Protocol Feature’ Column ............................................................ D-3D-4 Symbols for PICS ‘Support’ Column .......................................................................... D-3CCSDS 734.2-R-1 Page viii February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION1 INTRODUCTION1.1 PURPOSEThis document defines a Recommended Standard for the CCSDS Bundle Protocol, based onthe Bundle Protocol of RFC 5050 (reference [1]), and which defines end-to-end protocol,block formats, and abstract service descriptions for the exchange of messages (bundles) thatsupport Delay Tolerant Networking (DTN). BP provides network-layer service toapplications 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 (inaddition to continuous connectivity);– notional data accountability with built-in status reporting.1.2 SCOPEThis Recommended Standard is designed to be applicable to any kind of space mission orinfrastructure that is communication-resource poor and is subject to long latencies and/ortemporary network partitions, regardless of complexity. It is intended that this RecommendedStandard become a uniform standard among all CCSDS Agencies. In addition, thisspecification exists to utilize the underlying service of various internetworking protocolsboth onboard and in transit between ground and space-based assets.This Recommended Standard is intended to be applied to all systems that claim conformanceto the CCSDS Bundle Protocol. It is agnostic to the choice of underlying transmissionprotocol in that BP can function over AOS, Space Packet, Proximity-1 Space Link Protocol,and various Internet (IP) and ground based protocols.The CCSDS believes it is important to document the rationale underlying therecommendations chosen, so that future evaluations of proposed changes or improvementswill not lose sight of previous decisions. The concept and rationale for the use of a bundleprotocol in space links may be found in reference [F1].1.3 ORGANIZATION OF THIS RECOMMENDED STANDARDThis Recommended Standard is organized as follows:– Section 2 contains an overview of the Bundle Protocol and the references from whichit is derived.– Section 3 contains the CCSDS modification to RFC 5050.– Section 4 contains the service descriptions.CCSDS 734.2-R-1 Page 1-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION– Section 5 contains services BP requires of the system.– Section 6 contains conformance requirements.– Annex A contains the Compressed Bundle Header Encoding (CBHE) namingscheme.– Annex B contains the Extended Class of Service specification.– Annex C contains BP managed information.– Annex D contains the Implementation Conformance Statement for the protocol.– Annex E contains the Security, SANA, and Patent Considerations.– Annex G contains the abbreviations and acronyms.1.4 DEFINITIONS1.4.1 DEFINITIONS FROM OPEN SYSTEMS INTERCONNECTION (OSI)SERVICE DEFINITION CONVENTIONSThis Recommended Standard makes use of a number of terms defined in reference [2]. Theuse of those terms in this Recommended Standard 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 technologiesthat provide for the exchange of information between real systems. Those terms are:– indication;– primitive;– request;– response.1.4.2 DEFINITIONS FROM OSI BASIC REFERENCE MODELThis Recommended Standard makes use of a number of terms defined in reference [3]. Theuse of those terms in this Recommended Standard 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 technologiesthat 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-R-1 Page 1-2 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION1.4.3 DEFINITIONS FROM RFC 50501.4.3.1 OverviewThis Recommended Standard makes use of a number of terms defined in reference [1]. Someof 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 anyentity 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 theaddition of storage for enqueued traffic and a Management Information Base (MIB) element.Bundle NodeStorageApplication AgentBundle Protocol AgentMIBCL Adaptor CL Adaptor CL AdaptorFigure 1-1: Graphical Representation of a Bundle NodeIt should be noted that there is ONE application agent per conceptual bundle node. Thatapplication may register in multiple endpoints (may provide multiple endpoint identifiers tothe bundle protocol agent, requesting delivery of bundles to any of those endpoints).1.4.3.2 RFC 5050 Termsbundle. 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 sameunit of DTN protocol data) might exist concurrently in different parts of anetwork, possibly in different representations, in the memory local to one ormore bundle nodes and/or in transit between nodes. In the context of theoperation of a bundle node, a bundle is an instance of some bundle in the networkthat is in that node’s local memory.bundle node (also simply ‘node’). Any entity that can send and/or receive bundles.CCSDS 734.2-R-1 Page 1-3 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONNOTE – In the most familiar case, a bundle node is instantiated as a single processrunning on a general-purpose computer, but in general the definition is meant tobe broader: a bundle node might alternatively be a thread, an object in an objectorientedoperating system, a special-purpose hardware device, etc. Each bundlenode 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. Node component that offers the BP services and executes theprocedures of the bundle protocol.NOTE – The manner in which it does so is an implementation matter. Bundle ProtocolAgent (BPA) functionality can be coded into individual nodes; as a shared librarythat is shared by any number of bundle nodes on a single computer; as a daemonwhose services are invoked via inter-process or network communication by oneor more bundle nodes on one or more computers; or in hardware.application agent. Node component that utilizes the BP services to effect communication forsome purpose.NOTE – The Application Agent (AA) has an application-specific element andadministrative element. The application-specific element of an AA constructs, asdefined in section 5 of RFC 5050, requests transmission of, accepts delivery of, andprocesses application-specific application data units; the only interface between theBPA and the application-specific element of the AA is the BP service interface.The administrative element of an AA constructs and requests transmission ofadministrative records as defined in section 6 of RFC 5050. It accepts delivery ofand processes any custody signals that the node receives. In addition to the BPservice interface, there is a (conceptual) private control interface between the BPAand the administrative element of the AA that enables each to direct the other totake action under specific circumstances. For a node that serves simply as a‘router’ in the overlay network, the AA may have no application-specific elementat all. The application-specific elements of other nodes’ AAs may performarbitrarily complex application functions, perhaps even offering multiplexed DTNcommunication services to a number of other applications. As with the BPA, theway 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 orhardware that implements the BPA, and the application-specific element of an AAmight be implemented either in software or in hardware.convergence layer adapters. Adapter that sends and receives bundles on behalf of the BPA.NOTE – A Convergence Layer Adapter (CLA) enables the BPA to interact with aninterfacing network and use the services of that ‘native’ internet protocol towhich the specific CLA functionally interfaces. The manner in which a CLAsends and receives bundles is an implementation matter and is unique to theassociated internetworking layer. Therefore the BPA may utilize CLAs from anumber of different networks subject to the routing of traffic.CCSDS 734.2-R-1 Page 1-4 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION1.5 REFERENCESThe following documents contain provisions which, through reference in this text, constituteprovisions of this Recommended Standard. At the time of publication, the editions indicatedwere valid. All documents are subject to revision, and users of this Recommended Standardare encouraged to investigate the possibility of applying the most recent editions of thedocuments indicated below. The CCSDS Secretariat maintains a register of currently validCCSDS documents.[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/IEC10731:1994. Geneva: ISO, 1994.[3] Information Technology—Open Systems Interconnection—Basic Reference Model: TheBasic Model. International Standard, ISO/IEC 7498-1:1994. 2nd ed. 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. Draft Recommendation for Space DataSystem Standards, CCSDS 734.1-R-1. Red Book. Issue 1. Washington, D.C.: CCSDS,February 2011.[7] L. Eggert and G. Fairhurst. Unicast UDP Usage Guidelines for Application Designers. RFC5405. Reston, Virginia: ISOC, November 2008.[8] E. Kohler, M. Handley, and M. Handley. Datagram Congestion Control Protocol (DCCP).RFC 4340. Reston, Virginia: ISOC, March 2006.[9] M. Ramadas, S. Burleigh, and S. Burleigh. 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-R-1 Page 1-5 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION2 OVERVIEW2.1 GENERALDelay Tolerant Networking is an end-to-end network service providing communications inand/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.To provide the end-to-end network services the DTN protocols, also known as bundleprotocols, sit above the link or transport layers of the constituent internets, forming a storeand-forwardoverlay 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;– hop-by-hop security (authentication of transmitting entity);– end-to-end security (confidentiality, integrity) for data;– late binding of names to addresses.Reference [F1] contains descriptions of these capabilities and rationale for the DTNarchitecture.Bundle Bundle BundleTransport A Transport A Trans A Trans B Transport BNetwork A Network A Net A Net B Net BLink A1 Link A1 Link A2Link An Link B1 Link B1Phy A1 Phy A1 Phy A2Phy An Phy B1 Phy B1An internet An internetFigure 2-1: The Bundling Protocols Sit at or above the Link LayerCCSDS 734.2-R-1 Page 2-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONThe bundle protocols sit at or above the link or transport layers of networks as shown infigure 2-1. Bundling uses the ‘native’ local protocols for communications within a givennetwork. The interface between the common bundle protocol and a specific lower-layerprotocol suite is known as a convergence layer. Figure 2-1 shows the bundle protocol abovethe TCP/IP implementation on the right. For a space-borne application communicating overCCSDS data links, BP would use a convergence layer running over the LickliderTransmission Protocol (LTP).This document describes the format of the messages (called bundles) passed between entitiesparticipating in bundle communications. The entities are referred to as bundle nodes, and theapplications executing the bundle protocols are called bundle daemons. In addition thisdocument addresses endpoint naming for the use of bundle header compression and how theprotocol may be extended to support new capabilities while maintaining compatibility withthe base protocol. This document does not address:– the convergence layers that bundle protocol agents use to transport data or the bundleprotocol agent to convergence layer API;– the bundle routing algorithm or mechanisms for populating the routing or forwardinginformation bases of bundle nodes.The IETF’s classification of the Bundle Protocol RFC as ‘experimental’ should beconsidered in the context of deployment on the global Internet. In fact it is not viewed as aninternet standard nor is it proposed for any specific application. In the Internet, issues suchas scalability to millions of nodes, congestion control, and non-destructive coexistence withother established protocols (in particular the Transmission Control Protocol [TCP]), are ofextreme importance. Because the Bundle Protocol has NOT been deployed on a scale ofthousands of nodes, and because the specification was the result of an effort by an InternetResearch Task Force (IRTF) working group, the protocol’s status for global deployment isand should be (until it is determined to be suitable for deployment on Internet scales)experimental. However, the applicability of the Bundle Protocol in the harsh environment ofspace makes it an excellent technological innovation allowing multiple internetworkingenvironments to interact.The SIS-DTN working group has carefully considered the protocol specified in RFC 5050 andhas determined that it is suitable for adoption, together with the modifications in section 3 ofthis document, for use in CCSDS missions.2.2 IMPLEMENTATION ARCHITECTURESThere are many ways in which a bundle node can be instantiated. The following are someexamples:– a single process running on a general-purpose computer;– a thread running as a background process;CCSDS 734.2-R-1 Page 2-2 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION– an object in an object-oriented operating system;– a special-purpose hardware device.2.3 SERVICES PROVIDED BY BPBP provides a data transmission service to move ‘bundles’ (contiguous groups of octets) ofdata 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) bundle status reporting.2.4 SERVICES NOT PROVIDED BY BPThe bundle protocol as specified in this document DOES NOT provide any of the followingservices: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 desiredfunctions and are inserted between BP and the application layer. This would leave theexisting network protocol stack intact.CCSDS 734.2-R-1 Page 2-3 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION3 CCSDS PROFILE OF RFC 50503.1 GENERALThis document adopts the Bundle Protocol (BP) as specified in Internet RFC 5050(reference [1]), with the constraints and exceptions specified in section 3 of this document.3.2 COMPRESSED BUNDLE HEADER ENCODINGConformant implementations of the CCSDS Bundle Protocol shall implement the‘Compressed Bundle Header Encoding (CBHE)’ (reference [4]).NOTE – CBHE supports bit-efficient encoding of BP endpoint identifiers that use CBHEconformantschemes. Endpoints are identified by the combination of node numberand service number, both of which are Self-Delimiting Numeric Values (SDNVs).3.3 BUNDLE PROTOCOL EXTENDED CLASS OF SERVICEConformant implementations of the CCSDS Bundle Protocol shall implement the ‘ExtendedClass of Service (ECOS)’ block defined in annex B.NOTE – Spacecraft operations may require additional features beyond those identified inRFC 5050. One such feature is the expansion of the bundle process control flagsdesignated as ‘class-of-service’. ECOS provides the capability to prioritize orextend 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.3.4 USE OF TIME IN SECTION 6.1 OF RFC 5050Where the spacecraft time system does not provide sufficient precision to support therequirements 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 recordsuse seconds and nanoseconds since the start of year 2000. Spacecraft timesystems may not be able to provide meaningful values for the nanoseconds fieldsof these entries. In such a case the administrative time field shall support theprecision of the clock rate to the significant digits of the Command and DataHandling (C&DH) subsystem and will not drive requirements on the precision ofthe spacecraft clock.CCSDS 734.2-R-1 Page 3-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION3.5 SANA REGISTRY CONSIDERATIONS3.5.1 GENERALSANA shall establish a registry of BP CBHE Node Numbers as defined by IANA whichshall be used to denote agency manage BP CBHE Node Numbers and LTP engine IDs whichare coincident.NOTE – The purpose of this registry is to ensure uniqueness of BP CBHE Node Numbersthat are used in space missions.3.5.2 VALUE RANGE FOR BP CBHE NODE NUMBERSThe value range for BP CBHE Node Numbers shall be integers greater than 0 (reference [5],‘Bundle Protocol Compressed Bundle Header Encoding Node Numbers’).3.5.3 CCSDS BP CBHE NODE NUMBER REGISTRATION POLICYThe registration policy for the registry shall be: no engineering review required; requestmust come from the official CCSDS representative of a member agency.NOTE – For missions utilizing LTP and BP protocols, requests to SANA should attemptto utilize identical numbers for LTP Protocol Engine Identifiers and BP CBHENode Numbers to minimize confusion between missions.3.5.4 INITIAL CCSDS BP CBHE NODE NUMBER REGISTRY3.5.4.1 The initial content of the CCSDS BP CBHE Node Number Registry shall asspecified in table 3-1.Table 3-1: CCSDS BP CBHE Node Number RegistryValue Description Reference0 – 2 14 -1 Reserved This document2 14 – 2 21 -1 Assignable by SANA; blocks from this spaceallocated in units of 2 14 starting with 2 15 (see note)This document>=2 21 -1 Reserved This documentNOTE – The purpose of the block allocation scheme is to allocate 2 bytes of SDNVnumbering space (16,383 CBHE node numbers) per request. Each allocationcorresponds to a single number in the third octet of SDNV number space identifyingthe registrant, who is then responsible for managing the 16,383 numbers identifiedby the low order 2 octets of SDNV space.CCSDS 734.2-R-1 Page 3-2 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION11 0Each SANA allocationconsumes one value in thethird SDNV octet; the values128d is reserved; 129d—255d are available forallocation.Each SANA allocation assigns 2 14 ‐1nodenumbersthat are managed by the requestor.3.5.4.2 SANA shall establish a registry of BP CBHE Service Numbers.NOTE – The purpose of this registry is to ensure consistent identification of commonlyused BP clients. This registry is similar to the ‘well-known ports’ registrymaintained by IANA.3.5.5 VALUE RANGE FOR BP CBHE SERVICE NUMBERS ASSIGNED VIA THESANA REGISTRYThe value range for BP CBHE Service Numbers shall be: integers greater than 0.3.5.6 CCSDS BP CBHE SERVICE NUMBERS REGISTRATION POLICYThe registration policy for the registry shall be: no engineering review required; requestmust come from the official CCSDS representative of a member agency.3.5.7 INITIAL CCSDS BP CBHE SERVICE NUMBERS REGISTRYThe initial content of the CCSDS BP CBHE Service Numbers Registry shall as specified intable 3-2.CCSDS 734.2-R-1 Page 3-3 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONTable 3-2: Initial CCSDS BP CBHE Service Number RegistryValue Description Reference0 Administrative Record This document1 Echo service This Document2 Discard This Document3 Console This Document4 CFDP This Document5 – 127 Reserved Expert Review by CESG128 – 2 16 -1 Unassigned This document>=2 16 Private or experimental This document3.6 AGENCY USE OF BP CBHE SERVICE NUMBERSAll instances of BP for deployment in support of CCSDS missions and that use CBHE shalluse BP CBHE Service Numbers allocated by the CCSDS Space Assigned NumbersAuthority (SANA) (reference [5], ‘Bundle Protocol Compressed Bundle Header EncodingService Numbers’).NOTE – CBHE Service Numbers are represented in the bundle protocol with SDNVs.Values up to 2 21 -1 can be represented in three bytes.3.7 USE OF AGGREGATION BY BUNDLE PROTOCOLAggregation of bundles defined by this specification shall be by Licklider Transport Protocolas defined in section 3 of LTP for CCSDS (reference [6]).NOTE – Bundle protocol does not specifically prohibit the aggregation of bundles;however, it is viewed as desirable and expedient to use a CCSDS service that iscomplementary and viable for encapsulation of various types of PDU and notonly RFC 5050 bundles.CCSDS 734.2-R-1 Page 3-4 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION4 SERVICE DESCRIPTION4.1 SERVICES AT THE USER INTERFACEThe services provided by the bundle protocol shall be made available to bundle protocolusers 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.The DTN entity shall be implemented such that virtually any number of transactions may beconducted concurrently in various stages of transmission or reception at a single DTN entity.NOTE – To clarify: the implementation shall be able to accept a primitive, and thereuponinitiate a new transaction prior to the completion of previously initiatedtransactions. The requirement for concurrent transaction support therefore doesnot necessarily imply that the implementation shall be able to begin initialtransmission of data for one transaction while initial transmission of file data forone or more other transactions is still in progress. (But neither is support for thisfunctional model precluded.)4.2 SUMMARY OF PRIMITIVES4.2.1 The Bundling service shall consume the following request primitives:– Register.request;– Deregister.request;– ChangeRegistrationState.request;– Send.request;– Cancel.request;– Poll.request.4.2.2 The Bundling service shall deliver the following indication primitives:– LocalBundleID.indication;– BundleDelivery.indication.CCSDS 734.2-R-1 Page 4-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION4.3 SUMMARY OF PARAMETERS4.3.1 DESTINATION COMMUNICATIONS ENDPOINT IDThe destination communications endpoint ID parameter shall identify the communicationsendpoint to which the bundle is to be sent.NOTE – One can think of a DTN communications endpoint as an application, but ingeneral the definition is meant to be broader. For example, elements of a sensornetwork might register with a local bundle protocol agent to receive informationabout certain topics of interest. A communications endpoint could thus refer to aprocess running on a general-purpose processor, a special-purpose hardwaredevice, an object in an object-oriented operating system, etc.4.3.2 SOURCE COMMUNICATIONS ENDPOINT IDThe source communications endpoint ID parameter shall uniquely identify thecommunications endpoint from which the bundle was sent.4.3.3 REPORT-TO COMMUNICATIONS ENDPOINT IDThe report-to communications endpoint ID parameter shall identify the communicationsendpoint to which any bundle status reports pertaining to the bundle.4.3.4 ISSINGLETONEIDThe IsSingletonEID parameter shall be ‘True’ if the referenced Endpoint IDentifier (EID) isa 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 PARAMETERThe class-of-service parameter shall indicate which class of standard procedures shall befollowed when transmitting and delivering the bundle. Its value shall be one of thefollowing:– bulk;– normal;– expedited.CCSDS 734.2-R-1 Page 4-2 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION4.3.6 DELIVERY OPTIONS PARAMETERThe delivery options parameter shall indicate what optional procedures shall additionally befollowed when transmitting and delivering the bundle. Its value shall be a combination ofzero or more of the following:a) custody transfer;b) do-not-fragment;c) end-to-end return receipt;d) deletion receipt;e) delivery records for bundle received events;f) delivery records for bundle transmitted events;g) delivery records for custody taken events.4.3.7 LIFETIME PARAMETERThe lifetime parameter shall indicate the length of time, following initial creation time of abundle, after which bundle protocol agents may discard the bundle.4.3.8 APPLICATION DATA UNIT PARAMETERThe application data unit parameter shall indicate the location (in memory or non-volatilestorage, a local implementation matter) of the application data conveyed by the bundle.4.3.9 LOCAL BUNDLE IDThe Local Bundle ID parameter shall identify a particular bundle within the context of agiven bundle protocol agent.NOTE – This identification is provided to the user of the bundle service on submitting abundle for transmission so that the user may later reference that bundle in otherrequests, such as cancellation. The form of this identifier is entirelyimplementation-specific and should not be confused with the global Bundle IDfield used to uniquely identify bundles in the network.CCSDS 734.2-R-1 Page 4-3 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION4.4 BUNDLING SERVICE PRIMITIVES4.4.1 Register.request4.4.1.1 FunctionThe Register.request primitive shall be used to notify the bundle protocol agent of thestart of a period of passive bundle reception.4.4.1.2 SemanticsRegister.request shall provide parameters as follows:Register.request(delivery failure action,destination communications endpoint ID)4.4.1.3 When GeneratedRegister.request may be generated by any Bundling application at any time.4.4.1.4 Effect on ReceiptReceipt of Register.request shall cause the bundle protocol agent to deliver to theBundling application any bundles destined for the application that (a) arrived in the past andwere deferred or (b) arrive during the new period of passive bundle reception.4.4.1.5 Additional CommentsOnly one registration can be active for a given application and a given endpoint identifier at atime. That is, a given application may not register the same destination communicationsendpoint ID multiple times.CCSDS 734.2-R-1 Page 4-4 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION4.4.2 Deregister.request4.4.2.1 FunctionThe Deregister.request primitive shall be used to notify the bundle protocol agent of theend of a period of active or passive bundle reception.4.4.2.2 SemanticsDeregister.request shall provide parameters as follows:Deregister.request(destination communications endpoint ID)4.4.2.3 When GeneratedDeregister.request may be generated by any Bundling node at any time when the nodehas an active registration.4.4.2.4 Effect on ReceiptReceipt of Deregister.request shall cause the bundle protocol agent to dispatch anysubsequently arriving bundles destined for the registered endpoint in accord with the deliveryfailure action specified by the most recent Register.request primitive issued by this nodefor that endpoint.4.4.2.5 Additional CommentsMultiple applications may be members of the same endpoint. One node deregistering fromthe endpoint does not affect other nodes’ delivery or delivery failure behavior.CCSDS 734.2-R-1 Page 4-5 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION4.4.3 ChangeRegistrationState.request4.4.3.1 FunctionThe ChangeRegistrationState.request primitive shall be used to notify the bundleprotocol agent of a desired change in the bundle reception state.4.4.3.2 SemanticsChangeRegistrationState.request shall provide parameters as follows:ChangeRegistrationState.request(destination communications endpoint ID,registrationState)4.4.3.3 When GeneratedChangeRegistrationState.request may be generated by any Bundling application at anytime when it has one or more active registrations.4.4.3.4 Effect on ReceiptReceipt of ChangeRegistrationState.request shall cause the bundle protocol agent tochange the state of the registration to the requested state, if possible.4.4.3.5 Additional CommentsNone.CCSDS 734.2-R-1 Page 4-6 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION4.4.4 Send.request4.4.4.1 FunctionThe Send.request primitive shall be used by the application to request transmission of anapplication data unit from the source communications endpoint to a destinationcommunications endpoint.4.4.4.2 SemanticsSend.request shall provide parameters as follows:Send.request(source communications endpoint ID,destination communications endpoint ID,report-to communications endpoint ID,class-of-service,IsSingletonEID,delivery options,lifetime,application data unit)4.4.4.3 When GeneratedSend.request is generated by the source Bundling application at any time.4.4.4.4 Effect on ReceiptReceipt of Send.request shall cause the bundle protocol agent to initiate bundletransmission procedures.4.4.4.5 Additional CommentsNone.CCSDS 734.2-R-1 Page 4-7 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION4.4.5 Cancel.request4.4.5.1 FunctionThe Cancel.request primitive shall be used by the application to request termination oftransmission of an application data unit for which the application previously requestedtransmission.4.4.5.2 SemanticsCancel.request shall provide parameters as follows:Cancel.request(Local Bundle ID)4.4.5.3 When GeneratedCancel.request is generated by the application at any time after requesting transmission ofa bundle.4.4.5.4 Effect on ReceiptReceipt of Cancel.request shall cause the bundle protocol agent to stop attempting totransmit and to discard the target bundle, if possible.4.4.5.5 Additional CommentsIf the bundle has already been transmitted, there is no obligation on the sending bundleprotocol agent to take any further action. It is an implementation matter whether a bundlethat is in the process of being transmitted when a Cancel.request is received is terminated.CCSDS 734.2-R-1 Page 4-8 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION4.4.6 Poll.request4.4.6.1 FunctionThe Poll.request primitive shall be used by the application to request immediate deliveryof a bundle to a registration that is in the active mode.4.4.6.2 SemanticsPoll.request shall provide parameters as follows:Poll.request(destination communications endpoint ID)4.4.6.3 When GeneratedPoll.request is generated by any Bundling application at any time when not currently in aperiod of passive bundle reception.4.4.6.4 Effect on ReceiptReceipt of Poll.request shall cause the bundle protocol agent to deliver to the Bundlingapplication the least recently received bundle, destined for the destination communicationsendpoint ID, for which delivery was deferred. Prioritization only applies to forwarding of abundle. Deferred bundles are delivered on an first-come, first-served basis.4.4.6.5 Additional CommentsNone.CCSDS 734.2-R-1 Page 4-9 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION4.4.7 LocalBundleID.indication4.4.7.1 FunctionThe LocalBundleID.indication primitive shall be used to provide the application areference to a particular bundle of which the application requested transmission.4.4.7.2 SemanticsLocalBundleID.indication shall provide parameters as follows:LocalBundleID.indication(Local Bundle ID)4.4.7.3 When GeneratedLocalBundleID.indication shall be generated by a bundle protocol agent once it hasconsumed a Send.request from the application.4.4.7.4 Effect on ReceiptThe effect on receipt of LocalBundleID.indication by a Bundling application isundefined.4.4.7.5 Additional CommentsOn receiving this notice the sending application may, for example, release resources of itsown that are allocated to the bundles being transmitted, or remember the Local Bundle ID sothat transmission can be canceled in the future if necessary.CCSDS 734.2-R-1 Page 4-10 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION4.4.8 BundleDelivery.indication4.4.8.1 FunctionThe BundleDelivery.indication primitive shall be used to indicate to the bundle serviceuser that a bundle has been delivered to the application.4.4.8.2 SemanticsBundleDelivery.indication shall provide parameters as follows:BundleDelivery.indication(header information,application data unit)4.4.8.3 When GeneratedBundleDelivery.indication shall be generated by a bundle protocol agent on reception ofbundles destined for passive registrations or in response to poll requests.4.4.8.4 Effect on ReceiptEffect on receipt is defined by the application.4.4.8.5 Additional CommentsNone.CCSDS 734.2-R-1 Page 4-11 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION5 SERVICES BP REQUIRES OF THE SYSTEM5.1 RELIABLE STORAGE REQUIREMENTSBP nodes require access to a reliable storage service.NOTES1 This storage mechanism may be in dynamic memory or via a persistent mechanism suchas a solid-state recorder and may be organized by various means to include file systems.2 The implementation of this storage can be shared among multiple elements of thecommunication stack so that reliability mechanisms at multiple layers do not have tomaintain multiple copies of the data being transmitted.3 Volume of storage required and duration of storage are mission- and implementationdependent.5.2 UNDERLYING COMMUNICATION SERVICE REQUIREMENTS5.2.1 Each convergence layer protocol adapter is expected to provide the followingservices to the bundle protocol agent:a) sending a bundle to all bundle nodes in the minimum reception group of the endpointidentified by a specified endpoint ID that are reachable via the convergence layerprotocol; andb) delivering to the bundle protocol agent a bundle that was sent by a remote bundlenode via the convergence layer protocol.NOTE – The convergence layer service interface specified here is neither exhaustivenor exclusive. That is, supplementary DTN protocol specifications(including, but not restricted to, the Bundle Security Protocol [BSP]) mayexpect convergence layer adapters that serve BP implementations conformingto those protocols to provide additional services.5.2.2 The following information shall be available to BP, either from the local operatingenvironment or from the underlying communication service provider.NOTE – The means by which this information is accessed by BP is implementationdependent.– forward advancing time that can be represented as ‘DTN time’ as defined by RFC5050 (reference [1]);– at least one long lived singleton EndpointID;– ability to create a unique creation time for BP traffic.CCSDS 734.2-R-1 Page 5-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION5.2.3 The layer-(N-1) service shall deliver only complete layer-(N-1) service data units(bundles) to the receiving BP Node.5.2.4 The layer-(N-1) service shall provide integrity checking of the layer-(N-1) (bundle)service data units and shall discard layer-(N-1) service data units that are determined to becorrupted.5.2.5 BP assumes that, if necessary to the overall design, the layer-(N-1) service shallprovide a cap on the rate at which a sending BP engine can inject data into the layer-(N-1)service.NOTE – If such a capability is needed and is not provided by the layer-(N-1) service, itmay be possible to provide it as part of the BP interface to the layer-(N-1)service.CCSDS 734.2-R-1 Page 5-2 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION6 CONFORMANCE REQUIREMENTS6.1 GENERAL REQUIREMENTS6.1.1 PROTOCOL IMPLEMENTATIONA conforming implementation of this protocol shall:– conform to the BP specification (RFC 5050, reference [1]);– conform to the ECOS specification of annex B;– conform to the CBHE specification (RFC 6260, reference [4]);– implement the modifications in section 3 of this document;– implement the services described in section 4 of this document.6.1.2 PICS PROFORMAAn implementer shall prepare a Protocol Implementation Conformance Statement (PICS)based on the defined proforma in annex D of this document.6.2 BUNDLE PROTOCOL REQUIREMENTS6.2.1 MAJOR CAPABILITIES6.2.1.1 All Bundle Protocol ImplementationsAll Bundle Protocol implementations shall implement the following capabilities inaccordance with the base standard (RFC 5050):a) bundle structure as described in RFC 5050 sections 3.1, 4.0, 4.2, 4.4, 5.8, and 8;b) block structure as described in RFC 5050 sections 4.1, 4.5, 4.5.1, 4.5.2, 4.5.3, 4.6,4.7;c) administrative record generation and structure as described in RFC 5050 section 5.1,6.0, 6.1, and 6.2;d) administrative record processing as described in RFC 5050 sections 6.1.1, 6.1.2, and6.3;e) CBHE in accordance with RFC 6260 and section 3 of this document;f) ECOS in accordance with annex B and section 3 of this document.CCSDS 734.2-R-1 Page 6-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION6.2.1.2 Bundle Protocol Senders6.2.1.2.1 A conforming BP implementation shall support the following in accordance withthe base standard:a) bundle transmission as described in RFC 5050 sections 3.3, 4.3, 5.15, and 5.2;b) bundle forwarding as defined in RFC 5050 sections 4.2, 5.1, 5.3, 5.4, 5.4.1, 5.4.2, and5.5).6.2.1.2.2 In addition, a BP sender shall also support the following capabilities inaccordance with the base standard:a) intermittent connectivity conditions specified in RFC 5050 section 1;b) late binding as described in RFC 5050 section 1;c) bundle delivery failure as defined in RFC 5050 section 3.1;d) bundle priority as defined in RFC 5050 section 4.2 and the ECOS appendix C;e) bundle deletion procedures as defined in RFC 5050 sections 3.1, 4.2, 5.13, and 5.14;f) dictionary byte array and revision per RFC 5050 sections 4.4 and 4.7.6.2.1.3 Bundle Protocol ReceiversA conforming BP implementation shall support the following in accordance with the basestandard:a) bundle acceptance in accordance with RFC 5050 section 4.2, 4.5.1, 4.5.2, 5.6, 5.7,5.9, 5.10, and 5.13;b) processing of custody signals as described in RFC 5050 sections 3.1, 4.2, 5.4, 5.4.1,5.4.2, 5.10.1, 5.10.2, 5.11, 5.12, 6.1, 6.1.2, and 6.3;c) node registration as defined in RFC 5050 section 3.3 and 5.16.CCSDS 734.2-R-1 Page 6-2 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONANNEX ACONVERGENCE LAYER ADAPTERS(NORMATIVE)A1INTRODUCTIONThis annex describes various Convergence Layer Adapters (CLAs) to support missionoperations both in space and for ground support. There are many possible convergencelayers to support the various communications interfaces with which the Bundle protocol mayinteract. This annex is in no manner comprehensive or rigorous but contains CCSDSsupported CLAs which have been demonstrated under various environments, have beenrequested to be included at the time of this writing, and appear applicable to CCSDS users.When a specific CLA appears to contradict the specification for that specific convergencelayer or the bundle protocol specification, the CLA will be assumed to be invalid.A2LTP CONVERGENCE LAYER ADAPTERA2.1 OVERVIEWThis subsection describes the mechanism for encapsulating Bundles in LTP blocks fortransmission to another bundle protocol agent. 1A2.2 ENCAPSULATION OF BUNDLES IN LTP BLOCKSWhen sending/receiving bundles using LTP at the convergence layer, bundles shall beencapsulated in LTP blocks as described in the following subsections.A2.3 CONGESTION CONTROL WITH LTP OVER UDPWhen the LTP Convergence Layer (LTPCL) protocol uses UDP as its underlying linkservice, measures should be taken to ensure that the traffic generated by the bundle protocolagent does not congest the network. This may be done by using LTPCL on a closed networkor a network with reserved bandwidth, or it may include using congestion control proceduressuch as those described in RFC 5405 (reference [7]) or as implemented in DCCP (RFC4340—reference [8]).1 Text in this annex subsection reflects text contained in Delay-Tolerant Networking LTP Convergence Layer(LTPCL) Adapter draft-burleigh-dtnrg-ltpcl-03.CCSDS 734.2-R-1 Page A-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONA2.4 RELIABLE TRANSMISSION VIA LTPFor reliable bundle transmission, bundles shall be encapsulated in LTP blocks containingonly red-part (reliable) data according to the Client Operations section (section 7) of RFC5326 (reference [9]). The LTP Client Service ID presented by the bundle protocol agent tothe LTP Service Data Aggregation service shall be the service ID for ‘Bundle Protocol’ asspecified in the SANA LTP Client Service ID Number Registry (reference [5]).A2.5 UNRELIABLE TRANSMISSION VIA LTPFor unreliable bundle transmission, bundles shall be encapsulated into LTP blocks containingonly green-part (unreliable) data. One Bundle shall be encapsulated in each LTP block withno leading or trailing bytes. The LTP Client Service ID shall be the service ID for ‘BundleProtocol’ as specified in the SANA LTP Client Service ID Number Registry (reference [5]).A3UDP CONVERGENCE LAYER ADAPTORA3.1 OVERVIEWThis subsection describes the mechanism for encapsulating Bundles in UDP Datagrams fortransmission to another bundle protocol agent.A3.2 ENCAPSULATION OF BUNDLES IN UDP DATAGRAMSWhen sending/receiving bundles using UDP at the convergence layer, bundles shall beencapsulated in UDP datagrams as follows:a) UDP checksums shall be enabled;b) each bundle shall be encapsulated into one UDP datagram with no additional bytes;c) it is recommended that all implementations use UDP port 4556/UDP;d) it is recommended that all implementations ensure that the traffic sent by the UDPconvergence layer adaptor does not adversely affect other traffic on the network;NOTE – Network characteristics can best be managed on a closed network or anetwork with reserved bandwidth, or the utilization of congestion controlprocedures as described in RFC 5405 (reference [7]) can be adopted.e) it is recommended that bundle protocol agents endeavor to send bundles of such asize as not to require fragmentation by the IP layer.CCSDS 734.2-R-1 Page A-2 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONNOTE – In practice this generally means keeping the size of the IP datagram(including the IP and UDP headers, plus the bundle) to less than 1500 bytes.When using UDP as the convergence layer protocol, bundles are limited to amaximum size of 65,535 bytes (including all of the bundle blocks, the 8-byteUDP header, and the IP header (20 bytes for IPv4, 40 bytes for IPv6).CCSDS 734.2-R-1 Page A-3 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONANNEX BEXTENDED CLASS OF SERVICE EXTENSION SPECIFICATION(NORMATIVE)B1INTRODUCTIONB1.1 OVERVIEWThis annex describes an extension to the DTN BP (reference [1]) that marks bundles withclass-of-service designators beyond those defined for the BP primary block. The extendedclass-of-service designators are an ‘ordinal’ number that provides fine-grained prioritizationof bundles, a ‘critical’ flag, a ‘best-efforts’ flag, and an optional flow label.B1.2 BACKGROUNDExtended Class of Service (ECOS) is an extension to the DTN BP that marks bundles withclass-of-service designators beyond those defined for the BP primary block.The bundle protocol specification defines a single designator for a bundle’s class of service:– Priority, a value in the range 0 through 2, with higher values indicating greaterurgency: 0 = ‘bulk’, 1 = ‘normal’, 2 = ‘expedited’. Priority level 3 is reserved forfuture use.For some applications, such as space flight operations, additional variation in class of servicemay be required:– Many more levels of priority may be needed, enabling more fine-grained control overthe precedence of user-selected application data types in the progress of bundlesthrough the network.– A way of indicating ‘emergency’ traffic may be needed. Emergency traffic is notmerely high-priority: it is so important that the user is willing to incur the networkoverhead of transmitting the bundle along every potential route to its destination,rather than only on the route that would normally be selected as the ‘best’ routeaccording to the applicable routing value function. This expedient ensures that thebundle arrives at its destination in the least possible time, regardless of howaccurately the routing system reckons end-to-end latency on any given route: thebundle arrives by whatever turns out to be the fastest route, as well as by all others.– There may be a need to request that all nodes forwarding the bundle use convergencelayerprotocols that do not perform retransmission upon detected loss of data. Thisdesignation may be important for bundles carrying application data for whichtimeliness of delivery is more important than certainty: retransmitted ‘old data’ mayCCSDS 734.2-R-1 Page B-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONbe a waste of bandwidth that could instead be used to convey new data of greatervalue, or the out-of-order arrival of retransmitted data may degrade the usefulness ofstreaming data such as audio or video.– There may be a need for an opaque ‘flow label’ that can be used by the application topass a variety of transmission control parameters to the convergence-layer protocol.The ECOS extension to Bundle Protocol is designed to provide these additional class-ofservicedesignators. This specification defines the BP extension block in which the ECOSservice class designators are conveyed and the procedures that shall be performed onorigination and reception of a bundle containing an ECOS block.B2ECOS BLOCK FORMATThe ECOS extension block shall conform to sections 4.5.2 and 4.6 of reference [1],constrained as follows:a) Block type code shall be as assigned by IANA.b) The following block processing control flag shall be set to 1:– Bit 0 - block shall be replicated in every fragment.NOTE – The setting of other block processing control flags, where not mandated bythe Bundle Protocol specification, is an implementation matter.c) The block shall contain no EID references.d) Block data length shall be 2 + N, where N is zero if the ECOS block contains no flowlabel (as described below) and is otherwise the length of the SDNV in which thatflow label is represented.e) The block data of the ECOS block shall comprise at least two and possibly three fields.f) The first field of the block data shall be an 8-bit ‘flags’ byte. The bits of the flagsbyte shall signify the following conditions:– The 0x01 bit, if True, shall indicate that the bundle is ‘critical’: the bundleprotocol agent is requested to forward one copy of the bundle along every paththat might get it to its destination.– The 0x02 bit, if True, shall indicate that the bundle is ‘streaming’: the bundleprotocol agent is requested to forward the bundle on a ‘best-efforts’ basis, withoutretransmission.– The 0x04 bit, if True, shall indicate that the ‘ordinal’ byte of this ECOS block(the byte immediately following the ‘flags’ byte) is followed by a numeric ‘flowlabel’ in SDNV representation.– All other bits of the ‘flags’ byte are reserved for future use.CCSDS 734.2-R-1 Page B-2 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONg) The ‘flags’ byte shall be followed by an 8-bit ‘ordinal’ byte, containing an unsigned‘ordinal’ number in the range 0-255. For a bundle whose standard class of service is 2(‘expedited’), the ordinal number shall indicate the relative priority of this bundleamong all other expedited bundles: ordinal value 100 indicates greater urgency thanordinal value 99, and so on. Ordinal value 255 is reserved for custody signals.NOTE – For a bundle whose standard class of service is not 2, the ordinal value has nosignificance.h) If the 0x04 bit of the ECOS block’s ‘flags’ byte is False then the ‘ordinal’ byte shallbe the last field of the block data. Otherwise, the third and final field of the blockdata shall be a numeric ‘flow label’ value in SDNV representation.NOTE – The significance of the flow label is an implementation matter. Notionally,the flow label is intended to be used to convey quality-of-service informationto the convergence-layer protocol adapter.B3ECOS BLOCK PROCEDURESB3.1 STRUCTURAL CONSTRAINTSB3.1.1 Whenever a bundle contains an ECOS block, the ECOS block shall precede thepayload block.B3.1.2No bundle shall ever contain more than one ECOS block.B3.1.3 If the ECOS block contains a flow label, then the 0x04 bit of the block’s ‘flags’byte shall be set to 1 (True) and the flow label shall be a numeric value represented as a validSDNV. Otherwise the 0x04 bit of the block’s flags byte shall be set to 0 (False).B3.1.4 The ordinal byte of the ECOS block shall contain an unsigned integer in the range0-255. If the bundle of which the ECOS block is a part is a custody signal, then the value ofthe ordinal byte shall be 255; otherwise, the value of the ordinal byte shall be in the range 0-254.B3.2 BUNDLE ORIGINATIONInclusion of an ECOS extension block in a newly originated bundle is optional; the decisionon whether or not to insert an ECOS block into a new bundle is an implementation matter. Inthe event that a new ECOS block is inserted into a forwarded bundle, the values of the blockdata fields of that ECOS block are likewise an implementation matter, provided that theyconform to this specification.CCSDS 734.2-R-1 Page B-3 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONNOTE – Some or all of those values might be communicated to the bundle protocol agentby the application on whose behalf the bundle is being originated. In this case,the manner in which the application communicates those values is likewise animplementation matter.B3.3 BUNDLE FORWARDINGB3.3.1 Inclusion of an ECOS extension block in a received bundle that is to be forwardedbut contains no ECOS block is optional; the decision on whether or not to insert a new ECOSblock into a forwarded bundle is an implementation matter. In the event that a new ECOSblock is inserted into a forwarded bundle, the values of the block data fields of that ECOSblock are likewise an implementation matter, provided that they conform to thisspecification.B3.3.2 The forwarding of a bundle that contains a valid ECOS block, whether locallyoriginated or locally inserted upon reception from another bundle protocol agent, shall beconstrained as follows:– If the 0x01 bit of the ECOS block’s flags byte is set to 1 (‘critical’):• Exactly one copy of the bundle shall be forwarded to every neighboring node thathas some plausible prospect of being able to forward the bundle toward its finaldestination without returning it to the local node, a determination that is a matterleft to the bundle protocol agent’s route computation mechanism.NOTE – A conformant bundle protocol agent can at any time arbitrarily decidethat there is only one neighboring node that has some plausible prospectof being able to forward a given bundle toward its final destinationwithout returning it to the local node, in effect disabling this feature ofECOS. Such an implementation decision should not be taken lightly,however, as it might put network assets at risk; this expedient should beavoided unless necessary to preserve the continued operation of thebundle protocol agent.• The bundle shall be queued for transmission as if its class of service were 2(‘expedited’) and its ordinal value were 254, regardless of the actual values ofthese fields.• The bundle shall not be reforwarded in response to custody refusal, the expirationof a custody transfer timer, the presence of a routing loop in the network, or anyother condition. The manner in which this constraint is enforced is animplementation matter.NOTES1 Such reforwarding could result in unbounded bundle transmission explosions.CCSDS 734.2-R-1 Page B-4 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATION2 One possible implementation approach is to manage a list of the IDs andexpiration times of all critical bundles received, removing bundles from thelist only as the associated expiration times are reached; since ‘critical’ bundlesshould be issued rarely; managing such a list should not be a severeprocessing burden.– If the 0x02 bit of the ECOS block’s flags byte is set to 1 (‘streaming’), then thebundle protocol agent shall forward the bundle by invoking an adapter for aconvergence layer protocol that does NOT perform retransmission of data lost intransit, provided the bundle protocol agent has access to such a convergence layeradapter; otherwise, this flag shall be ignored.NOTE – Inability to accommodate this request for streaming transmission may causeapplication data units to arrive out of transmission order at the destination(possibly degrading application performance) and/or cause transmissionbandwidth to be wasted on unnecessary retransmission, reducing the effectivethroughput of the network.– If the bundle’s class of service is 2 (expedited), then:• The effective ordinal byte value of a given bundle is zero if the bundle has noECOS block; otherwise it is the ordinal byte value in the bundle’s ECOS block.• The bundle protocol agent shall forward this bundle only after forwarding all otherbundles that are to be forwarded to the same node and have class of service 2 andhave effective ordinal byte value that is higher than or equal to the ECOS block’sordinal byte value.• The bundle protocol agent shall forward this bundle before forwarding any otherbundle that is to be forwarded to the same node and either (a) has class of service 2and effective ordinal byte value lower than the ECOS block’s ordinal byte valueor (b) has class of service less than 2.– The ECOS block of a received bundle that is to be forwarded to another node shallnot be deleted from the bundle.B4BUNDLE DELIVERYWhen a bundle that contains an ECOS block is delivered to its final destination, the values ofECOS block fields shall have no impact on bundle delivery procedures.B5DISCUSSION—SECURITY CONSIDERATIONSThe origination of bundles whose ECOS blocks have the ‘critical’ flag set to True couldincrease the impact of a denial of service attack. As with all such attacks, probably the bestavailable defense is to require valid Bundle Authentication Blocks on all received bundles.CCSDS 734.2-R-1 Page B-5 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONB6DISCUSSION—IANA CONSIDERATIONSThis specification requests that IANA allocate a codepoint from the Bundle Block Typesregistry defined in RFC 6255 (reference [10]) for the ‘Extended Class of Service Block’defined in this annex.CCSDS 734.2-R-1 Page B-6 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONANNEX CBP MANAGED INFORMATION(NORMATIVE)C1BASIC REQUIREMENTSEach BP node shall support sets of managed information that represents the state of the nodeat a particular time. The minimal set of such information contains those data items identifiedby RFC 5050 and collected in this annex.BP nodes shall support five types of managed information:a) bundle state information;b) error and reporting information;c) registration information;d) convergence-layer information;e) general configuration information.In addition to required information, each BP node may choose to provide supplementaryinformation. Each identified managed information item shall identify whether its collectionand accurate reporting is required or recommended.NOTES1 Representation of, and mechanisms for access to, managed information items will beimplementation matters.2 Individual pieces of managed information may describe related events. Care must betaken when modifying these data to ensure that related data sets remain coherent. Forexample, when a cumulative counter ‘rolls over’ or is otherwise reset, relatedcounters should also be reset.C2BUNDLE STATE INFORMATIONC2.1 OVERVIEWBundles do not have a natural end state within a node: they are forwarded, delivered, ordeleted. As such, bundles at rest within a node exist pending a particular action. This set ofmanaged information describes these bundle states and the transitions between them.CCSDS 734.2-R-1 Page C-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONC2.2 SUPPORTED TYPES OF BUNDLE STATE INFORMATIONBP nodes shall support the bundle state information itemized in table C-1.Table C-1: Bundle State InformationManagedInformationItem Description Req?BundlesRetained forForwardingBundlesRetained forTransmissionBundlesRetained forCustodyAcceptanceBundlesRetained forReassemblyBulk BundlesSourcedNormal BundlesSourcedExpeditedBundlesSourcedBulk BundlesQueuedNormal BundlesQueuedRetention ConstraintsThe number of bundles/bytes associated withthe retention constraint forward pending atthis node.The number of bundles/bytes associated withthe retention constraint dispatch pending atthis node.The number of bundles/bytes associated withthe retention constraint custody accepted atthis node.The number of bundles/bytes associated withthe retention constraint reassembly pendingat this node.Priority CountersThe number of bundles/bytes generated by thisnode with the bulk priority.The number of bundles/bytes generated by thisnode with the normal priority.The number of bundles/bytes generated by thisnode with the expedited priority.The number of bundles/bytes with the bulkpriority currently resident on this node.The number of bundles/bytes with the normalpriority currently resident on this node.Cumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesExpeditedBundlesQueuedThe number of bundles/bytes with theexpedited priority currently resident on thisnode.Cumulative BytesCumulative BundlesYesYesBundle ProcessingFragmentationNumber ofFragmentsThe number of bundles that have beenfragmented by this node.The number of fragments created by thisbundleCumulative BundlesCumulativeFragmentsYesYesCCSDS 734.2-R-1 Page C-2 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONC3NODE ERROR AND REPORTING INFORMATIONC3.1 OVERVIEWNodes generate reports in response to both anomalous and special events. This set ofmanaged information reports on the number of errors and reports constructed at the node.C3.2 SUPPORTED TYPES OF ERROR AND REPORTING INFORMATIONBP nodes shall support the error and reporting information itemized in table C-2.Table C-2: Error and Reporting InformationManagedInformationItemDescriptionReq?Sent Status ReportsReceptionReportsThe number of bundle reception reports sentby this node.Cumulative ReportsYesCustodyAcceptedReportsThe number of custody acceptance reportssent by this node.Cumulative ReportsYesForwardingReportsThe number of bundle forwarding reportssent by this node.Cumulative ReportsYesCustodySuccessReportsThe number of custody success reports sentby this node.Cumulative ReportsYesDeliveryReportsThe number of bundle delivery reports sentby this node.Cumulative ReportsYesDeletionReportsThe number of bundle deletion reports sentby this node.Cumulative ReportsYesNo Info CodesThe number of status reports sent with the Noadditional information reason code.Cumulative ReportsYesExpired CodesThe number of status reports sent with theLifetime expired reason code.Cumulative ReportsYesUni-forwardedCodesThe number of status reports sent with theForwarded over unidirectional link reasoncode.Cumulative ReportsYesCancelledCodesThe number of status reports sent with theTransmission canceled reason code.Cumulative ReportsYesNo StorageCodesThe number of status reports sent with theDepleted Storage reason code.Cumulative ReportsYesCCSDS 734.2-R-1 Page C-3 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONManagedInformationItemDescriptionReq?Bad EID CodesThe number of status reports sent with theDestination endpoint ID unintelligiblereason code.Cumulative ReportsYesNo RouteCodesThe number of status reports sent with the Noknown route to destination from herereason code.Cumulative ReportsYesNo TimelyContact CodesThe number of status reports sent with the Notimely contact with next node on routereason code.Cumulative ReportsYesBad BlockCodesThe number of status reports sent with theBlock unintelligible reason code.Cumulative ReportsYesBundle Processing ErrorsFailed CustodyTransfersThe number of incoming bundles/bytes whoserequest for custody was not successful at thisnode.Cumulative BytesCumulative BundlesYesYesFailed ForwardsThe number of bundles/bytes that haveexperienced a forwarding failure at this node.Cumulative BytesCumulative BundlesYesYesAbandonedDeliveryThe number of bundles/bytes whose deliveryhas been abandoned at this node.Cumulative BytesCumulative BundlesYesYesDiscardedBundlesThe number of bundles/bytes discarded at thisnode.Cumulative BytesCumulative BundlesYesYesC4DISCUSSION—REGISTRATION INFORMATIONC4.1 OVERVIEWNodes register with one of more endpoints at the bundle protocol agent. These registrationsallow for the reception and processing of bundles in the context of the endpoints to whichthey are addressed.C4.2 SUPPORTED TYPES OF REGISTRATION INFORMATIONBP nodes shall support the registration information itemized in table C-3.CCSDS 734.2-R-1 Page C-4 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONTable C-3: Registration InformationManagedInformationItemDescriptionReq?EndpointIdentifierActivity StateSingleton StateDefault FailureActionReceivedBundlesSent BundlesForwardedBundlesDuplicateBundlesBulk BundlesReceivedNormal BundlesReceivedExpeditedBundlesReceivedReceptionReportsCustodyAcceptedReportsForwardingReportsCustodySuccess ReportsIdentity InformationThe Endpoint ID of this registered endpoint.The current state of the EID, at the time the managed information wasqueried.One of: ACTIVE or PASSIVE.Whether this EID is a singleton EID.One of: YES or NO.The default action to be taken when delivery is not possible.One of: ABANDON or DEFER.Bundle Traffic InformationThe number of bundles/bytes received by thisnode through this endpoint.The number of bundles/bytes sent by this nodethrough this endpoint.The number of bundles/bytes forwarded by thisnode through this endpoint.The number of duplicate bundles/bytes receivedby this node through this endpoint.Priority CountersThe number of bundles/bytes received by thisnode, through this endpoint, with the bulkpriority.The number of bundles/bytes generated by thisnode, through this endpoint, with the normalpriority.The number of bundles/bytes generated by thisnode, through this endpoint, with the expeditedpriority.Received Status ReportsThe number of bundle reception reportsreceived by this node through this endpoint.The number of custody acceptance reportsreceived by this node through this endpoint.The number of bundle forwarding reportsreceived by this node through this endpoint.The number of custody success reportsreceived by this node through this endpoint.Cumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative BytesCumulative BundlesCumulative ReportsCumulative ReportsCumulative ReportsCumulative ReportsYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesCCSDS 734.2-R-1 Page C-5 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONManagedInformationItemDescriptionReq?Delivery Reports The number of bundle delivery reportsreceived by this node through this endpoint.Deletion Reports The number of bundle deletion reportsreceived by this node through this endpoint.No Info CodesExpired CodesUni-forwardedCodesThe number of status reports received with theNo additional information reason code at thisnode through this endpoint.The number of status reports received with theLifetime expired reason code at this nodethrough this endpoint.The number of status reports received with theForwarded over unidirectional link reasoncode at this node through this endpoint.Cancelled Codes The number of status reports received with theTransmission canceled reason code at thisnode through this endpoint.No StorageCodesBad EID CodesThe number of status reports received with theDepleted Storage reason code at this nodethrough this endpoint.The number of status reports received with theDestination endpoint ID unintelligible reasoncode at this node through this endpoint.No Route Codes The number of status reports received with theNo known route to destination from herereason code at this node through this endpoint.No TimelyContact CodesThe number of status reports received with theNo timely contact with next node on routereason code at this node through this endpoint.Bad Block Codes The number of status reports received with theBlock unintelligible reason code at this nodethrough this endpoint.Cumulative ReportsCumulative ReportsCumulative ReportsCumulative ReportsCumulative ReportsCumulative ReportsCumulative ReportsCumulative ReportsCumulative ReportsCumulative ReportsCumulative ReportsYesYesYesYesYesYesYesYesYesYesYesC5DISCUSSION—CONVERGENCE LAYER INFORMATIONC5.1 OVERVIEWNodes register with one or more convergence layer adapters (CLAs). These CLAs allow thebundle protocol agent to receive bundles from a variety of local, supported data links.C5.2 SUPPORTED TYPES OF CLA INFORMATIONBP nodes shall support the CLA Information itemized in table C-4.CCSDS 734.2-R-1 Page C-6 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONTable C-4: CLA InformationManagedInformationItemDescriptionIdentity InformationReq?CLA TypeThe type of convergence layer adapter (typically the name of theprotocol used by the adapter)CLA Name The locally assigned name of the CLA. YesCLA ID A unique identifier for this CLA at this node. YesDirectionalityReceivedBundlesSent BundlesThe way in which the CLA may interface with the BPA.One of: INBOUND ONLY, OUTBOUND ONLY, BIDIRECTIONALBundle Traffic InformationThe number of bundles/bytes received by thisCLA and passed up to the node.The number of bundles/bytes sent by this CLAafter being received by the node.Cumulative BytesCumulative BundlesCumulative BytesCumulative BundlesYesYesYesYesYesYesCCSDS 734.2-R-1 Page C-7 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONANNEX DPROTOCOL IMPLEMENTATION CONFORMANCESTATEMENT PROFORMA(NORMATIVE)D1OVERVIEWThis annex provides the Protocol Implementation Conformance Statement (PICS)Requirements List (PRL) for CCSDS-compliant implementations of BP. The PICS for animplementation is generated by completing the PRL in accordance with the instructionsbelow. An implementation shall satisfy the mandatory conformance requirements of the basestandards referenced in the PRL.An implementation’s completed PRL is called the PICS. The PICS states which capabilitiesand options of the protocol have been implemented. The following can use the PICS:a) the protocol implementer, as a checklist to reduce the risk of failure to conform to thestandard through oversight;b) the supplier and acquirer or potential acquirer of the implementation, as a detailedindication of the capabilities of the implementation, stated relative to the commonbasis for understanding provided by the standard PICS proforma;c) the user or potential user of the implementation, as a basis for initially checking thepossibility of interworking with another implementation (it should be noted that,while interworking can never be guaranteed, failure to interwork can often bepredicted from incompatible PICSes);d) a protocol tester, as the basis for selecting appropriate tests against which to assessthe claim for conformance of the implementation.D2INSTRUCTIONS FOR COMPLETING THE PRLAn implementer shows the extent of compliance to the protocol by completing the PRL; thatis, compliance to all mandatory requirements and the options that are not supported areshown. The resulting completed PRL is called a PICS. In the Support column, each responseshall be selected either from the indicated set of responses, or it shall comprise one or moreparameter values as requested. If a conditional requirement is inapplicable, N/A should beused. If a mandatory requirement is not satisfied, exception information must be supplied byentering a reference Xi, where i is a unique identifier, to an accompanying rationale for thenoncompliance. When the requirement is expressed as a two-character combination (asdefined below), the response shall address each element of the requirement; e.g., for therequirement ‘MO’, the possible compliant responses are ‘YY’ or ‘YN’.CCSDS 734.2-R-1 Page D-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIOND3NOTATIOND3.1 The following symbols are used in the PRL to indicate the status of features:SymbolMMandatoryTable D-1: PICS NotationMeaningM. Support of every item of the group labeled by the same number required,but only one is active at a timeO OptionalO. Optional, but support of at least one of the group of options labeled by thesame numeral is requiredC Conditional-- Non-applicable field/function (i.e., logically impossible in the scope of thePRL)I Out of scope of the PRL (left as an implementation choice)X Excluded or prohibitedD3.2 Two-character combinations may be used for dynamic conformance requirements. Inthis case, the first character refers to the static (implementation) status, and the second refersto the dynamic (use) status; thus ‘MO’ means ‘mandatory to be implemented, optional to beused’.D3.3 The following notations for conditional status shall be used:Table D-2: PICS Conditional Status NotationSymbol::::::MeaningThis notation introduces a group of items, all of which are conditional on.This notation introduces a single item which is conditional on .This notation indicates that the status following it applies only when the PICSstates that the features identified by the index are supported. In the simplestcase, is the identifying tag of a single PRL item. The symbol also may be a Boolean expression composed of several indices.This notation indicates that the associated clause should be completed.CCSDS 734.2-R-1 Page D-2 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIOND3.3.1 Either of the predicate forms may identify a protocol feature, or a Booleancombination of predicates. (‘^’ is the symbol for logical negation, ‘|’ is the symbol for logicalOR, and ‘&’ is the symbol for logical AND.)D3.4 The following notations shall be used in the ‘Protocol Feature’ column.Table D-3: Symbols for PICS ‘Protocol Feature’ ColumnSymbolMeaningDenotes the receiving system.Denotes the transmitting system.D3.5 The following symbols shall be used in the ‘Support’ column of the PICS.Table D-4: Symbols for PICS ‘Support’ ColumnSymbolYNN/AMeaningYes, the feature is supported by the implementation.No, the feature is not supported by the implementation.The item is not applicable.D4REFERENCED BASE STANDARDSD4.1 The base standards referenced in the PRL shall be:a) CCSDS BP (this document);b) RFC 5050 (reference [1]).D4.2 In the tables below, the notation in the Reference column combines one of the shortformdocument identifiers above (e.g., CCSDS-BP) with applicable subsection numbers inthe referenced document. RFC numbers are used to facilitate reference to subsections withinthe Internet specifications.CCSDS 734.2-R-1 Page D-3 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIOND5GENERAL INFORMATIOND5.1 IDENTIFICATION OF PICSRef Question Response1 Date of Statement (DD/MM/YYYY)2 PICS serial number3 System conformance statement crossreferenceD5.2 IDENTIFICATION OF IMPLEMENTATION UNDER TEST (IUT)Ref Question Response1 Implementation name2 Implementation version3 Name of hardware (machine) used intest4 Version of hardware (machine) used intest5 Name of operating system used duringtest6 Version of operating system usedduring test7 Additional configuration informationpertinent to the test8 Other informationD5.3 IDENTIFICATIONRef Question Response1 Supplier2 Point of contact for queries3 Implementation name(s) and version(s)4 Other information necessary for fullidentification (e.g., name(s) andversion(s) for machines and/oroperating systemsCCSDS 734.2-R-1 Page D-4 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIOND5.4 PROTOCOL SUMMARYRef Question Response1 Protocol version2 Addenda implemented3 Amendments implemented4 Have any exceptions been required?NOTE – A YES answer means thatthe implementation does notconform to the protocol.Non-supported mandatorycapabilities are to beidentified in the PICS, withan explanation of why theimplementation is nonconforming.5 Date of statement (DD/MM/YYYY)a) Yesb) NoD6BASIC REQUIREMENTSItembaseBPbaseCBHECBHE_namingbpECOSbpTimeCbheNodeNoProtocolFeature Reference Status SupportBase BP spec fromRFC 5050 withmodifications andoptions asspecified insection 3 of thisdocumentBase CBHE specfrom RFC 6260except as noted insection 3 of thisdocumentCBHE for ‘IPN’:EID NamingSchemeExtended Class ofService Block asdefined inreference [4]Precision ofonboard timeCBHE Nodenumber is greaterthan zeroRFC 5050; this document:section 3RFC 6260; this document: 3.2RFC 6260; this document: 3.2This document: 3.3, B2, B3RFC 5050 section 6.1; thisdocument: 3.4This document: 3.5.2MMMOMOMCCSDS 734.2-R-1 Page D-5 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONItemCbheService NobpAggregrationbpInitRegistrationbpTerm RegistrationbpSwitchRegistrationbpTransmitBundlebpCancelTransmissionbpPollRegistrationProtocolFeature Reference Status SupportValue shall begreater than zeroand less than 2*21-1BP Aggregationby LTPBP registrationinitializationserviceBP terminateinitializationserviceBP switchregistration stateserviceBP transmit abundle to anidentified bundleendpoint serviceBP cancel atransmissionservicePoll a registrationthat is in passivestatebpDeliverRecvdBundle Deliver receivedbundle serviceThis document: 3.5.5, 3.6This document: 3.7This document: 4.1This document: 4.1This document: 4.1This document: 4.1This document: 4.1This document: 4.1This document: 4.1bpBundle Bundle structure RFC 5050: sections 3.1, 4.0,4.2, 4.4, and 5.8.8bpBlockbpBlockPayloadSDNVSDNVLargeValuePrimary BundleBlock structurePayload BundleBlock StructureSelf-DelimitingNumberic ValuesSDNV encodedvalue larger than(2^64-1)RFC 5050: sections 4.1, 4.5,4.5.1, 4.5.2RFC 5050: sections 3.1, 4.5,4.5.3, and 4.7RFC 5050: section 4.1RFC 5050: section 4.1bpPriority Bundle Priority RFC 5050: section 4.2; thisdocument: annex BbpAcceptbpTransmissionbpForwardBundleAcceptanceBundleTransmissionServiceBundleForwardingRFC 5050: sections 4.2, 4.5.1,4.5.2, 5.6, 5.7, 5.9, 5.10, 5.13RFC 5050: sections 3.3, 4.3,5.15, 5.2RFC 5050: sections 4.2, 5.1,5.3, 5.4, 5.4.1, 5.4.2, 5.5MOMMMMMMMM::M::M::M::O::M::M::M::MCCSDS 734.2-R-1 Page D-6 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONItembpDeleteDictionaryArraybpExtnBlkbpBSPBlockAdmin RecordStructureAdmin RecordProcessingAdmin RecordGenerationConnectivityProtocolFeature Reference Status SupportBundle deletionproceduresDictionary bytearrayImplementationsupports extensionblocksBundle Securityextension blockAdministrativeRecord DefinitionAdministrativeRecord ProcessingAdministrativeRecord GenerationIntermittentconnectivityconditionsRFC 5050: sections 3.1, 4.2,5.13, and 5.14RFC 5050: sections 4.4 and 4.7RFC 5050: section 4.6RFC 5050: section 3.3RFC 5050: sections 5.1, 6.0,6.1, and 6.2RFC 5050: sections 6.1.1, 6.1.2,and 6.3RFC 5050: sections 5.1 and 6.2RFC 5050: section 1::MM::M::OLateBinding Late Binding RFC 5050: section 1 MbpDeliveryFailCustodySigProcEIDRegisterNodeEIDTerminateNodeEIDSwitchNodeEIDPollNodeEIDFormatBundle deliveryfailureCustody SignalProcessingCustodycountdown timerCustody transferfailure actionRegistration ofnode in anendpointTermination ofnode in anendpointSwitching noderegistrationbetween Active &PassivePolling noderegistrationEIDs may beexpressed in someinternationalizedmanner (IRI)RFC 5050: section 1This document: 6.2.1.3b)RFC 5050: section 3.3RFC 5050: section 3.3.RFC 5050: section 3.3RFC 5050: sections 3.3 and5.16RFC 5050: section 4.4MMMMMMOOMMMMOCCSDS 734.2-R-1 Page D-7 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONItemBlkFwdErrorbpSecuritybpSecurityBABbpSecurityPSBbpSecurityPCBbpSecurityExtMIB_stateMIB_errorsMIB_registrationMIB_CL_infoMIB_ConfigProtocolFeature Reference Status SupportBlk forward w/oprocessing flagmay be optionallycleared by anothernode that receivesthe bundle and canprocess that blockRemoval ofcurrent custodianEID scheme nameand/or SP fromdictionaryUse of BundleSecurity ProtocolBundleAuthenticationBlockPayload SecurityBlockPayloadConfidentialityBlockExtension SecurityBlockFragmentation(Prohibit?)Bundle StateInformationError andReportingInformationRegistrationInformationConvergence-Layer InformationGeneralConfigurationInformationRFC 5050: section 4.6This document: E1.2; RFC6257 (Bundle SecurityProtocol)This document: E1.2; RFC6257 (Bundle SecurityProtocol)This document: E1.2; RFC6257 (Bundle SecurityProtocol)This document: E1.2; RFC6257 (Bundle SecurityProtocol)This document: E1.2; RFC6257 (Bundle SecurityProtocol)This document: table C-1This document: table C-2This document: table C-3This document: table C-4This document: annex C::OOO::O::O::O::OM:O?MMMMMCCSDS 734.2-R-1 Page D-8 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONANNEX ESECURITY, SANA, AND PATENT CONSIDERATIONS(INFORMATIVE)E1SECURITYE1.1 OVERVIEWThe bundle protocol as defined by RFC 5050 has factored in security from the outset of itsdesign. The necessary security architecture and services have been developed in anaccompanying RFC, the Bundle Security Protocol specification. Because BP was designedfor a resource constrained environment, it is essential to ensure that only those entitiesauthorized to utilize those resources be allowed to do so.Also, because of the long latencies and delays in the constrained environments which utilizeBP, integrity and confidentiality are of primary importance. Without adequate protections inplace to ensure that data integrity and confidentiality are maintained, the difficulty inidentifying compromised data will be compounded due to the unique environment of CCSDSmissions.E1.2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENTThe BP implementation (reference [1]) contains a security section (8) which addressesnecessary implementations to protect bundle protocol data and recommends the use of theBundle Security Protocol (BSP) of RFC 6257. Four types of security blocks are defined inRFC 6257:a) Bundle Authentication Blocks (BAB) ensure the authenticity and integrity of bundleson a hop-by-hop basis between bundle nodes.b) Payload Integrity Blocks (PIBs) assure authenticity and integrity of the payload fromthe PIB security-source to the PIB security-destination.c) Payload Confidentiality Blocks (PCBs) indicate that the associated payload has beenencrypted, and provide for confidential communications between the PCB securitysourceand the PCB security-destination.d) Extension Security Blocks (ESBs) provide security for non-payload blocks in abundle.NOTE – Section 8 of RFC 5050 also discusses the limitations of its securitymechanisms and recommends the use of BSP.CCSDS 734.2-R-1 Page E-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONE1.3 AUDITING OF RESOURCE USAGENo mechanisms are defined in this specification to audit or assist with the auditing ofresource usage by the protocol.E1.4 POTENTIAL THREATS AND ATTACK SCENARIOSNo potential threat or attacks scenarios are discussed.E1.5 CONSEQUENCES OF NOT APPLYING SECURITY TO THETECHNOLOGYBy not applying the native security of the BP protocol and the extended security of BSPallowed by BP, the system must rely on security measures provided at the CLA interfaces.For space applications these may be non-existent or merely physical because of the lack ofintegration between payload and ground systems interfaces. If no security is applied at theBP or lower layers, then applications may be open to man-in-the middle attacks, replayattacks, or a general loss of integrity of transported bundles.E2SANA CONSIDERATIONSThe recommendations of this document request SANA to create the following registriesbased on the recommendation of 3.5:a) The registry named Bundle Protocol Compressed Bundle Header Encoding NodeNumbers which consists of a table of parameters:1) the initial registry values are not defined;2) the registration rule for new values of this registry requires no engineeringreview, but the request must come from the official representative of a spaceagency, member of the CCSDS;b) the registry named Bundle Protocol Compressed Bundle Header Encoding ServiceNumbers which consists of a table of parameters:1) limited initial registry values are defined;2) the registration rule for new values of this registry requires an officialrepresentative of a space agency member of the CCSDS request followed byexpert CESG review,E3PATENT CONSIDERATIONSThere are no known patents covering the Bundle Protocol as described in this document andits normative references.CCSDS 734.2-R-1 Page E-2 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONANNEX FINFORMATIVE REFERENCES(INFORMATIVE)[F1] Rationale, Scenarios, and Requirements for DTN in Space. Report Concerning Space DataSystem Standards, CCSDS 734.0-G-1. Green Book. Issue 1. Washington, D.C.: CCSDS,August 2010.[F2] Organization and Processes for the Consultative Committee for Space Data Systems. CCSDSA02.1-Y-3. Yellow Book. Issue 3. Washington, D.C.: CCSDS, July 2011.CCSDS 734.2-R-1 Page F-1 February 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CCSDS BUNDLE PROTOCOL SPECIFICATIONANNEX GABBREVIATIONS AND ACRONYMS(INFORMATIVE)TermAABABBPBPABSPCBHECLADTNECOSEIDESBIANAIPIRTFMIBOSIPICSPCBPDUPIBPRLRFCSANASDNVSDUMeaningApplication AgentBundle Authentication BlockBundle ProtocolBundle Protocol AgentBundle Security ProtocolCompressed Bundle Header EncodingConvergence Layer AdapterDelay Tolerant NetworkExtended Class of ServiceEndpoint IDentifierExtension Security BlockInternet Assigned Numbers AuthorityInternet ProtocolInternet Task Research Task ForceManagement Information BaseOpen Systems InterconnectionProtocol Implementation Conformance StatementPayload Confidentiality BlockPayload Data UnitPayload Integrity BlockPICS Requirement ListRequest For CommentSpace Assigned Numbers AuthoritySelf-Delimiting Numeric ValuesService Data UnitCCSDS 734.2-R-1 Page G-1 February 2012