idnits 2.17.1 draft-ietf-dtn-bpbis-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2019) is 1650 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5050' is defined on line 2361, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BPSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRC16' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRC32C' -- Possible downref: Non-RFC (?) normative reference: ref. 'EPOCH' ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay-Tolerant Networking Working Group S. Burleigh 2 Internet Draft JPL, Calif. Inst. Of Technology 3 Intended status: Standards Track K. Fall 4 Expires: April 20, 2020 Roland Computing Services 5 E. Birrane 6 APL, Johns Hopkins University 7 October 18, 2019 9 Bundle Protocol Version 7 10 draft-ietf-dtn-bpbis-15.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 20, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 This Internet Draft presents a specification for Bundle Protocol, 53 adapted from the experimental Bundle Protocol specification 54 developed by the Delay-Tolerant Networking Research group of the 55 Internet Research Task Force and documented in RFC 5050. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Conventions used in this document..............................5 61 3. Service Description............................................5 62 3.1. Definitions...............................................5 63 3.2. Discussion of BP concepts.................................9 64 3.3. Services Offered by Bundle Protocol Agents...............12 65 4. Bundle Format.................................................12 66 4.1. BP Fundamental Data Structures...........................13 67 4.1.1. CRC Type............................................13 68 4.1.2. CRC.................................................13 69 4.1.3. Bundle Processing Control Flags.....................14 70 4.1.4. Block Processing Control Flags......................15 71 4.1.5. Identifiers.........................................16 72 4.1.5.1. Endpoint ID....................................16 73 4.1.5.2. Node ID........................................17 74 4.1.6. DTN Time............................................18 75 4.1.7. Creation Timestamp..................................19 76 4.1.8. Block-type-specific Data............................20 77 4.2. Bundle Representation....................................20 78 4.2.1. Bundle..............................................20 79 4.2.2. Primary Bundle Block................................20 80 4.2.3. Canonical Bundle Block Format.......................23 81 4.3. Extension Blocks.........................................23 82 4.3.1. Previous Node.......................................24 83 4.3.2. Bundle Age..........................................24 84 4.3.3. Hop Count...........................................25 85 5. Bundle Processing.............................................25 86 5.1. Generation of Administrative Records.....................26 87 5.2. Bundle Transmission......................................27 88 5.3. Bundle Dispatching.......................................27 89 5.4. Bundle Forwarding........................................27 90 5.4.1. Forwarding Contraindicated..........................29 91 5.4.2. Forwarding Failed...................................29 92 5.5. Bundle Expiration........................................30 93 5.6. Bundle Reception.........................................30 94 5.7. Local Bundle Delivery....................................31 95 5.8. Bundle Fragmentation.....................................32 96 5.9. Application Data Unit Reassembly.........................33 97 5.10. Bundle Deletion.........................................34 98 5.11. Discarding a Bundle.....................................34 99 5.12. Canceling a Transmission................................34 100 6. Administrative Record Processing..............................34 101 6.1. Administrative Records...................................34 102 6.1.1. Bundle Status Reports...............................35 103 6.2. Generation of Administrative Records.....................38 104 7. Services Required of the Convergence Layer....................39 105 7.1. The Convergence Layer....................................39 106 7.2. Summary of Convergence Layer Services....................39 107 8. Implementation Status.........................................39 108 9. Security Considerations.......................................41 109 10. IANA Considerations..........................................42 110 10.1. Bundle Block Types......................................42 111 10.2. Primary Bundle Protocol Version.........................43 112 10.3. Bundle Processing Control Flags.........................44 113 10.4. Block Processing Control Flags..........................45 114 10.5. Bundle Status Report Reason Codes.......................46 115 10.6. URI scheme type codes...................................47 116 10.7. New URI scheme "dtn"....................................48 117 10.8. Change status of URI scheme "ipn".......................50 118 11. References...................................................50 119 11.1. Normative References....................................50 120 11.2. Informative References..................................51 121 12. Acknowledgments..............................................52 122 13. Significant Changes from RFC 5050............................52 123 Appendix A. For More Information.................................53 124 Appendix B. CDDL expression......................................54 126 1. Introduction 128 Since the publication of the Bundle Protocol Specification 129 (Experimental RFC 5050) in 2007, the Delay-Tolerant Networking (DTN) 130 Bundle Protocol has been implemented in multiple programming 131 languages and deployed to a wide variety of computing platforms. 132 This implementation and deployment experience has identified 133 opportunities for making the protocol simpler, more capable, and 134 easier to use. The present document, standardizing the Bundle 135 Protocol (BP), is adapted from RFC 5050 in that context. 136 Significant changes from the Bundle Protocol specification defined 137 in RFC 5050 are listed in section 13. 139 This document describes version 7 of BP. 141 Delay Tolerant Networking is a network architecture providing 142 communications in and/or through highly stressed environments. 143 Stressed networking environments include those with intermittent 144 connectivity, large and/or variable delays, and high bit error 145 rates. To provide its services, BP may be viewed as sitting at the 146 application layer of some number of constituent networks, forming a 147 store-carry-forward overlay network. Key capabilities of BP 148 include: 150 . Ability to use physical motility for the movement of data 151 . Ability to move the responsibility for error control from one 152 node to another 153 . Ability to cope with intermittent connectivity, including cases 154 where the sender and receiver are not concurrently present in 155 the network 156 . Ability to take advantage of scheduled, predicted, and 157 opportunistic connectivity, whether bidirectional or 158 unidirectional, in addition to continuous connectivity 159 . Late binding of overlay network endpoint identifiers to 160 underlying constituent network addresses 162 For descriptions of these capabilities and the rationale for the DTN 163 architecture, see [ARCH] and [SIGC]. 165 BP's location within the standard protocol stack is as shown in 166 Figure 1. BP uses underlying "native" transport and/or network 167 protocols for communications within a given constituent network. 169 The interface between the bundle protocol and a specific underlying 170 protocol is termed a "convergence layer adapter". 172 Figure 1 shows three distinct transport and network protocols 173 (denoted T1/N1, T2/N2, and T3/N3). 175 +-----------+ +-----------+ 176 | BP app | | BP app | 177 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 178 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 179 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 180 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 181 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 182 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 183 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 184 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 185 +-----------+ +-------------+ +-------------+ +-----------+ 186 | | | | 187 |<---- A network ---->| |<---- A network ---->| 188 | | | | 190 Figure 1: The Bundle Protocol in the Protocol Stack Model 192 This document describes the format of the protocol data units 193 (called "bundles") passed between entities participating in BP 194 communications. 196 The entities are referred to as "bundle nodes". This document does 197 not address: 199 . Operations in the convergence layer adapters that bundle nodes 200 use to transport data through specific types of internets. 201 (However, the document does discuss the services that must be 202 provided by each adapter at the convergence layer.) 203 . The bundle route computation algorithm. 204 . Mechanisms for populating the routing or forwarding information 205 bases of bundle nodes. 206 . The mechanisms for securing bundles en route. 207 . The mechanisms for managing bundle nodes. 209 Note that implementations of the specification presented in this 210 document will not be interoperable with implementations of RFC 5050. 212 2. Conventions used in this document 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 216 "OPTIONAL" in this document are to be interpreted as described in 217 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 218 capitals, as shown here. 220 3. Service Description 222 3.1. Definitions 224 Bundle - A bundle is a protocol data unit of BP, so named because 225 negotiation of the parameters of a data exchange may be impractical 226 in a delay-tolerant network: it is often better practice to "bundle" 227 with a unit of application data all metadata that might be needed in 228 order to make the data immediately usable when delivered to the 229 application. Each bundle comprises a sequence of two or more 230 "blocks" of protocol data, which serve various purposes. 232 Block - A bundle protocol block is one of the protocol data 233 structures that together constitute a well-formed bundle. 235 Application Data Unit (ADU) - An application data unit is the unit 236 of data whose conveyance to the bundle's destination is the purpose 237 for the transmission of some bundle that is not a fragment (as 238 defined below). 240 Bundle payload - A bundle payload (or simply "payload") is the 241 content of the bundle's payload block. The terms "bundle content", 242 "bundle payload", and "payload" are used interchangeably in this 243 document. For a bundle that is not a fragment (as defined below), 244 the payload is an application data unit. 246 Partial payload - A partial payload is a payload that comprises 247 either the first N bytes or the last N bytes of some other payload 248 of length M, such that 0 < N < M. Note that every partial payload 249 is a payload and therefore can be further subdivided into partial 250 payloads. 252 Fragment - A fragment is a bundle whose payload block contains a 253 partial payload. 255 Bundle node - A bundle node (or, in the context of this document, 256 simply a "node") is any entity that can send and/or receive bundles. 257 Each bundle node has three conceptual components, defined below, as 258 shown in Figure 2: a "bundle protocol agent", a set of zero or more 259 "convergence layer adapters", and an "application agent". 261 +-----------------------------------------------------------+ 262 |Node | 263 | | 264 | +-------------------------------------------------------+ | 265 | |Application Agent | | 266 | | | | 267 | | +--------------------------+ +----------------------+ | | 268 | | |Administrative element | |Application-specific | | | 269 | | | | |element | | | 270 | | | | | | | | 271 | | +--------------------------+ +----------------------+ | | 272 | | ^ ^ | | 273 | | Admin|records Application|data | | 274 | | | | | | 275 | +----------------v--------------------------v-----------+ | 276 | ^ | 277 | | ADUs | 278 | | | 279 | +-----------------------------v-------------------------+ | 280 | |Bundle Protocol Agent | | 281 | | | | 282 | | | | 283 | +-------------------------------------------------------+ | 284 | ^ ^ ^ | 285 | | Bundles | Bundles Bundles | | 286 | | | | | 287 | +------v-----+ +-----v------+ +-----v-----+ | 288 | |CLA 1 | |CLA 2 | |CLA n | | 289 | | | | | . . . | | | 290 | | | | | | | | 291 +-+------------+-----+------------+-----------+-----------+-+ 292 ^ ^ ^ 293 CL1|PDUs CL2|PDUs CLn|PDUs 294 | | | 295 +------v-----+ +-----v------+ +-----v-----+ 296 Network 1 Network 2 Network n 298 Figure 2: Components of a Bundle Node 300 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 301 the node component that offers the BP services and executes the 302 procedures of the bundle protocol. 304 Convergence layer adapter - A convergence layer adapter (CLA) is a 305 node component that sends and receives bundles on behalf of the BPA, 306 utilizing the services of some 'native' protocol stack that is 307 supported in one of the networks within which the node is 308 functionally located. 310 Application agent - The application agent (AA) of a node is the node 311 component that utilizes the BP services to effect communication for 312 some user purpose. The application agent in turn has two elements, 313 an administrative element and an application-specific element. 315 Application-specific element - The application-specific element of 316 an AA is the node component that constructs, requests transmission 317 of, accepts delivery of, and processes units of user application 318 data. 320 Administrative element - The administrative element of an AA is the 321 node component that constructs and requests transmission of 322 administrative records (defined below), including status reports, 323 and accepts delivery of and processes any administrative records 324 that the node receives. 326 Administrative record - A BP administrative record is an application 327 data unit that is exchanged between the administrative elements of 328 nodes' application agents for some BP administrative purpose. The 329 only administrative record defined in this specification is the 330 status report, discussed later. 332 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 333 of zero or more bundle nodes that all identify themselves for BP 334 purposes by some common identifier, called a "bundle endpoint ID" 335 (or, in this document, simply "endpoint ID"; endpoint IDs are 336 described in detail in Section 4.4.1 below). 338 Singleton endpoint - A singleton endpoint is an endpoint that always 339 contains exactly one member. 341 Registration - A registration is the state machine characterizing a 342 given node's membership in a given endpoint. Any single 343 registration has an associated delivery failure action as defined 344 below and must at any time be in one of two states: Active or 345 Passive. 347 Delivery - A bundle is considered to have been delivered at a node 348 subject to a registration as soon as the application data unit that 349 is the payload of the bundle, together with any relevant metadata 350 (an implementation matter), has been presented to the node's 351 application agent in a manner consistent with the state of that 352 registration. 354 Deliverability - A bundle is considered "deliverable" subject to a 355 registration if and only if (a) the bundle's destination endpoint is 356 the endpoint with which the registration is associated, (b) the 357 bundle has not yet been delivered subject to this registration, and 358 (c) the bundle has not yet been "abandoned" (as defined below) 359 subject to this registration. 361 Abandonment - To abandon a bundle subject to some registration is to 362 assert that the bundle is not deliverable subject to that 363 registration. 365 Delivery failure action - The delivery failure action of a 366 registration is the action that is to be taken when a bundle that is 367 "deliverable" subject to that registration is received at a time 368 when the registration is in the Passive state. 370 Destination - The destination of a bundle is the endpoint comprising 371 the node(s) at which the bundle is to be delivered (as defined 372 below). 374 Transmission - A transmission is an attempt by a node's BPA to cause 375 copies of a bundle to be delivered to one or more of the nodes that 376 are members of some endpoint (the bundle's destination) in response 377 to a transmission request issued by the node's application agent. 379 Forwarding - To forward a bundle to a node is to invoke the services 380 of one or more CLAs in a sustained effort to cause a copy of the 381 bundle to be received by that node. 383 Discarding - To discard a bundle is to cease all operations on the 384 bundle and functionally erase all references to it. The specific 385 procedures by which this is accomplished are an implementation 386 matter. 388 Retention constraint - A retention constraint is an element of the 389 state of a bundle that prevents the bundle from being discarded. 390 That is, a bundle cannot be discarded while it has any retention 391 constraints. 393 Deletion - To delete a bundle is to remove unconditionally all of 394 the bundle's retention constraints, enabling the bundle to be 395 discarded. 397 3.2. Discussion of BP concepts 399 Multiple instances of the same bundle (the same unit of DTN protocol 400 data) might exist concurrently in different parts of a network -- 401 possibly differing in some blocks -- in the memory local to one or 402 more bundle nodes and/or in transit between nodes. In the context of 403 the operation of a bundle node, a bundle is an instance (copy), in 404 that node's local memory, of some bundle that is in the network. 406 The payload for a bundle forwarded in response to a bundle 407 transmission request is the application data unit whose location is 408 provided as a parameter to that request. The payload for a bundle 409 forwarded in response to reception of a bundle is the payload of the 410 received bundle. 412 In the most familiar case, a bundle node is instantiated as a single 413 process running on a general-purpose computer, but in general the 414 definition is meant to be broader: a bundle node might alternatively 415 be a thread, an object in an object-oriented operating system, a 416 special-purpose hardware device, etc. 418 The manner in which the functions of the BPA are performed is wholly 419 an implementation matter. For example, BPA functionality might be 420 coded into each node individually; it might be implemented as a 421 shared library that is used in common by any number of bundle nodes 422 on a single computer; it might be implemented as a daemon whose 423 services are invoked via inter-process or network communication by 424 any number of bundle nodes on one or more computers; it might be 425 implemented in hardware. 427 Every CLA implements its own thin layer of protocol, interposed 428 between BP and the (usually "top") protocol(s) of the underlying 429 native protocol stack; this "CL protocol" may only serve to 430 multiplex and de-multiplex bundles to and from the underlying native 431 protocol, or it may offer additional CL-specific functionality. The 432 manner in which a CLA sends and receives bundles, as well as the 433 definitions of CLAs and CL protocols, are beyond the scope of this 434 specification. 436 Note that the administrative element of a node's application agent 437 may itself, in some cases, function as a convergence-layer adapter. 438 That is, outgoing bundles may be "tunneled" through encapsulating 439 bundles: 441 . An outgoing bundle constitutes a byte array. This byte array 442 may, like any other, be presented to the bundle protocol agent 443 as an application data unit that is to be transmitted to some 444 endpoint. 445 . The original bundle thus forms the payload of an encapsulating 446 bundle that is forwarded using some other convergence-layer 447 protocol(s). 448 . When the encapsulating bundle is received, its payload is 449 delivered to the peer application agent administrative element, 450 which then instructs the bundle protocol agent to dispatch that 451 original bundle in the usual way. 453 The purposes for which this technique may be useful (such as cross- 454 domain security) are beyond the scope of this specification. 456 The only interface between the BPA and the application-specific 457 element of the AA is the BP service interface. But between the BPA 458 and the administrative element of the AA there is a (conceptual) 459 private control interface in addition to the BP service interface. 460 This private control interface enables the BPA and the 461 administrative element of the AA to direct each other to take action 462 under specific circumstances. 464 In the case of a node that serves simply as a BP "router", the AA 465 may have no application-specific element at all. The application- 466 specific elements of other nodes' AAs may perform arbitrarily 467 complex application functions, perhaps even offering multiplexed DTN 468 communication services to a number of other applications. As with 469 the BPA, the manner in which the AA performs its functions is wholly 470 an implementation matter. 472 Singletons are the most familiar sort of endpoint, but in general 473 the endpoint notion is meant to be broader. For example, the nodes 474 in a sensor network might constitute a set of bundle nodes that 475 identify themselves by a single common endpoint ID and thus form a 476 single bundle endpoint. *Note* too that a given bundle node might 477 identify itself by multiple endpoint IDs and thus be a member of 478 multiple bundle endpoints. 480 The destination of every bundle is an endpoint, which may or may not 481 be singleton. The source of every bundle is a node, identified by 482 the endpoint ID for some singleton endpoint that contains that node. 483 Note, though, that the source node ID asserted in a given bundle may 484 be the null endpoint ID (as described later) rather than the 485 endpoint ID of the actual source node; bundles for which the 486 asserted source node ID is the null endpoint ID are termed 487 "anonymous" bundles. 489 Any number of transmissions may be concurrently undertaken by the 490 bundle protocol agent of a given node. 492 When the bundle protocol agent of a node determines that a bundle 493 must be forwarded to a node (either to a node that is a member of 494 the bundle's destination endpoint or to some intermediate forwarding 495 node) in the course of completing the successful transmission of 496 that bundle, the bundle protocol agent invokes the services of one 497 or more CLAs in a sustained effort to cause a copy of the bundle to 498 be received by that node. 500 Upon reception, the processing of a bundle that has been received by 501 a given node depends on whether or not the receiving node is 502 registered in the bundle's destination endpoint. If it is, and if 503 the payload of the bundle is non-fragmentary (possibly as a result 504 of successful payload reassembly from fragmentary payloads, 505 including the original payload of the newly received bundle), then 506 the bundle is normally delivered to the node's application agent 507 subject to the registration characterizing the node's membership in 508 the destination endpoint. 510 The bundle protocol does not natively ensure delivery of a bundle to 511 its destination. Data loss along the path to the destination node 512 can be minimized by utilizing reliable convergence-layer protocols 513 between neighbors on all segments of the end-to-end path, but for 514 end-to-end bundle delivery assurance it will be necessary to develop 515 extensions to the bundle protocol and/or application-layer 516 mechanisms. 518 The bundle protocol is designed for extensibility. Bundle protocol 519 extensions, documented elsewhere, may extend this specification by: 521 . defining additional blocks; 522 . defining additional administrative records; 523 . defining additional bundle processing flags; 524 . defining additional block processing flags; 525 . defining additional types of bundle status reports; 526 . defining additional bundle status report reason codes; 527 . defining additional mandates and constraints on processing 528 that conformant bundle protocol agents must perform at 529 specified points in the inbound and outbound bundle processing 530 cycles. 532 3.3. Services Offered by Bundle Protocol Agents 534 The BPA of each node is expected to provide the following services 535 to the node's application agent: 537 . commencing a registration (registering the node in an 538 endpoint); 539 . terminating a registration; 540 . switching a registration between Active and Passive states; 541 . transmitting a bundle to an identified bundle endpoint; 542 . canceling a transmission; 543 . polling a registration that is in the Passive state; 544 . delivering a received bundle. 546 4. Bundle Format 548 The format of bundles SHALL conform to the Concise Binary Object 549 Representation (CBOR [RFC7049]). 551 Each bundle SHALL be a concatenated sequence of at least two blocks, 552 represented as a CBOR indefinite-length array. The first block in 553 the sequence (the first item of the array) MUST be a primary bundle 554 block in CBOR representation as described below; the bundle MUST 555 have exactly one primary bundle block. The primary block MUST be 556 followed by one or more canonical bundle blocks (additional array 557 items) in CBOR representation as described below. The last such 558 block MUST be a payload block; the bundle MUST have exactly one 559 payload block. The last item of the array, immediately following 560 the payload block, SHALL be a CBOR "break" stop code. 562 (Note that, while CBOR permits considerable flexibility in the 563 encoding of bundles, this flexibility must not be interpreted as 564 inviting increased complexity in protocol data unit structure.) 566 An implementation of the Bundle Protocol MAY discard any sequence of 567 bytes that does not conform to the Bundle Protocol specification. 569 An implementation of the Bundle Protocol MAY accept a sequence of 570 bytes that does not conform to the Bundle Protocol specification 571 (e.g., one that represents data elements in fixed-length arrays 572 rather than indefinite-length arrays) and transform it into 573 conformant BP structure before processing it. Procedures for 574 accomplishing such a transformation are beyond the scope of this 575 specification. 577 4.1. BP Fundamental Data Structures 579 4.1.1. CRC Type 581 CRC type is an unsigned integer type code for which the following 582 values (and no others) are valid: 584 . 0 indicates "no CRC is present." 585 . 1 indicates "a standard X-25 CRC-16 is present." [CRC16] 586 . 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present." 587 [CRC32C] 589 CRC type SHALL be represented as a CBOR unsigned integer. 591 For examples of CRC32C CRCs, see Appendix A.4 of [RFC7143]. 593 4.1.2. CRC 595 CRC SHALL be omitted from a block if and only if the block's CRC 596 type code is zero. 598 When not omitted, the CRC SHALL be represented as sequence a CBOR 599 unsigned integer either of two bytes (that is, CBOR additional 600 information 25, if CRC type is 1) or as a sequence of four bytes 601 (that is, CBOR additional information 26, if CRC type is 2); in each 602 case the sequence of bytes SHALL constitute an unsigned integer 603 value (of 16 or 32 bits, respectively) in network byte order. 605 4.1.3. Bundle Processing Control Flags 607 Bundle processing control flags assert properties of the bundle as a 608 whole rather than of any particular block of the bundle. They are 609 conveyed in the primary block of the bundle. 611 The following properties are asserted by the bundle processing 612 control flags: 614 . The bundle is a fragment. (Boolean) 616 . The bundle's payload is an administrative record. (Boolean) 618 . The bundle must not be fragmented. (Boolean) 620 . Acknowledgment by the user application is requested. (Boolean) 622 . Status time is requested in all status reports. (Boolean) 624 . The bundle contains a "manifest" extension block. (Boolean) 626 . Flags requesting types of status reports (all Boolean): 628 o Request reporting of bundle reception. 630 o Request reporting of bundle forwarding. 632 o Request reporting of bundle delivery. 634 o Request reporting of bundle deletion. 636 If the bundle processing control flags indicate that the bundle's 637 application data unit is an administrative record, then all status 638 report request flag values must be zero. 640 If the bundle's source node is omitted (i.e., the source node ID is 641 the ID of the null endpoint, which has no members as discussed 642 below; this option enables anonymous bundle transmission), then the 643 bundle is not uniquely identifiable and all bundle protocol features 644 that rely on bundle identity must therefore be disabled: the "Bundle 645 must not be fragmented" flag value must be 1 and all status report 646 request flag values must be zero. 648 The bundle processing control flags SHALL be represented as a CBOR 649 unsigned integer item of two bytes (that is, CBOR additional 650 information 25) containing a bit field of 16 bits indicating the 651 control flag values as follows: 653 . Bit 0 (the high-order bit, 0x8000): reserved. 654 . Bit 1 (0x4000): reserved. 655 . Bit 2 (0x2000): reserved. 656 . Bit 3(0x1000): bundle deletion status reports are requested. 657 . Bit 4(0x0800): bundle delivery status reports are requested. 658 . Bit 5(0x0400): bundle forwarding status reports are requested. 659 . Bit 6(0x0200): reserved. 660 . Bit 7(0x0100): bundle reception status reports are requested. 661 . Bit 8(0x0080): reserved. 662 . Bit 9(0x0040): status time is requested in all status reports. 663 . Bit 10(0x0020): user application acknowledgement is requested. 664 . Bit 11(0x0010): reserved. 665 . Bit 12(0x0008): reserved. 666 . Bit 13(0x0004): bundle must not be fragmented. 667 . Bit 14(0x0002): payload is an administrative record. 668 . Bit 15 (the low-order bit, 0x0001: bundle is a fragment. 670 Note: bit 8 is reserved with the intention of using it to indicate 671 the presence of a Manifest extension block, not yet defined. 673 4.1.4. Block Processing Control Flags 675 The block processing control flags assert properties of canonical 676 bundle blocks. They are conveyed in the header of the block to 677 which they pertain. 679 The following properties are asserted by the block processing 680 control flags: 682 . This block must be replicated in every fragment. (Boolean) 684 . Transmission of a status report is requested if this block 685 can't be processed. (Boolean) 687 . Block must be removed from the bundle if it can't be processed. 688 (Boolean) 690 . Bundle must be deleted if this block can't be processed. 691 (Boolean) 693 For each bundle whose bundle processing control flags indicate that 694 the bundle's application data unit is an administrative record, or 695 whose source node ID is the null endpoint ID as defined below, the 696 value of the "Transmit status report if block can't be processed" 697 flag in every canonical block of the bundle must be zero. 699 The block processing control flags SHALL be represented as a CBOR 700 unsigned integer item of 1 byte (that is, CBOR additional 701 information 24) containing a bit field of 8 bits indicating the 702 control flag values as follows: 704 . Bit 0 (the high-order bit, 0x80): reserved. 705 . Bit 1 (0x40): reserved. 706 . Bit 2(0x20): reserved. 707 . Bit 3(0x10): reserved. 708 . Bit 4(0x08): bundle must be deleted if block can't be 709 processed. 710 . Bit 5(0x04): transmission of a status report is requested if 711 block can't be processed. 712 . Bit 6(0x02): block must be removed from bundle if it can't be 713 processed. 714 . Bit 7(the low-order bit, 0x01): block must be replicated in 715 every fragment. 717 4.1.5. Identifiers 719 4.1.5.1. Endpoint ID 721 The destinations of bundles are bundle endpoints, identified by text 722 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 723 (EID) is a Uniform Resource Identifier (URI; [URI]). As such, each 724 endpoint ID can be characterized as having this general structure: 726 < scheme name > : < scheme-specific part, or "SSP" > 728 The scheme identified by the < scheme name > in an endpoint ID is a 729 set of syntactic and semantic rules that fully explain how to parse 730 and interpret the SSP. The set of allowable schemes is effectively 731 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 732 protocol endpoint ID. 734 Note that, although endpoint IDs are URIs, implementations of the BP 735 service interface may support expression of endpoint IDs in some 736 internationalized manner (e.g., Internationalized Resource 737 Identifiers (IRIs); see [RFC3987]). 739 The endpoint ID "dtn:none" identifies the "null endpoint", the 740 endpoint that by definition never has any members. 742 Each BP endpoint ID (EID) SHALL be represented as a CBOR array 743 comprising a 2-tuple. 745 The first item of the array SHALL be the code number identifying the 746 endpoint's URI scheme [URI], as defined in the registry of URI 747 scheme code numbers for Bundle Protocol maintained by IANA as 748 described in Section 10. [URIREG]. Each URI scheme code number 749 SHALL be represented as a CBOR unsigned integer. 751 The second item of the array SHALL be the applicable CBOR 752 representation of the scheme-specific part (SSP) of the EID, defined 753 as follows: 755 . If the EID's URI scheme is "dtn" then the SSP SHALL be 756 represented as a CBOR text string unless the EID's SSP is 757 "none", in which case the SSP SHALL be represented as a CBOR 758 unsigned integer with the value zero. 759 . If the EID's URI scheme is "ipn" then the SSP SHALL be 760 represented as a CBOR array comprising a 2-tuple. The first 761 item of this array SHALL be the EID's node number represented 762 as a CBOR unsigned integer. The second item of this array 763 SHALL be the EID's service number represented as a CBOR 764 unsigned integer. 765 . Definitions of the CBOR representations of the SSPs of EIDs 766 encoded in other URI schemes are included in the specifications 767 defining those schemes. 769 4.1.5.2. Node ID 771 For many purposes of the Bundle Protocol it is important to identify 772 the node that is operative in some context. 774 As discussed in 3.1 above, nodes are distinct from endpoints; 775 specifically, an endpoint is a set of zero or more nodes. But 776 rather than define a separate namespace for node identifiers, we 777 instead use endpoint identifiers to identify nodes, subject to the 778 following restrictions: 780 . Every node MUST be a member of at least one singleton endpoint. 781 . The EID of any singleton endpoint of which a node is a member 782 MAY be used to identify that node. A "node ID" is an EID that 783 is used in this way. 784 . A node's membership in a given singleton endpoint MUST be 785 sustained at least until the nominal operation of the Bundle 786 Protocol no longer depends on the identification of that node 787 using that endpoint's ID. 789 4.1.6. DTN Time 791 A DTN time is an unsigned integer indicating an interval of Unix 792 epoch time [EPOCH] that has elapsed since the start of the year 2000 793 on the Coordinated Universal Time (UTC) scale [UTC], which is Unix 794 epoch timestamp 946684800. (Note that the DTN time that equates to 795 the current time as reported by the UNIX time() function can be 796 derived by subtracting 946684800 from that reported time value.) 797 Each DTN time SHALL be represented as a CBOR unsigned integer item. 799 Note: The choice of Unix epoch time as the scale on which time 800 values in DTN are expressed may need some explanation. 802 The computation of time intervals is integral to several DTN 803 protocol procedures. Inconsistency in the results of these 804 computations would result in inconsistent performance of those 805 procedures and would compromise the operation of the protocol. 807 So the key qualities sought in selecting the time scale to be used 808 for expressing DTN times were these: (a) the broadest possible 809 access to the value of the current time on the selected time scale, 810 enabling all nodes of the network to perform protocol procedures in 811 the same way using the same information, and (b) ease of time 812 interval computation. 814 UTC was an obvious candidate but fell short on both counts. First, 815 millions of devices can readily query the current UTC time, thanks 816 to NTP, but spacecraft operating beyond Earth orbit cannot. There 817 is currently no adaptation of NTP that operates over the long and 818 variable signal propagation delays between vehicles in deep space. 820 Moreover, computing the number of actual elapsed seconds between two 821 UTC times is non-trivial because UTC times include leap seconds. As 822 an illustration of the issue, consider the passage of UTC and TAI 823 time at a ground station antenna that began transmitting data at 824 8Kbps around midnight December 31, 2016 (UTC), when a leap second 825 was added (*): 827 UTC TAI Total bytes sent 829 t1 2016-12-31 23:59:58 2017-01-01 00:00:34 0 831 t2 2016-12-31 23:59:59 2017-01-01 00:00:35 1000 833 t3 2016-12-31 23:59:60* 2017-01-01 00:00:36 2000 835 t4 2017-01-01 00:00:00 2017-01-01 00:00:37 3000 836 t5 2017-01-01 00:00:01 2017-01-01 00:00:38 4000 838 Suppose we must compute the volume of data transmitted in the 839 interval between t1 and t5. If we use TAI time values, the elapsed 840 time interval is 4 seconds (00:00:38 minus 00:00:34); at 8Kbps, the 841 computed transmission volume is 4000 bytes, which is correct. If we 842 instead use UTC time values as stated, without special compensation 843 for the insertion of the leap second, the elapsed time interval is 3 844 seconds (00:00:01 minus 23:59:58); the computed transmission volume 845 is then 3000 bytes, which is incorrect. 847 TAI, then, would be an ideal time scale for DTN, as the interval in 848 seconds between two TAI times can be computed by simply subtracting 849 one from the other; there is no need to consult a table of leap 850 seconds each time a time interval is computed. Unfortunately the 851 current value of TAI, as tracked by atomic clocks on Earth and 852 carefully managed by the International Bureau of Weights and 853 Measures, is likewise not directly accessible to spacecraft. 855 Unix epoch time is the next best option. Like TAI, Unix epoch time 856 is simply a count of seconds elapsed since a standard epoch. Unlike 857 TAI, the current value of Unix epoch time is provided by virtually 858 all operating systems on which BP is likely to run. 860 Implementers of Bundle Protocol need to be aware that the difference 861 between DTN time and UTC time will increase with the passing years 862 as additional leap seconds are inserted into UTC. Converting DTN 863 time to the correct corresponding UTC time, in the event that such 864 conversion is needed, will require an understanding of the leap 865 second adjustments made to UTC over time; for software written in C, 866 the widely supported gmtime() function provides this service. 868 Implementers also need to be aware that DTN time values conveyed in 869 CBOR representation in bundles can conceivably exceed (2**32 - 1). 871 4.1.7. Creation Timestamp 873 Each creation timestamp SHALL be represented as a CBOR array item 874 comprising a 2-tuple. 876 The first item of the array SHALL be a DTN time. 878 The second item of the array SHALL be the creation timestamp's 879 sequence number, represented as a CBOR unsigned integer. 881 4.1.8. Block-type-specific Data 883 Block-type-specific data in each block (other than the primary 884 block) SHALL be the applicable CBOR representation of the content of 885 the block. Details of this representation are included in the 886 specification defining the block type. 888 4.2. Bundle Representation 890 This section describes the primary block in detail and non-primary 891 blocks in general. Rules for processing these blocks appear in 892 Section 5 of this document. 894 Note that supplementary DTN protocol specifications (including, but 895 not restricted to, the Bundle Security Protocol [BPSEC]) may require 896 that BP implementations conforming to those protocols construct and 897 process additional blocks. 899 4.2.1. Bundle 901 Each bundle SHALL be represented as a CBOR indefinite-length array. 902 The first item of this array SHALL be the CBOR representation of a 903 Primary Block. Every other item of the array except the last SHALL 904 be the CBOR representation of a Canonical Block. The last item of 905 the array SHALL be a CBOR "break" stop code. 907 Associated with each block of a bundle is a block number. The block 908 number uniquely identifies the block within the bundle, enabling 909 blocks (notably bundle security protocol blocks) to reference other 910 blocks in the same bundle without ambiguity. The block number of 911 the primary block is implicitly zero; the block numbers of all other 912 blocks are explicitly stated in block headers as noted below. Block 913 numbering is unrelated to the order in which blocks are sequenced in 914 the bundle. The block number of the payload block is always 1. 916 4.2.2. Primary Bundle Block 918 The primary bundle block contains the basic information needed to 919 forward bundles to their destinations. 921 Each primary block SHALL be represented as a CBOR array; the number 922 of elements in the array SHALL be 8 (if the bundle is not a fragment 923 and has the block has no CRC), 9 (if the block has a CRC and the 924 bundle is not a fragment), 10 (if the bundle is a fragment and the 925 block has no CRC), or 11 (if the bundle is a fragment and the block 926 has a CRC). 928 The primary block of each bundle SHALL be immutable. The values of 929 all fields in the primary block must remain unchanged from the time 930 the block is created to the time it is delivered. 932 The fields of the primary bundle block SHALL be as follows, listed 933 in the order in which they MUST appear: 935 Version: An unsigned integer value indicating the version of the 936 bundle protocol that constructed this block. The present document 937 describes version 7 of the bundle protocol. Version number SHALL be 938 represented as a CBOR unsigned integer item. 940 Bundle Processing Control Flags: The Bundle Processing Control Flags 941 are discussed in Section 4.1.3. above. 943 CRC Type: CRC Type codes are discussed in Section 4.1.1. above. The 944 CRC Type code for the primary block MAY be zero if the bundle 945 contains a BPsec [BPSEC] Block Integrity Block whose target is the 946 primary block; otherwise the CRC Type code for the primary block 947 MUST be non-zero. 949 Destination EID: The Destination EID field identifies the bundle 950 endpoint that is the bundle's destination, i.e., the endpoint that 951 contains the node(s) at which the bundle is to be delivered. 953 Source node ID: The Source node ID field identifies the bundle node 954 at which the bundle was initially transmitted, except that Source 955 node ID may be the null endpoint ID in the event that the bundle's 956 source chooses to remain anonymous. 958 Report-to EID: The Report-to EID field identifies the bundle 959 endpoint to which status reports pertaining to the forwarding and 960 delivery of this bundle are to be transmitted. 962 Creation Timestamp: The creation timestamp (discussed in 4.1.7 963 above) is a pair ofcomprises two unsigned integers that, together 964 with the source node ID and (if the bundle is a fragment) the 965 fragment offset and payload length, serve to identify the bundle. 966 The first of these integers is the bundle's creation time, while the 967 second is the bundle's creation timestamp sequence number. Bundle 968 creation time SHALL be the DTN time at which the transmission 969 request was received that resulted in the creation of the bundle. 970 Sequence count SHALL be the latest value (as of the time at which 971 that transmission request was received) of a monotonically 972 increasing positive integer counter managed by the source node's 973 bundle protocol agent that MAY be reset to zero whenever the current 974 time advances by one second. For nodes that lack accurate clocks, it 975 is recommended that bundle creation time be set to zero and that the 976 counter used as the source of the bundle sequence count never be 977 reset to zero. Note that, in general, the creation of two distinct 978 bundles with the same source node ID and bundle creation timestamp 979 may result in unexpected network behavior and/or suboptimal 980 performance. The combination of source node ID and bundle creation 981 timestamp serves to identify a single transmission request, enabling 982 it to be acknowledged by the receiving application (provided the 983 source node ID is not the null endpoint ID). 985 Lifetime: The lifetime field is an unsigned integer that indicates 986 the time at which the bundle's payload will no longer be useful, 987 encoded as a number of microseconds past the creation time. (For 988 high-rate deployments with very brief disruptions, fine-grained 989 expression of bundle lifetime may be useful.) When a bundle's age 990 exceeds its lifetime, bundle nodes need no longer retain or forward 991 the bundle; the bundle SHOULD be deleted from the network. For 992 bundles originating at nodes that lack accurate clocks, it is 993 recommended that bundle age be obtained from the Bundle Age 994 extension block (see 4.3.2 below) rather than from the difference 995 between current time and bundle creation time. Bundle lifetime 996 SHALL be represented as a CBOR unsigned integer item. 998 Fragment offset: If and only if the Bundle Processing Control Flags 999 of this Primary block indicate that the bundle is a fragment, 1000 fragment offset SHALL be present in the primary block. Fragment 1001 offset SHALL be represented as a CBOR unsigned integer indicating 1002 the offset from the start of the original application data unit at 1003 which the bytes comprising the payload of this bundle were located. 1005 Total Application Data Unit Length: If and only if the Bundle 1006 Processing Control Flags of this Primary block indicate that the 1007 bundle is a fragment, total application data unit length SHALL be 1008 present in the primary block. Total application data unit length 1009 SHALL be represented as a CBOR unsigned integer indicating the total 1010 length of the original application data unit of which this bundle's 1011 payload is a part. 1013 CRC: A CRC SHALL be present in the primary block unless the bundle 1014 includes a BPsec [BPSEC] Block Integrity Block whose target is the 1015 primary block, in which case a CRC MAY be present in the primary 1016 block. The length and nature of the CRC SHALL be as indicated by 1017 the CRC type. The CRC SHALL be computed over the concatenation of 1018 all bytes (including CBOR "break" characters) of the primary block 1019 including the CRC field itself, which for this purpose SHALL be 1020 temporarily populated with the value zero. 1022 4.2.3. Canonical Bundle Block Format 1024 Every block other than the primary block (all such blocks are termed 1025 "canonical" blocks) SHALL be represented as a CBOR array; the number 1026 of elements in the array SHALL be 5 (if CRC type is zero) or 6 1027 (otherwise). 1029 The fields of every canonical block SHALL be as follows, listed in 1030 the order in which they MUST appear: 1032 . Block type code, an unsigned integer. Bundle block type code 1 1033 indicates that the block is a bundle payload block. Block type 1034 codes 2 through 9 are explicitly reserved as noted later in 1035 this specification. Block type codes 192 through 255 are not 1036 reserved and are available for private and/or experimental use. 1037 All other block type code values are reserved for future use. 1038 . Block number, an unsigned integer as discussed in 4.2.1 above. 1039 Block number SHALL be represented as a CBOR unsigned integer. 1040 . Block processing control flags as discussed in Section 4.1.4 1041 above. 1042 . CRC type as discussed in Section 4.1.1 above. 1043 . Block-type-specific data represented as a single definite- 1044 length CBOR byte string, i.e., a CBOR byte string that is not 1045 of indefinite length. For each type of block, the block-type- 1046 specific data byte string is the serialization, in a block- 1047 type-specific manner, of the data conveyed by that type of 1048 block; definitions of blocks are required to define the manner 1049 in which block-type-specific data are serialized within the 1050 block-type-specific data field. For the Payload Block in 1051 particular (block type 1), the block-type-specific data field, 1052 termed the "payload", SHALL be an application data unit, or 1053 some contiguous extent thereof, represented as a definite- 1054 length CBOR byte string. 1055 . If and only if the value of the CRC type field of this block is 1056 non-zero, a CRC. If present, the length and nature of the CRC 1057 SHALL be as indicated by the CRC type and the CRC SHALL be 1058 computed over the concatenation of all bytes of the block 1059 (including CBOR "break" characters) including the CRC field 1060 itself, which for this purpose SHALL be temporarily populated 1061 with the value zero. 1063 4.3. Extension Blocks 1065 "Extension blocks" are all blocks other than the primary and payload 1066 blocks. Because not all extension blocks are defined in the Bundle 1067 Protocol specification (the present document), not all nodes 1068 conforming to this specification will necessarily instantiate Bundle 1069 Protocol implementations that include procedures for processing 1070 (that is, recognizing, parsing, acting on, and/or producing) all 1071 extension blocks. It is therefore possible for a node to receive a 1072 bundle that includes extension blocks that the node cannot process. 1073 The values of the block processing control flags indicate the action 1074 to be taken by the bundle protocol agent when this is the case. 1076 Extension block types 2 and 3 are reserved for the Block Integrity 1077 Block and Block Confidentiality Block as defined in the Bundle 1078 Security Protocol specification [BPSEC]. 1080 The following extension block types are reserved for extension 1081 blocks for which a need is anticipated but for which no definitions 1082 yet exist: 1084 . Block type 4 is reserved for the anticipated Manifest Block. 1085 Note: it is anticipated that the manifest block will identify 1086 the blocks that were present in the bundle at the time it was 1087 created, implying that the bundle MUST contain one (1) 1088 occurrence of this type of block if the value of the "manifest" 1089 flag in the bundle processing control flags is 1, but otherwise 1090 the bundle MUST NOT contain any Manifest block. 1091 . Block type 5 is reserved for the anticipated Metadata Block. 1092 Note: the structure and function of the anticipated Metadata 1093 Block are currently undefined. 1094 . Block type 6 is reserved for the anticipated Data Label Block. 1095 Note: it is anticipated that the data label block will provide 1096 additional information that can assist nodes in making 1097 forwarding decisions. 1099 The following extension blocks are defined in the current document. 1101 4.3.1. Previous Node 1103 The Previous Node block, block type 7, identifies the node that 1104 forwarded this bundle to the local node (i.e., to the node at which 1105 the bundle currently resides); its block-type-specific data is the 1106 node ID of that forwarder node which SHALL take the form of a node 1107 ID represented as described in Section 4.1.5.2. above. If the local 1108 node is the source of the bundle, then the bundle MUST NOT contain 1109 any previous node block. Otherwise the bundle SHOULD contain one 1110 (1) occurrence of this type of block. 1112 4.3.2. Bundle Age 1114 The Bundle Age block, block type 8, contains the number of 1115 microseconds that have elapsed between the time the bundle was 1116 created and time at which it was most recently forwarded. It is 1117 intended for use by nodes lacking access to an accurate clock, to 1118 aid in determining the time at which a bundle's lifetime expires. 1119 The block-type-specific data of this block is an unsigned integer 1120 containing the age of the bundle in microseconds, which SHALL be 1121 represented as a CBOR unsigned integer item. (The age of the bundle 1122 is the sum of all known intervals of the bundle's residence at 1123 forwarding nodes, up to the time at which the bundle was most 1124 recently forwarded, plus the summation of signal propagation time 1125 over all episodes of transmission between forwarding nodes. 1126 Determination of these values is an implementation matter.) If the 1127 bundle's creation time is zero, then the bundle MUST contain exactly 1128 one (1) occurrence of this type of block; otherwise, the bundle MAY 1129 contain at most one (1) occurrence of this type of block. A bundle 1130 MUST NOT contain multiple occurrences of the bundle age block, as 1131 this could result in processing anomalies. 1133 4.3.3. Hop Count 1135 The Hop Count block, block type 9, contains two unsigned integers, 1136 hop limit and hop count. A "hop" is here defined as an occasion on 1137 which a bundle was forwarded from one node to another node. Hop 1138 limit MUST be in the range 1 through 255. The hop limit value SHOULD 1139 NOT be changed at any time after creation of the Hop Count block; 1140 the hop count value SHOULD initially be zero and SHOULD be increased 1141 by 1 on each hop. 1143 The hop count block is mainly intended as a safety mechanism, a 1144 means of identifying bundles for removal from the network that can 1145 never be delivered due to a persistent forwarding error. When a 1146 bundle's hop count exceeds its hop limit, the bundle SHOULD be 1147 deleted for the reason "hop limit exceeded", following the bundle 1148 deletion procedure defined in Section 5.10. . Procedures for 1149 determining the appropriate hop limit for a block are beyond the 1150 scope of this specification. The block-type-specific data in a hop 1151 count block SHALL be represented as a CBOR array comprising a 2- 1152 tuple. The first item of this array SHALL be the bundle's hop 1153 limit, represented as a CBOR unsigned integer. The second item of 1154 this array SHALL be the bundle's hop count, represented as a CBOR 1155 unsigned integer. A bundle MAY contain at most one (1) occurrence of 1156 this type of block. 1158 5. Bundle Processing 1160 The bundle processing procedures mandated in this section and in 1161 Section 6 govern the operation of the Bundle Protocol Agent and the 1162 Application Agent administrative element of each bundle node. They 1163 are neither exhaustive nor exclusive. Supplementary DTN protocol 1164 specifications (including, but not restricted to, the Bundle 1165 Security Protocol [BPSEC]) may augment, override, or supersede the 1166 mandates of this document. 1168 5.1. Generation of Administrative Records 1170 All transmission of bundles is in response to bundle transmission 1171 requests presented by nodes' application agents. When required to 1172 "generate" an administrative record (such as a bundle status 1173 report), the bundle protocol agent itself is responsible for causing 1174 a new bundle to be transmitted, conveying that record. In concept, 1175 the bundle protocol agent discharges this responsibility by 1176 directing the administrative element of the node's application agent 1177 to construct the record and request its transmission as detailed in 1178 Section 6 below. In practice, the manner in which administrative 1179 record generation is accomplished is an implementation matter, 1180 provided the constraints noted in Section 6 are observed. 1182 Note that requesting status reports for any single bundle might 1183 easily result in the generation of (1 + (2 *(N-1))) status report 1184 bundles, where N is the number of nodes on the path from the 1185 bundle's source to its destination, inclusive. That is, the 1186 requesting of status reports for large numbers of bundles could 1187 result in an unacceptable increase in the bundle traffic in the 1188 network. For this reason, the generation of status reports MUST be 1189 disabled by default and enabled only when the risk of excessive 1190 network traffic is deemed acceptable. 1192 When the generation of status reports is enabled, the decision on 1193 whether or not to generate a requested status report is left to the 1194 discretion of the bundle protocol agent. Mechanisms that could 1195 assist in making such decisions, such as pre-placed agreements 1196 authorizing the generation of status reports under specified 1197 circumstances, are beyond the scope of this specification. 1199 Notes on administrative record terminology: 1201 . A "bundle reception status report" is a bundle status report 1202 with the "reporting node received bundle" flag set to 1. 1203 . A "bundle forwarding status report" is a bundle status report 1204 with the "reporting node forwarded the bundle" flag set to 1. 1205 . A "bundle delivery status report" is a bundle status report 1206 with the "reporting node delivered the bundle" flag set to 1. 1207 . A "bundle deletion status report" is a bundle status report 1208 with the "reporting node deleted the bundle" flag set to 1. 1210 5.2. Bundle Transmission 1212 The steps in processing a bundle transmission request are: 1214 Step 1: Transmission of the bundle is initiated. An outbound bundle 1215 MUST be created per the parameters of the bundle transmission 1216 request, with the retention constraint "Dispatch pending". The 1217 source node ID of the bundle MUST be either the null endpoint ID, 1218 indicating that the source of the bundle is anonymous, or else the 1219 EID of a singleton endpoint whose only member is the node of which 1220 the BPA is a component. 1222 Step 2: Processing proceeds from Step 1 of Section 5.4. 1224 5.3. Bundle Dispatching 1226 The steps in dispatching a bundle are: 1228 Step 1: If the bundle's destination endpoint is an endpoint of which 1229 the node is a member, the bundle delivery procedure defined in 1230 Section 5.7 MUST be followed and for the purposes of all subsequent 1231 processing of this bundle at this node the node's membership in the 1232 bundle's destination endpoint SHALL be disavowed; specifically, even 1233 though the node is a member of the bundle's destination endpoint, 1234 the node SHALL NOT undertake to forward the bundle to itself in the 1235 course of performing the procedure described in Section 5.4. 1237 Step 2: Processing proceeds from Step 1 of Section 5.4. 1239 5.4. Bundle Forwarding 1241 The steps in forwarding a bundle are: 1243 Step 1: The retention constraint "Forward pending" MUST be added to 1244 the bundle, and the bundle's "Dispatch pending" retention constraint 1245 MUST be removed. 1247 Step 2: The bundle protocol agent MUST determine whether or not 1248 forwarding is contraindicated for any of the reasons listed in 1249 Figure 4. In particular: 1251 . The bundle protocol agent MAY choose either to forward the 1252 bundle directly to its destination node(s) (if possible) or to 1253 forward the bundle to some other node(s) for further 1254 forwarding. The manner in which this decision is made may 1255 depend on the scheme name in the destination endpoint ID and/or 1256 on other state but in any case is beyond the scope of this 1257 document. If the BPA elects to forward the bundle to some other 1258 node(s) for further forwarding but finds it impossible to 1259 select any node(s) to forward the bundle to, then forwarding is 1260 contraindicated. 1261 . Provided the bundle protocol agent succeeded in selecting the 1262 node(s) to forward the bundle to, the bundle protocol agent 1263 MUST select the convergence layer adapter(s) whose services 1264 will enable the node to send the bundle to those nodes. The 1265 manner in which specific appropriate convergence layer adapters 1266 are selected is beyond the scope of this document. If the agent 1267 finds it impossible to select any appropriate convergence layer 1268 adapter(s) to use in forwarding this bundle, then forwarding is 1269 contraindicated. 1271 Step 3: If forwarding of the bundle is determined to be 1272 contraindicated for any of the reasons listed in Figure 4, then the 1273 Forwarding Contraindicated procedure defined in Section 5.4.1 MUST 1274 be followed; the remaining steps of Section 5.4 are skipped at this 1275 time. 1277 Step 4: For each node selected for forwarding, the bundle protocol 1278 agent MUST invoke the services of the selected convergence layer 1279 adapter(s) in order to effect the sending of the bundle to that 1280 node. Determining the time at which the bundle protocol agent 1281 invokes convergence layer adapter services is a BPA implementation 1282 matter. Determining the time at which each convergence layer 1283 adapter subsequently responds to this service invocation by sending 1284 the bundle is a convergence-layer adapter implementation matter. 1285 Note that: 1287 . If the bundle contains a data label extension block (to be 1288 defined in a future document) then that data label value MAY 1289 identify procedures for determining the order in which 1290 convergence layer adapters must send bundles, e.g., considering 1291 bundle source when determining the order in which bundles are 1292 sent. The definition of such procedures is beyond the scope of 1293 this specification. 1294 . If the bundle has a bundle age block, as defined in 4.3.2. 1295 above, then at the last possible moment before the CLA 1296 initiates conveyance of the bundle via the CL protocol the 1297 bundle age value MUST be increased by the difference between 1298 the current time and the time at which the bundle was received 1299 (or, if the local node is the source of the bundle, created). 1301 Step 5: When all selected convergence layer adapters have informed 1302 the bundle protocol agent that they have concluded their data 1303 sending procedures with regard to this bundle, processing may depend 1304 on the results of those procedures. If completion of the data 1305 sending procedures by all selected convergence layer adapters has 1306 not resulted in successful forwarding of the bundle (an 1307 implementation-specific determination that is beyond the scope of 1308 this specification), then the bundle protocol agent MAY choose (in 1309 an implementation-specific manner, again beyond the scope of this 1310 specification) to initiate another attempt to forward the bundle. 1311 In that event, processing proceeds from Step 4 of Section 5.4. 1313 If completion of the data sending procedures by all selected 1314 convergence layer adapters HAS resulted in successful forwarding of 1315 the bundle, or if it has not but the bundle protocol agent does not 1316 choose to initiate another attempt to forward the bundle, then: 1318 . If the "request reporting of bundle forwarding" flag in the 1319 bundle's status report request field is set to 1, and status 1320 reporting is enabled, then a bundle forwarding status report 1321 SHOULD be generated, destined for the bundle's report-to 1322 endpoint ID. The reason code on this bundle forwarding status 1323 report MUST be "no additional information". 1324 . If any applicable bundle protocol extensions mandate generation 1325 of status reports upon conclusion of convergence-layer data 1326 sending procedures, all such status reports SHOULD be generated 1327 with extension-mandated reason codes. 1328 . The bundle's "Forward pending" retention constraint MUST be 1329 removed. 1331 5.4.1. Forwarding Contraindicated 1333 The steps in responding to contraindication of forwarding are: 1335 Step 1: The bundle protocol agent MUST determine whether or not to 1336 declare failure in forwarding the bundle. Note: this decision is 1337 likely to be influenced by the reason for which forwarding is 1338 contraindicated. 1340 Step 2: If forwarding failure is declared, then the Forwarding 1341 Failed procedure defined in Section 5.4.2 MUST be followed. 1343 Otherwise, when -- at some future time - the forwarding of this 1344 bundle ceases to be contraindicated, processing proceeds from Step 4 1345 of Section 5.4. 1347 5.4.2. Forwarding Failed 1349 The steps in responding to a declaration of forwarding failure are: 1351 Step 1: The bundle protocol agent MAY forward the bundle back to the 1352 node that sent it, as identified by the Previous Node block, if 1353 present. This forwarding, if performed, SHALL be accomplished by 1354 performing Step 4 and Step 5 of section 5.4 where the sole node 1355 selected for forwarding SHALL be the node that sent the bundle. 1357 Step 2: If the bundle's destination endpoint is an endpoint of which 1358 the node is a member, then the bundle's "Forward pending" retention 1359 constraint MUST be removed. Otherwise, the bundle MUST be deleted: 1360 the bundle deletion procedure defined in Section 5.10 MUST be 1361 followed, citing the reason for which forwarding was determined to 1362 be contraindicated. 1364 5.5. Bundle Expiration 1366 A bundle expires when the bundle's age exceeds its lifetime as 1367 specified in the primary bundle block. Bundle age MAY be determined 1368 by subtracting the bundle's creation timestamp time from the current 1369 time if (a) that timestamp time is not zero and (b) the local node's 1370 clock is known to be accurate; otherwise bundle age MUST be obtained 1371 from the Bundle Age extension block. Bundle expiration MAY occur at 1372 any point in the processing of a bundle. When a bundle expires, the 1373 bundle protocol agent MUST delete the bundle for the reason 1374 "lifetime expired": the bundle deletion procedure defined in Section 1375 5.10 MUST be followed. 1377 5.6. Bundle Reception 1379 The steps in processing a bundle that has been received from another 1380 node are: 1382 Step 1: The retention constraint "Dispatch pending" MUST be added to 1383 the bundle. 1385 Step 2: If the "request reporting of bundle reception" flag in the 1386 bundle's status report request field is set to 1, and status 1387 reporting is enabled, then a bundle reception status report with 1388 reason code "No additional information" SHOULD be generated, 1389 destined for the bundle's report-to endpoint ID. 1391 Step 3: CRCs SHOULD be computed for every block of the bundle that 1392 has an attached CRC. If any block of the bundle is malformed 1393 according to this specification, or if any block has an attached CRC 1394 and the CRC computed for this block upon reception differs from that 1395 attached CRC, then the bundle protocol agent MUST delete the bundle 1396 for the reason "Block unintelligible". The bundle deletion 1397 procedure defined in Section 5.10 MUST be followed and all remaining 1398 steps of the bundle reception procedure MUST be skipped. 1400 Step 4: For each block in the bundle that is an extension block that 1401 the bundle protocol agent cannot process: 1403 . If the block processing flags in that block indicate that a 1404 status report is requested in this event, and status reporting 1405 is enabled, then a bundle reception status report with reason 1406 code "Block unintelligible" SHOULD be generated, destined for 1407 the bundle's report-to endpoint ID. 1408 . If the block processing flags in that block indicate that the 1409 bundle must be deleted in this event, then the bundle protocol 1410 agent MUST delete the bundle for the reason "Block 1411 unintelligible"; the bundle deletion procedure defined in 1412 Section 5.10 MUST be followed and all remaining steps of the 1413 bundle reception procedure MUST be skipped. 1414 . If the block processing flags in that block do NOT indicate 1415 that the bundle must be deleted in this event but do indicate 1416 that the block must be discarded, then the bundle protocol 1417 agent MUST remove this block from the bundle. 1418 . If the block processing flags in that block indicate neither 1419 that the bundle must be deleted nor that that the block must be 1420 discarded, then processing continues with the next extension 1421 block that the bundle protocol agent cannot process, if any; 1422 otherwise, processing proceeds from step 5. 1424 Step 5: Processing proceeds from Step 1 of Section 5.3. 1426 5.7. Local Bundle Delivery 1428 The steps in processing a bundle that is destined for an endpoint of 1429 which this node is a member are: 1431 Step 1: If the received bundle is a fragment, the application data 1432 unit reassembly procedure described in Section 5.9 MUST be followed. 1433 If this procedure results in reassembly of the entire original 1434 application data unit, processing of this bundle (whose fragmentary 1435 payload has been replaced by the reassembled application data unit) 1436 proceeds from Step 2; otherwise, the retention constraint 1437 "Reassembly pending" MUST be added to the bundle and all remaining 1438 steps of this procedure MUST be skipped. 1440 Step 2: Delivery depends on the state of the registration whose 1441 endpoint ID matches that of the destination of the bundle: 1443 . An additional implementation-specific delivery deferral 1444 procedure MAY optionally be associated with the registration. 1445 . If the registration is in the Active state, then the bundle 1446 MUST be delivered automatically as soon as it is the next 1447 bundle that is due for delivery according to the BPA's bundle 1448 delivery scheduling policy, an implementation matter. 1449 . If the registration is in the Passive state, or if delivery of 1450 the bundle fails for some implementation-specific reason, then 1451 the registration's delivery failure action MUST be taken. 1452 Delivery failure action MUST be one of the following: 1454 o defer delivery of the bundle subject to this registration 1455 until (a) this bundle is the least recently received of 1456 all bundles currently deliverable subject to this 1457 registration and (b) either the registration is polled or 1458 else the registration is in the Active state, and also 1459 perform any additional delivery deferral procedure 1460 associated with the registration; or 1462 o abandon delivery of the bundle subject to this registration 1463 (as defined in 3.1. ). 1465 Step 3: As soon as the bundle has been delivered, if the "request 1466 reporting of bundle delivery" flag in the bundle's status report 1467 request field is set to 1 and bundle status reporting is enabled, 1468 then a bundle delivery status report SHOULD be generated, destined 1469 for the bundle's report-to endpoint ID. Note that this status report 1470 only states that the payload has been delivered to the application 1471 agent, not that the application agent has processed that payload. 1473 5.8. Bundle Fragmentation 1475 It may at times be advantageous for bundle protocol agents to reduce 1476 the sizes of bundles in order to forward them. This might be the 1477 case, for example, if a node to which a bundle is to be forwarded is 1478 accessible only via intermittent contacts and no upcoming contact is 1479 long enough to enable the forwarding of the entire bundle. 1481 The size of a bundle can be reduced by "fragmenting" the bundle. To 1482 fragment a bundle whose payload is of size M is to replace it with 1483 two "fragments" -- new bundles with the same source node ID and 1484 creation timestamp as the original bundle -- whose payloads are the 1485 first N and the last (M - N) bytes of the original bundle's payload, 1486 where 0 < N < M. Note that fragments may themselves be fragmented, 1487 so fragmentation may in effect replace the original bundle with more 1488 than two fragments. (However, there is only one 'level' of 1489 fragmentation, as in IP fragmentation.) 1490 Any bundle whose primary block's bundle processing flags do NOT 1491 indicate that it must not be fragmented MAY be fragmented at any 1492 time, for any purpose, at the discretion of the bundle protocol 1493 agent. NOTE, however, that some combinations of bundle 1494 fragmentation, replication, and routing might result in unexpected 1495 traffic patterns. 1497 Fragmentation SHALL be constrained as follows: 1499 . The concatenation of the payloads of all fragments produced by 1500 fragmentation MUST always be identical to the payload of the 1501 fragmented bundle (that is, the bundle that is being 1502 fragmented). Note that the payloads of fragments resulting from 1503 different fragmentation episodes, in different parts of the 1504 network, may be overlapping subsets of the fragmented bundle's 1505 payload. 1506 . The primary block of each fragment MUST differ from that of the 1507 fragmented bundle, in that the bundle processing flags of the 1508 fragment MUST indicate that the bundle is a fragment and both 1509 fragment offset and total application data unit length must be 1510 provided. Additionally, the CRC of the primary block of the 1511 fragmented bundle, if any, MUST be replaced in each fragment by 1512 a new CRC computed for the primary block of that fragment. 1513 . The payload blocks of fragments will differ from that of the 1514 fragmented bundle as noted above. 1515 . If the fragmented bundle is not a fragment or is the fragment 1516 with offset zero, then all extension blocks of the fragmented 1517 bundle MUST be replicated in the fragment whose offset is zero. 1518 . Each of the fragmented bundle's extension blocks whose "Block 1519 must be replicated in every fragment" flag is set to 1 MUST be 1520 replicated in every fragment. 1521 . Beyond these rules, replication of extension blocks in the 1522 fragments is an implementation matter. 1524 5.9. Application Data Unit Reassembly 1526 If the concatenation -- as informed by fragment offsets and payload 1527 lengths -- of the payloads of all previously received fragments with 1528 the same source node ID and creation timestamp as this fragment, 1529 together with the payload of this fragment, forms a byte array whose 1530 length is equal to the total application data unit length in the 1531 fragment's primary block, then: 1533 . This byte array -- the reassembled application data unit -- 1534 MUST replace the payload of this fragment. 1536 . The "Reassembly pending" retention constraint MUST be removed 1537 from every other fragment whose payload is a subset of the 1538 reassembled application data unit. 1540 Note: reassembly of application data units from fragments occurs at 1541 the nodes that are members of destination endpoints as necessary; an 1542 application data unit MAY also be reassembled at some other node on 1543 the path to the destination. 1545 5.10. Bundle Deletion 1547 The steps in deleting a bundle are: 1549 Step 1: If the "request reporting of bundle deletion" flag in the 1550 bundle's status report request field is set to 1, and if status 1551 reporting is enabled, then a bundle deletion status report citing 1552 the reason for deletion SHOULD be generated, destined for the 1553 bundle's report-to endpoint ID. 1555 Step 2: All of the bundle's retention constraints MUST be removed. 1557 5.11. Discarding a Bundle 1559 As soon as a bundle has no remaining retention constraints it MAY be 1560 discarded, thereby releasing any persistent storage that may have 1561 been allocated to it. 1563 5.12. Canceling a Transmission 1565 When requested to cancel a specified transmission, where the bundle 1566 created upon initiation of the indicated transmission has not yet 1567 been discarded, the bundle protocol agent MUST delete that bundle 1568 for the reason "transmission cancelled". For this purpose, the 1569 procedure defined in Section 5.10 MUST be followed. 1571 6. Administrative Record Processing 1573 6.1. Administrative Records 1575 Administrative records are standard application data units that are 1576 used in providing some of the features of the Bundle Protocol. One 1577 type of administrative record has been defined to date: bundle 1578 status reports. Note that additional types of administrative 1579 records may be defined by supplementary DTN protocol specification 1580 documents. 1582 Every administrative record consists of: 1584 . Record type code (an unsigned integer for which valid values 1585 are as defined below). 1586 . Record content in type-specific format. 1588 Valid administrative record type codes are defined as follows: 1590 +---------+--------------------------------------------+ 1592 | Value | Meaning | 1594 +=========+============================================+ 1596 | 1 | Bundle status report. | 1598 +---------+--------------------------------------------+ 1600 | (other) | Reserved for future use. | 1602 +---------+--------------------------------------------+ 1604 Figure 3: Administrative Record Type Codes 1606 Each BP administrative record SHALL be represented as a CBOR array 1607 comprising a 2-tuple. 1609 The first item of the array SHALL be a record type code, which SHALL 1610 be represented as a CBOR unsigned integer. 1612 The second element of this array SHALL be the applicable CBOR 1613 representation of the content of the record. Details of the CBOR 1614 representation of administrative record type 1 are provided below. 1615 Details of the CBOR representation of other types of administrative 1616 record type are included in the specifications defining those 1617 records. 1619 6.1.1. Bundle Status Reports 1621 The transmission of "bundle status reports" under specified 1622 conditions is an option that can be invoked when transmission of a 1623 bundle is requested. These reports are intended to provide 1624 information about how bundles are progressing through the system, 1625 including notices of receipt, forwarding, final delivery, and 1626 deletion. They are transmitted to the Report-to endpoints of 1627 bundles. 1629 Each bundle status report SHALL be represented as a CBOR array. The 1630 number of elements in the array SHALL be either 6 (if the subject 1631 bundle is a fragment) or 4 (otherwise). 1633 The first item of the bundle status report array SHALL be bundle 1634 status information represented as a CBOR array of at least 4 1635 elements. The first four items of the bundle status information 1636 array shall provide information on the following four status 1637 assertions, in this order: 1639 . Reporting node received bundle. 1640 . Reporting node forwarded the bundle. 1641 . Reporting node delivered the bundle. 1642 . Reporting node deleted the bundle. 1644 Each item of the bundle status information array SHALL be a bundle 1645 status item represented as a CBOR array; the number of elements in 1646 each such array SHALL be either 2 (if the value of the first item of 1647 this bundle status item is 1 AND the "Report status time" flag was 1648 set to 1 in the bundle processing flags of the bundle whose status 1649 is being reported) or 1 (otherwise). The first item of the bundle 1650 status item array SHALL be a status indicator, a Boolean value 1651 indicating whether or not the corresponding bundle status is 1652 asserted, represented as a CBOR Boolean value. The second item of 1653 the bundle status item array, if present, SHALL indicate the time 1654 (as reported by the local system clock, an implementation matter) at 1655 which the indicated status was asserted for this bundle, represented 1656 as a DTN time as described in Section 4.1.6. above. 1658 The second item of the bundle status report array SHALL be the 1659 bundle status report reason code explaining the value of the status 1660 indicator, represented as a CBOR unsigned integer. Valid status 1661 report reason codes are defined in Figure 4 below but the list of 1662 status report reason codes provided here is neither exhaustive nor 1663 exclusive; supplementary DTN protocol specifications (including, but 1664 not restricted to, the Bundle Security Protocol [BPSEC]) may define 1665 additional reason codes. 1667 +---------+--------------------------------------------+ 1669 | Value | Meaning | 1671 +=========+============================================+ 1673 | 0 | No additional information. | 1675 +---------+--------------------------------------------+ 1676 | 1 | Lifetime expired. | 1678 +---------+--------------------------------------------+ 1680 | 2 | Forwarded over unidirectional link. | 1682 +---------+--------------------------------------------+ 1684 | 3 | Transmission canceled. | 1686 +---------+--------------------------------------------+ 1688 | 4 | Depleted storage. | 1690 +---------+--------------------------------------------+ 1692 | 5 | Destination endpoint ID unintelligible. | 1694 +---------+--------------------------------------------+ 1696 | 6 | No known route to destination from here. | 1698 +---------+--------------------------------------------+ 1700 | 7 | No timely contact with next node on route. | 1702 +---------+--------------------------------------------+ 1704 | 8 | Block unintelligible. | 1706 +---------+--------------------------------------------+ 1708 | 9 | Hop limit exceeded. | 1710 +---------+--------------------------------------------+ 1712 | 10 | Traffic pared (e.g., status reports). | 1714 +---------+--------------------------------------------+ 1716 | (other) | Reserved for future use. | 1718 +---------+--------------------------------------------+ 1720 Figure 4: Status Report Reason Codes 1722 The third item of the bundle status report array SHALL be the source 1723 node ID identifying the source of the bundle whose status is being 1724 reported, represented as described in Section 4.1.5.2. above. 1726 The fourth item of the bundle status report array SHALL be the 1727 creation timestamp of the bundle whose status is being reported, 1728 represented as described in Section 4.1.7. above. 1730 The fifth item of the bundle status report array SHALL be present if 1731 and only if the bundle whose status is being reported contained a 1732 fragment offset. If present, it SHALL be the subject bundle's 1733 fragment offset represented as a CBOR unsigned integer item. 1735 The sixth item of the bundle status report array SHALL be present if 1736 and only if the bundle whose status is being reported contained a 1737 fragment offset. If present, it SHALL be the length of the subject 1738 bundle's payload represented as a CBOR unsigned integer item. 1740 Note that the forwarding parameters (such as lifetime, applicable 1741 security measures, etc.) of the bundle whose status is being 1742 reported MAY be reflected in the parameters governing the forwarding 1743 of the bundle that conveys a status report, but this is an 1744 implementation matter. Bundle protocol deployment experience to 1745 date has not been sufficient to suggest any clear guidance on this 1746 topic. 1748 6.2. Generation of Administrative Records 1750 Whenever the application agent's administrative element is directed 1751 by the bundle protocol agent to generate an administrative record 1752 with reference to some bundle, the following procedure must be 1753 followed: 1755 Step 1: The administrative record must be constructed. If the 1756 administrative record references a bundle and the referenced bundle 1757 is a fragment, the administrative record MUST contain the fragment 1758 offset and fragment length. 1760 Step 2: A request for transmission of a bundle whose payload is this 1761 administrative record MUST be presented to the bundle protocol 1762 agent. 1764 7. Services Required of the Convergence Layer 1766 7.1. The Convergence Layer 1768 The successful operation of the end-to-end bundle protocol depends 1769 on the operation of underlying protocols at what is termed the 1770 "convergence layer"; these protocols accomplish communication 1771 between nodes. A wide variety of protocols may serve this purpose, 1772 so long as each convergence layer protocol adapter provides a 1773 defined minimal set of services to the bundle protocol agent. This 1774 convergence layer service specification enumerates those services. 1776 7.2. Summary of Convergence Layer Services 1778 Each convergence layer protocol adapter is expected to provide the 1779 following services to the bundle protocol agent: 1781 . sending a bundle to a bundle node that is reachable via the 1782 convergence layer protocol; 1783 . notifying the bundle protocol agent when it has concluded its 1784 data sending procedures with regard to a bundle; 1785 . delivering to the bundle protocol agent a bundle that was sent 1786 by a bundle node via the convergence layer protocol. 1788 The convergence layer service interface specified here is neither 1789 exhaustive nor exclusive. That is, supplementary DTN protocol 1790 specifications (including, but not restricted to, the Bundle 1791 Security Protocol [BPSEC]) may expect convergence layer adapters 1792 that serve BP implementations conforming to those protocols to 1793 provide additional services such as reporting on the transmission 1794 and/or reception progress of individual bundles (at completion 1795 and/or incrementally), retransmitting data that were lost in 1796 transit, discarding bundle-conveying data units that the convergence 1797 layer protocol determines are corrupt or inauthentic, or reporting 1798 on the integrity and/or authenticity of delivered bundles. 1800 8. Implementation Status 1802 [NOTE to the RFC Editor: please remove this section before 1803 publication, as well as the reference to RFC 7942.] 1805 This section records the status of known implementations of the 1806 protocol defined by this specification at the time of posting of 1807 this Internet-Draft, and is based on a proposal described in RFC 1808 7942. The description of implementations in this section is 1809 intended to assist the IETF in its decision processes in progressing 1810 drafts to RFCs. Please note that the listing of any individual 1811 implementation here does not imply endorsement by the IETF. 1812 Furthermore, no effort has been spent to verify the information 1813 presented here that was supplied by IETF contributors. This is not 1814 intended as, and must not be construed to be, a catalog of available 1815 implementations or their features. Readers are advised to note that 1816 other implementations may exist. 1818 According to RFC 7942, "this will allow reviewers and working groups 1819 to assign due consideration to documents that have the benefit of 1820 running code, which may serve as evidence of valuable 1821 experimentation and feedback that have made the implemented 1822 protocols more mature. It is up to the individual working groups to 1823 use this information as they see fit". 1825 At the time of this writing, there are three known implementations 1826 of the current document. 1828 The first known implementation is microPCN (https://upcn.eu/). 1829 According to the developers: 1831 The Micro Planetary Communication Network (uPCN) is a free 1832 software project intended to offer an implementation of Delay- 1833 tolerant Networking protocols for POSIX operating systems (well, 1834 and for Linux) plus for the ARM Cortex STM32F4 microcontroller 1835 series. More precisely it currently provides an implementation of 1837 . the Bundle Protocol (BP, RFC 5050), 1838 . the Bundle Protocol version 7 specification draft (version 6), 1839 . the DTN IP Neighbor Discovery (IPND) protocol, and 1840 . a routing approach optimized for message-ferry micro LEO 1841 satellites. 1843 uPCN is written in C and is built upon the real-time operating 1844 system FreeRTOS. The source code of uPCN is released under the 1845 "BSD 3-Clause License". 1847 The project depends on an execution environment offering link 1848 layer protocols such as AX.25. The source code uses the USB 1849 subsystem to interact with the environment. 1851 The second known implementation is PyDTN, developed by X-works, 1852 s.r.o (https://x-works.sk/). The final third of the implementation 1853 was developed during the IETF 101 Hackathon. According to the 1854 developers, PyDTN implements bundle coding/decoding and neighbor 1855 discovery. PyDTN is written in Python and has been shown to be 1856 interoperable with uPCN. 1858 The third known implementation is "Terra" 1859 (https://github.com/RightMesh/Terra/), a Java implementation 1860 developed in the context of terrestrial DTN. It includes an 1861 implementation of a "minimal TCP" convergence layer adapter. 1863 9. Security Considerations 1865 The bundle protocol security architecture and the available security 1866 services are specified in an accompanying document, the Bundle 1867 Security Protocol specification [BPSEC]. 1869 The bpsec extensions to Bundle Protocol enable each block of a 1870 bundle (other than a bpsec extension block) to be individually 1871 authenticated by a signature block (Block Integrity Block, or BIB) 1872 and also enable each block of a bundle other than the primary block 1873 (and the bpsec extension blocks themselves) to be individually 1874 encrypted by a BCB. 1876 Because the security mechanisms are extension blocks that are 1877 themselves inserted into the bundle, the integrity and 1878 confidentiality of bundle blocks are protected while the bundle is 1879 at rest, awaiting transmission at the next forwarding opportunity, 1880 as well as in transit. 1882 Additionally, convergence-layer protocols that ensure authenticity 1883 of communication between adjacent nodes in BP network topology 1884 SHOULD be used where available, to minimize the ability of 1885 unauthenticated nodes to introduce inauthentic traffic into the 1886 network. Convergence-layer protocols that ensure confidentiality of 1887 communication between adjacent nodes in BP network topology SHOULD 1888 also be used where available, to minimize exposure of the bundle's 1889 primary block and other clear-text blocks, thereby offering some 1890 defense against traffic analysis. 1892 Note that, while the primary block must remain in the clear for 1893 routing purposes, the Bundle Protocol can be protected against 1894 traffic analysis to some extent by using bundle-in-bundle 1895 encapsulation to tunnel bundles to a safe forward distribution 1896 point: the encapsulated bundle forms the payload of an encapsulating 1897 bundle, and that payload block may be encrypted by a BCB. 1899 Note that the generation of bundle status reports is disabled by 1900 default because malicious initiation of bundle status reporting 1901 could result in the transmission of extremely large numbers of 1902 bundles, effecting a denial of service attack. 1904 The bpsec extensions accommodate an open-ended range of 1905 ciphersuites; different ciphersuites may be utilized to protect 1906 different blocks. One possible variation is to sign and/or encrypt 1907 blocks using symmetric keys securely formed by Diffie-Hellman 1908 procedures (such as EKDH) using the public and private keys of the 1909 sending and receiving nodes. For this purpose, the key distribution 1910 problem reduces to the problem of trustworthy delay-tolerant 1911 distribution of public keys, a current research topic. 1913 Bundle security MUST NOT be invalidated by forwarding nodes even 1914 though they themselves might not use the Bundle Security Protocol. 1916 In particular, while blocks MAY be added to bundles transiting 1917 intermediate nodes, removal of blocks with the "Discard block if it 1918 can't be processed" flag set in the block processing control flags 1919 may cause security to fail. 1921 Inclusion of the Bundle Security Protocol in any Bundle Protocol 1922 implementation is RECOMMENDED. Use of the Bundle Security Protocol 1923 in Bundle Protocol operations is OPTIONAL, subject to the following 1924 guidelines: 1926 . Every block (that is not a bpsec extension block) of every 1927 bundle SHOULD be authenticated by a BIB citing the ID of the 1928 node that inserted that block. (Note that a single BIB may 1929 authenticate multiple "target" blocks.) BIB authentication MAY 1930 be omitted on (and only on) any initial end-to-end path 1931 segments on which it would impose unacceptable overhead, 1932 provided that satisfactory authentication is ensured at the 1933 convergence layer and that BIB authentication is asserted on 1934 the first path segment on which the resulting overhead is 1935 acceptable and on all subsequent path segments. 1936 . If any segment of the end-to-end path of a bundle will traverse 1937 the Internet or any other potentially insecure communication 1938 environment, then the payload block SHOULD be encrypted by a 1939 BCB on this path segment and all subsequent segments of the 1940 end-to-end path. 1942 10. IANA Considerations 1944 The Bundle Protocol includes fields requiring registries managed by 1945 IANA. 1947 10.1. Bundle Block Types 1949 IANA is requested to add values 2-9, as noted below, to the Bundle 1950 Block Type registry. In addition, the value "0" was not defined in 1951 that registry; as per consensus by the DTN working group, it is 1952 reserved per this document. 1954 +--------------+---------------------------------+---------------+ 1956 | Value | Description | Reference | 1958 +--------------+---------------------------------+---------------+ 1960 | 0 | Reserved | This document | 1962 | 2 | Block Integrity Block | [BPSEC] | 1964 | 3 | Block Confidentiality Block | [BPSEC] | 1966 | 4-6 | Reserved | section 4.3 | 1968 | 7 | Previous node (proximate sender)| section 4.3.1 | 1970 | 8 | Bundle age (in seconds) | section 4.3.2 | 1972 | 9 | Hop count (#prior xmit attempts)| section 4.3.3 | 1974 +--------------+---------------------------------+---------------+ 1976 10.2. Primary Bundle Protocol Version 1978 IANA is requested to add value 7, as noted below, to the Primary 1979 Bundle Protocol Version registry. In addition, the values "0-5" 1980 were not defined in that registry; as per consensus by the DTN 1981 working group, they are reserved per this document. 1983 +-------+-------------+---------------+ 1985 | Value | Description | Reference | 1987 +-------+-------------+---------------+ 1989 | 0-5 | Reserved | This document | 1991 | 7 | Assigned | section 4.2.2 | 1993 +-------+-------------+---------------+ 1995 10.3. Bundle Processing Control Flags 1997 The Bundle Protocol has a Bundle Processing Control Flags field 1998 (Section 4.1.3) for which IANA is requested to create and maintain a 1999 new registry named "BPv7 Bundle Processing Control Flags". Initial 2000 values for this registry are given below. 2002 The registration policy for this registry is: Specification 2003 Required. The nominated expert(s) verify that a specification 2004 exists and is readily accessible. Specifications for new 2005 registrations need to describe in detail the manner in which bundle 2006 processing is affected by the new flag settings. Expert(s) are 2007 encouraged to be biased towards approving registrations unless they 2008 are abusive, frivolous, or actively harmful (not merely 2009 aesthetically displeasing, or architecturally dubious). 2011 The value range is: variable length. Maximum number of flag bit 2012 positions: 16. 2014 Bundle Processing Control Flags Registry 2016 +--------------------+----------------------------------+----------+ 2018 | Bit Position | Description | Reference| 2020 | (right to left) | | | 2022 +--------------------+----------------------------------+----------+ 2024 | 0 | Bundle is a fragment | 4.1.3 | 2026 | 1 | Application data unit is an | 4.1.3 | 2028 | | administrative record | | 2030 | 2 | Bundle must not be fragmented | 4.1.3 | 2032 | 3 | reserved | 4.1.3 | 2034 | 4 | reserved | 4.1.3 | 2036 | 5 | Acknowledgement by application | 4.1.3 | 2038 | | is requested | | 2040 | 6 | Status time requested in reports | 4.1.3 | 2041 | 7 | Reserved | 4.1.3 | 2043 | 8 | Request reporting of bundle | 4.1.3 | 2045 | | reception | | 2047 | 9 | Reserved | 4.1.3 | 2049 | 10 | Request reporting of bundle | 4.1.3 | 2051 | | forwarding | | 2053 | 11 | Request reporting of bundle | 4.1.3 | 2055 | | delivery | | 2057 | 12 | Request reporting of bundle | 4.1.3 | 2059 | | deletion | | 2061 | 13-15 | Unassigned | | 2063 +--------------------+----------------------------------+----------+ 2065 10.4. Block Processing Control Flags 2067 The Bundle Protocol has a Block Processing Control Flags field 2068 (Section 4.1.4) for which IANA is requested to create and maintain a 2069 new registry named "BPv7 Block Processing Control Flags". Initial 2070 values for this registry are given below. 2072 The registration policy for this registry is: Specification 2073 Required. The nominated expert(s) verify that a specification 2074 exists and is readily accessible. Specifications for new 2075 registrations need to describe in detail the manner in which block 2076 processing is affected by the new flag settings. Expert(s) are 2077 encouraged to be biased towards approving registrations unless they 2078 are abusive, frivolous, or actively harmful (not merely 2079 aesthetically displeasing, or architecturally dubious). 2081 The value range is: variable length. Maximum number of flag bit 2082 positions: 8. 2084 Block Processing Control Flags Registry 2086 +--------------------+----------------------------------+----------+ 2087 | Bit Position | Description | Reference| 2089 | (right to left) | | | 2091 +--------------------+----------------------------------+----------+ 2093 | 0 | Block must be replicated in | 4.1.4 | 2095 | | every fragment | | 2097 | 1 | Discard block if it can't be | 4.1.4 | 2099 | | processed | | 2101 | 2 | Transmit status report if block | 4.1.4 | 2103 | | can't be processed | | 2105 | 3 | Delete bundle if block can't be | 4.1.4 | 2107 | | processed | | 2109 | 4-7 | Reserved | | 2111 +--------------------+----------------------------------+----------+ 2113 10.5. Bundle Status Report Reason Codes 2115 The Bundle Protocol has a Bundle Status Report Reason Codes field 2116 (Section 6.1.1) for which IANA is requested to create and maintain a 2117 new registry named "BPv7 Bundle Status Report Reason Codes". 2118 Initial values for this registry are given below. 2120 The registration policy for this registry is: Specification 2121 Required. The nominated expert(s) verify that a specification exists 2122 and is readily accessible. Specifications for new registrations need 2123 to describe in detail the conditions under which bundle processing 2124 may result in the transmission of status reports annotated with the 2125 new reason codes. Expert(s) are encouraged to be biased towards 2126 approving registrations unless they are abusive, frivolous, or 2127 actively harmful (not merely aesthetically displeasing, or 2128 architecturally dubious). 2130 The value range is: unsigned 8-bit integer. 2132 Bundle Status Report Reason Codes Registry 2134 +-------+-------------------------------------------+--------------+ 2136 | Value | Description | Reference | 2138 +-------+-------------------------------------------+--------------+ 2140 | 0 | No additional information | 6.1.1 | 2142 | 1 | Lifetime expired | 6.1.1 | 2144 | 2 | Forwarded over unidirectional link | 6.1.1 | 2146 | 3 | Transmission canceled | 6.1.1 | 2148 | 4 | Depleted storage | 6.1.1 | 2150 | 5 | Destination endpoint ID unintelligible | 6.1.1 | 2152 | 6 | No known route to destination from here | 6.1.1 | 2154 | 7 | No timely contact with next node on route | 6.1.1 | 2156 | 8 | Block unintelligible | 6.1.1 | 2158 | 9 | Hop limit exceeded | 6.1.1 | 2160 | 10 | Traffic pared | 6.1.1 | 2162 |11-254 | Unassigned | | 2164 | 255 | Reserved | | 2166 +-------+-------------------------------------------+--------------+ 2168 10.6. URI scheme type codes 2170 The Bundle Protocol has a URI scheme type field - an unsigned 2171 integer of undefined length - for which IANA is requested to create 2172 and maintain a new registry named "URI scheme type codes". Initial 2173 values for the Bundle Protocol URI scheme type code registry are 2174 given below. 2176 The registration policy for this registry is: Specification 2177 Required. The nominated expert(s) verify that a specification exists 2178 and is readily accessible. Specifications for new registrations need 2179 to reference the documents defining the URIs for which new codes are 2180 being registered. Expert(s) are encouraged to be biased towards 2181 approving registrations unless they are abusive, frivolous, or 2182 actively harmful (not merely aesthetically displeasing, or 2183 architecturally dubious). 2185 The value range is: unsigned 8-bit integer. 2187 Each assignment consists of a URI scheme type name and its 2188 associated value. 2190 URI Scheme Type Codes Registry 2192 +--------------+-----------------------------+-------------------+ 2194 | Value | Description | Reference | 2196 +--------------+-----------------------------+-------------------+ 2198 | 0 | Reserved | | 2200 | 1 | dtn | section 10.7 | 2202 | 2 | ipn | RFC6260, Section 4| 2204 | 3-254 | Unassigned | | 2206 | 255 | reserved | | 2208 +--------------+-----------------------------+-------------------+ 2210 10.7. New URI scheme "dtn" 2212 IANA is requested to register a URI scheme with the string "dtn" as 2213 the scheme name, as follows: 2215 URI scheme name: "dtn" 2217 Status: permanent 2219 URI scheme syntax: 2221 This specification uses the Augmented Backus-Naur Form (ABNF) 2222 notation of [RFC5234]. 2224 dtn-uri = "dtn:" dtn-hier-part 2225 dtn-hier-part = "//" node-name name-delim demux ; a path-rootless 2227 node-name = 1*VCHAR 2229 name-delim = "/" 2231 demux = *VCHAR 2233 None of the reserved characters defined in the generic URI syntax 2234 are used as delimiters within URIs of the DTN scheme. 2236 URI scheme semantics: URIs of the DTN scheme are used as endpoint 2237 identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol 2238 (BP) as described in Section 4.1.5.1. 2240 Encoding considerations: URIs of the DTN scheme are encoded 2241 exclusively in US-ASCII characters. 2243 Applications and/or protocols that use this URI scheme name: the 2244 Delay-Tolerant Networking (DTN) Bundle Protocol (BP). 2246 Interoperability considerations: as noted above, URIs of the DTN 2247 scheme are encoded exclusively in US-ASCII characters. 2249 Security considerations: 2251 . Reliability and consistency: none of the BP endpoints 2252 identified by the URIs of the DTN scheme are guaranteed to be 2253 reachable at any time, and the identity of the processing 2254 entities operating on those endpoints is never guaranteed by 2255 the Bundle Protocol itself. Bundle authentication as defined by 2256 the Bundle Security Protocol is required for this purpose. 2257 . Malicious construction: malicious construction of a conformant 2258 DTN-scheme URI is limited to the malicious selection of node 2259 names and the malicious selection of demux strings. That is, a 2260 maliciously constructed DTN-scheme URI could be used to direct 2261 a bundle to an endpoint that might be damaged by the arrival of 2262 that bundle or, alternatively, to declare a false source for a 2263 bundle and thereby cause incorrect processing at a node that 2264 receives the bundle. In both cases (and indeed in all bundle 2265 processing), the node that receives a bundle should verify its 2266 authenticity and validity before operating on it in any way. 2267 . Back-end transcoding: the limited expressiveness of URIs of the 2268 DTN scheme effectively eliminates the possibility of threat due 2269 to errors in back-end transcoding. 2270 . Rare IP address formats: not relevant, as IP addresses do not 2271 appear anywhere in conformant DTN-scheme URIs. 2273 . Sensitive information: because DTN-scheme URIs are used only to 2274 represent the identities of Bundle Protocol endpoints, the risk 2275 of disclosure of sensitive information due to interception of 2276 these URIs is minimal. Examination of DTN-scheme URIs could be 2277 used to support traffic analysis; where traffic analysis is a 2278 plausible danger, bundles should be conveyed by secure 2279 convergence-layer protocols that do not expose endpoint IDs. 2280 . Semantic attacks: the simplicity of DTN-scheme URI syntax 2281 minimizes the possibility of misinterpretation of a URI by a 2282 human user. 2284 Contact: 2286 Scott Burleigh 2288 Jet Propulsion Laboratory, 2290 California Institute of Technology 2292 scott.c.burleigh@jpl.nasa.gov 2294 +1 (800) 393-3353 2296 Author/Change controller: 2298 Scott Burleigh 2300 Jet Propulsion Laboratory, 2302 California Institute of Technology 2304 scott.c.burleigh@jpl.nasa.gov 2306 10.8. Change status of URI scheme "ipn" 2308 IANA is requested to change to "permanent" the status of the URI 2309 scheme named "ipn". 2311 11. References 2313 11.1. Normative References 2315 [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work 2316 In Progress, October 2015. 2318 [CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4, 2319 International Telecommunications Union, October 1996. 2321 [CRC32C] Castagnoli, G., Brauer, S., and M. Herrmann, "Optimization 2322 of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE 2323 Transact. on Communications, Vol. 41, No. 6, June 1993. 2325 [EPOCH] Thompson, K. and D. M. Ritchie, "UNIX Programmer's Manual, 2326 Fifth Edition", Bell Telephone Laboratories Inc., June 1974. See 2327 https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man. 2328 pdf. 2330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2331 Requirement Levels", BCP 14, RFC 2119, March 1997. 2333 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2334 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2336 [RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object 2337 Representation (CBOR)", RFC 7049, October 2013. 2339 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2340 2119 Key Words", BCP 14, RFC 8174, May 2017. 2342 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2343 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 2344 January 2005. 2346 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2347 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 2348 2015. 2350 11.2. Informative References 2352 [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 2353 4838, April 2007. 2355 [BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", Work In 2356 Progress, June 2017. 2358 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 2359 Identifiers (IRIs)", RFC 3987, January 2005. 2361 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 2362 Specification", RFC 5050, November 2007. 2364 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, 2365 "Internet Small Computer System Interface (iSCSI) Protocol 2366 (Consolidated)", RFC 7143, April 2014. 2368 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 2369 Challenged Internets", SIGCOMM 2003. 2371 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 2372 historical background and perspectives" in "Journees systemes de 2373 reference spatio-temporels", 2004. 2375 12. Acknowledgments 2377 This work is freely adapted from RFC 5050, which was an effort of 2378 the Delay Tolerant Networking Research Group. The following DTNRG 2379 participants contributed significant technical material and/or 2380 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 2381 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 2382 Michael Demmer of the University of California at Berkeley, Robert 2383 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 2384 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 2385 College Dublin, Howard Weiss and Peter Lovell of SPARTA, Inc., and 2386 Manikantan Ramadas of Ohio University. 2388 This document was prepared using 2-Word-v2.0.template.dot. 2390 13. Significant Changes from RFC 5050 2392 Points on which this draft significantly differs from RFC 5050 2393 include the following: 2395 . Clarify the difference between transmission and forwarding. 2396 . Migrate custody transfer to the bundle-in-bundle encapsulation 2397 specification [BIBE]. 2398 . Introduce the concept of "node ID" as functionally distinct 2399 from endpoint ID, while having the same syntax. 2400 . Restructure primary block, making it immutable. Add optional 2401 CRC. 2402 . Add optional CRCs to non-primary blocks. 2403 . Add block ID number to canonical block format (to support 2404 BPSEC). 2405 . Add definition of bundle age extension block. 2406 . Add definition of previous node extension block. 2407 . Add definition of hop count extension block. 2408 . Remove Quality of Service markings. 2409 . Change from SDNVs to CBOR representation. 2411 Appendix A. For More Information 2413 Please refer comments to dtn@ietf.org. DTN Working Group documents 2414 are located at https://datatracker.ietf.org/wg/dtn/documents. The 2415 original Delay Tolerant Networking Research Group (DTNRG) Web site 2416 is located at https://irtf.org/concluded/dtnrg. 2418 Copyright (c) 2019 IETF Trust and the persons identified as authors 2419 of the code. All rights reserved. 2421 Redistribution and use in source and binary forms, with or without 2422 modification, is permitted pursuant to, and subject to the license 2423 terms contained in, the Simplified BSD License set forth in Section 2424 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2425 (http://trustee.ietf.org/license-info). 2427 Appendix B. CDDL expression 2429 For informational purposes, Carsten Bormann and Brian Sipos have 2430 kindly provided an expression of the Bundle Protocol specification 2431 in the Concise Data Definition Language (CDDL). That CDDL 2432 expression is presented below. Note that wherever the CDDL 2433 expression is in disagreement with the textual representation of the 2434 BP specification presented in the earlier sections of this document, 2435 the textual representation rules. 2437 start = bundle / #6.55799(bundle) 2439 ; Times before 2000 are invalid 2441 dtn-time = uint 2443 ; CRC enumerated type 2445 crc-type = &( 2447 crc-none: 0, 2449 crc-16bit: 1, 2451 crc-32bit: 2 2453 ) 2455 ; Either 16-bit or 32-bit 2457 crc-value = (bstr .size 2) / (bstr .size 4) 2459 creation-timestamp = [ 2461 dtn-time, ; absolute time of creation 2463 sequence: uint ; sequence within the time 2465 ] 2467 eid = $eid .within eid-structure 2469 eid-structure = [ 2471 uri-code: uint, 2472 SSP: any 2474 ] 2476 $eid /= [ 2478 uri-code: 1, 2480 SSP: (tstr / 0) 2482 ] 2484 $eid /= [ 2486 uri-code: 2, 2488 SSP: [ 2490 nodenum: uint, 2492 servicenum: uint 2494 ] 2496 ] 2498 ; The root bundle array 2500 bundle = [primary-block, *extension-block, payload-block] 2502 primary-block = [ 2504 version: 7, 2506 bundle-control-flags, 2508 crc-type, 2510 destination: eid, 2512 source-node: eid, 2514 report-to: eid, 2516 creation-timestamp, 2518 lifetime: uint, 2519 ? ( 2521 fragment-offset: uint, 2523 total-application-data-length: uint 2525 ), 2527 ? crc-value, 2529 ] 2531 bundle-control-flags = uint .bits bundleflagbits 2533 bundleflagbits = &( 2535 reserved: 15, 2537 reserved: 14, 2539 reserved: 13, 2541 bundle-deletion-status-reports-are-requested: 12, 2543 bundle-delivery-status-reports-are-requested: 11, 2545 bundle-forwarding-status-reports-are-requested: 10, 2547 reserved: 9, 2549 bundle-reception-status-reports-are-requested: 8, 2551 bundle-contains-a-Manifest-block: 7, 2553 status-time-is-requested-in-all-status-reports: 6, 2555 user-application-acknowledgement-is-requested: 5, 2557 reserved: 4, 2559 reserved: 3, 2561 bundle-must-not-be-fragmented: 2, 2563 payload-is-an-administrative-record: 1, 2565 bundle-is-a-fragment: 0 2567 ) 2569 ; Abstract shared structure of all non-primary blocks 2571 canonical-block-structure = [ 2573 block-type-code: uint, 2575 block-number: uint, 2577 block-control-flags, 2579 crc-type, 2581 ; Each block type defines the content within the bytestring 2583 block-type-specific-data, 2585 ? crc-value 2587 ] 2589 block-control-flags = uint .bits blockflagbits 2591 blockflagbits = &( 2593 reserved: 7, 2595 reserved: 6, 2597 reserved: 5, 2599 reserved: 4, 2601 bundle-must-be-deleted-if-block-cannot-be-processed: 3, 2603 status-report-must-be-transmitted-if-block-cannot-be-processed: 2, 2605 block-must-be-removed-from-bundle-if-it-cannot-be-processed: 1, 2607 block-must-be-replicated-in-every-fragment: 0 2609 ) 2611 block-type-specific-data = bstr / #6.24(bstr) 2612 ; Actual CBOR data embedded in a bytestring, with optional tag to 2613 indicate so 2615 embedded-cbor = (bstr .cbor Item) / #6.24(bstr .cbor Item) 2617 ; Extension block type, which does not specialize other than the 2618 code/number 2620 extension-block = $extension-block-structure .within canonical- 2621 block-structure 2623 ; Generic shared structure of all non-primary blocks 2625 extension-block-use = [ 2627 block-type-code: CodeValue, 2629 block-number: (uint .gt 1), 2631 block-control-flags, 2633 crc-type, 2635 BlockData, 2637 ? crc-value 2639 ] 2641 ; Payload block type 2643 payload-block = payload-block-structure .within canonical-block- 2644 structure 2646 payload-block-structure = [ 2648 block-type-code: 1, 2650 block-number: 1, 2652 block-control-flags, 2654 crc-type, 2656 $payload-block-data, 2658 ? crc-value 2660 ] 2662 ; Arbitrary payload data, including non-CBOR bytestring 2664 $payload-block-data /= block-type-specific-data 2666 ; Administrative record as a payload data specialization 2668 $payload-block-data /= embedded-cbor 2670 admin-record = $admin-record .within admin-record-structure 2672 admin-record-structure = [ 2674 record-type-code: uint, 2676 record-content: any 2678 ] 2680 ; Only one defined record type 2682 $admin-record /= [1, status-record-content] 2684 status-record-content = [ 2686 bundle-status-information, 2688 status-report-reason-code: uint, 2690 source-node-eid: eid, 2692 subject-creation-timestamp: creation-timestamp, 2694 ? ( 2696 subject-payload-offset: uint, 2698 subject-payload-length: uint 2700 ) 2702 ] 2704 bundle-status-information = [ 2706 reporting-node-received-bundle: status-info-content, 2707 reporting-node-forwarded-bundle: status-info-content, 2709 reporting-node-delivered-bundle: status-info-content, 2711 reporting-node-deleted-bundle: status-info-content 2713 ] 2715 status-info-content = [ 2717 status-indicator: bool, 2719 ? timestamp: dtn-time 2721 ] 2723 ; Previous Node extension block 2725 $extension-block-structure /= 2727 extension-block-use<7, embedded-cbor> 2729 ext-data-previous-node = eid 2731 ; Bundle Age extension block 2733 $extension-block-structure /= 2735 extension-block-use<8, embedded-cbor> 2737 ext-data-bundle-age = uint 2739 ; Hop Count extension block 2741 $extension-block-structure /= 2743 extension-block-use<9, embedded-cbor> 2745 ext-data-hop-count = [ 2747 hop-limit: uint, 2749 hop-count: uint 2751 ] 2753 Authors' Addresses 2755 Scott Burleigh 2756 Jet Propulsion Laboratory, California Institute of Technology 2757 4800 Oak Grove Dr. 2758 Pasadena, CA 91109-8099 2759 US 2760 Phone: +1 818 393 3353 2761 Email: Scott.C.Burleigh@jpl.nasa.gov 2763 Kevin Fall 2764 Roland Computing Services 2765 3871 Piedmont Ave. Suite 8 2766 Oakland, CA 94611 2767 US 2768 Email: kfall+rcs@kfall.com 2770 Edward J. Birrane 2771 Johns Hopkins University Applied Physics Laboratory 2772 11100 Johns Hopkins Rd 2773 Laurel, MD 20723 2774 US 2775 Phone: +1 443 778 7423 2776 Email: Edward.Birrane@jhuapl.edu