idnits 2.17.1 draft-ietf-dtn-bpbis-18.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 (January 15, 2020) is 1563 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'BPSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRC16' ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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: July 18, 2020 Roland Computing Services 5 E. Birrane 6 APL, Johns Hopkins University 7 January 15, 2020 9 Bundle Protocol Version 7 10 draft-ietf-dtn-bpbis-18.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 July 18, 2020. 35 Copyright Notice 37 Copyright (c) 2020 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 The Internet Research Task Force is advised that this document is an 58 update of the protocol described in RFC 5050, reflecting lessons 59 learned. The Internet Research Task Force is requested to mark RFC 60 5050 as obsolete. 62 Table of Contents 64 1. Introduction...................................................3 65 2. Conventions used in this document..............................5 66 3. Service Description............................................6 67 3.1. Definitions...............................................6 68 3.2. Discussion of BP concepts.................................9 69 3.3. Services Offered by Bundle Protocol Agents...............12 70 4. Bundle Format.................................................13 71 4.1. BP Fundamental Data Structures...........................13 72 4.1.1. CRC Type............................................13 73 4.1.2. CRC.................................................14 74 4.1.3. Bundle Processing Control Flags.....................14 75 4.1.4. Block Processing Control Flags......................16 76 4.1.5. Identifiers.........................................17 77 4.1.5.1. Endpoint ID....................................17 78 4.1.5.2. Node ID........................................18 79 4.1.6. DTN Time............................................18 80 4.1.7. Creation Timestamp..................................18 81 4.1.8. Block-type-specific Data............................19 82 4.2. Bundle Representation....................................19 83 4.2.1. Bundle..............................................19 84 4.2.2. Primary Bundle Block................................19 85 4.2.3. Canonical Bundle Block Format.......................22 86 4.3. Extension Blocks.........................................22 87 4.3.1. Previous Node.......................................23 88 4.3.2. Bundle Age..........................................23 89 4.3.3. Hop Count...........................................23 90 5. Bundle Processing.............................................24 91 5.1. Generation of Administrative Records.....................24 92 5.2. Bundle Transmission......................................25 93 5.3. Bundle Dispatching.......................................25 94 5.4. Bundle Forwarding........................................26 95 5.4.1. Forwarding Contraindicated..........................28 96 5.4.2. Forwarding Failed...................................28 97 5.5. Bundle Expiration........................................28 98 5.6. Bundle Reception.........................................29 99 5.7. Local Bundle Delivery....................................30 100 5.8. Bundle Fragmentation.....................................31 101 5.9. Application Data Unit Reassembly.........................32 102 5.10. Bundle Deletion.........................................32 103 5.11. Discarding a Bundle.....................................33 104 5.12. Canceling a Transmission................................33 105 6. Administrative Record Processing..............................33 106 6.1. Administrative Records...................................33 107 6.1.1. Bundle Status Reports...............................34 108 6.2. Generation of Administrative Records.....................37 109 7. Services Required of the Convergence Layer....................37 110 7.1. The Convergence Layer....................................37 111 7.2. Summary of Convergence Layer Services....................37 112 8. Implementation Status.........................................38 113 9. Security Considerations.......................................39 114 10. IANA Considerations..........................................40 115 10.1. Bundle Block Types......................................40 116 10.2. Primary Bundle Protocol Version.........................41 117 10.3. Bundle Processing Control Flags.........................42 118 10.4. Block Processing Control Flags..........................44 119 10.5. Bundle Status Report Reason Codes.......................45 120 10.6. Bundle Protocol URI scheme types........................47 121 10.7. URI scheme "dtn"........................................48 122 10.8. Change status of URI scheme "ipn".......................50 123 11. References...................................................50 124 11.1. Normative References....................................50 125 11.2. Informative References..................................50 126 12. Acknowledgments..............................................51 127 13. Significant Changes from RFC 5050............................52 128 Appendix A. For More Information.................................53 129 Appendix B. CDDL expression......................................54 131 1. Introduction 133 Since the publication of the Bundle Protocol Specification 134 (Experimental RFC 5050) in 2007, the Delay-Tolerant Networking (DTN) 135 Bundle Protocol has been implemented in multiple programming 136 languages and deployed to a wide variety of computing platforms. 137 This implementation and deployment experience has identified 138 opportunities for making the protocol simpler, more capable, and 139 easier to use. The present document, standardizing the Bundle 140 Protocol (BP), is adapted from RFC 5050 in that context. 142 The Internet Research Task Force is advised that this document is an 143 update of the protocol described in RFC 5050, reflecting lessons 144 learned. The Internet Research Task Force is requested to mark RFC 145 5050 as obsolete. 147 Significant changes from the Bundle Protocol specification defined 148 in RFC 5050 are listed in section 13. 150 This document describes version 7 of BP. 152 Delay Tolerant Networking is a network architecture providing 153 communications in and/or through highly stressed environments. 154 Stressed networking environments include those with intermittent 155 connectivity, large and/or variable delays, and high bit error 156 rates. To provide its services, BP may be viewed as sitting at the 157 application layer of some number of constituent networks, forming a 158 store-carry-forward overlay network. Key capabilities of BP 159 include: 161 . Ability to use physical motility for the movement of data 162 . Ability to move the responsibility for error control from one 163 node to another 164 . Ability to cope with intermittent connectivity, including cases 165 where the sender and receiver are not concurrently present in 166 the network 167 . Ability to take advantage of scheduled, predicted, and 168 opportunistic connectivity, whether bidirectional or 169 unidirectional, in addition to continuous connectivity 170 . Late binding of overlay network endpoint identifiers to 171 underlying constituent network addresses 173 For descriptions of these capabilities and the rationale for the DTN 174 architecture, see [ARCH] and [SIGC]. 176 BP's location within the standard protocol stack is as shown in 177 Figure 1. BP uses underlying "native" transport and/or network 178 protocols for communications within a given constituent network. 180 The interface between the bundle protocol and a specific underlying 181 protocol is termed a "convergence layer adapter". 183 Figure 1 shows three distinct transport and network protocols 184 (denoted T1/N1, T2/N2, and T3/N3). 186 +-----------+ +-----------+ 187 | BP app | | BP app | 188 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 189 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 190 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 191 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 192 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 193 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 194 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 195 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 196 +-----------+ +-------------+ +-------------+ +-----------+ 197 | | | | 198 |<---- A network ---->| |<---- A network ---->| 199 | | | | 201 Figure 1: The Bundle Protocol in the Protocol Stack Model 203 This document describes the format of the protocol data units 204 (called "bundles") passed between entities participating in BP 205 communications. 207 The entities are referred to as "bundle nodes". This document does 208 not address: 210 . Operations in the convergence layer adapters that bundle nodes 211 use to transport data through specific types of internets. 212 (However, the document does discuss the services that must be 213 provided by each adapter at the convergence layer.) 214 . The bundle route computation algorithm. 215 . Mechanisms for populating the routing or forwarding information 216 bases of bundle nodes. 217 . The mechanisms for securing bundles en route. 218 . The mechanisms for managing bundle nodes. 220 Note that implementations of the specification presented in this 221 document will not be interoperable with implementations of RFC 5050. 223 2. Conventions used in this document 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 227 "OPTIONAL" in this document are to be interpreted as described in 228 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 229 capitals, as shown here. 231 3. Service Description 233 3.1. Definitions 235 Bundle - A bundle is a protocol data unit of BP, so named because 236 negotiation of the parameters of a data exchange may be impractical 237 in a delay-tolerant network: it is often better practice to "bundle" 238 with a unit of application data all metadata that might be needed in 239 order to make the data immediately usable when delivered to the 240 application. Each bundle comprises a sequence of two or more 241 "blocks" of protocol data, which serve various purposes. 243 Block - A bundle protocol block is one of the protocol data 244 structures that together constitute a well-formed bundle. 246 Application Data Unit (ADU) - An application data unit is the unit 247 of data whose conveyance to the bundle's destination is the purpose 248 for the transmission of some bundle that is not a fragment (as 249 defined below). 251 Bundle payload - A bundle payload (or simply "payload") is the 252 content of the bundle's payload block. The terms "bundle content", 253 "bundle payload", and "payload" are used interchangeably in this 254 document. For a bundle that is not a fragment (as defined below), 255 the payload is an application data unit. 257 Partial payload - A partial payload is a payload that comprises 258 either the first N bytes or the last N bytes of some other payload 259 of length M, such that 0 < N < M. Note that every partial payload 260 is a payload and therefore can be further subdivided into partial 261 payloads. 263 Fragment - A fragment is a bundle whose payload block contains a 264 partial payload. 266 Bundle node - A bundle node (or, in the context of this document, 267 simply a "node") is any entity that can send and/or receive bundles. 268 Each bundle node has three conceptual components, defined below, as 269 shown in Figure 2: a "bundle protocol agent", a set of zero or more 270 "convergence layer adapters", and an "application agent". 272 +-----------------------------------------------------------+ 273 |Node | 274 | | 275 | +-------------------------------------------------------+ | 276 | |Application Agent | | 277 | | | | 278 | | +--------------------------+ +----------------------+ | | 279 | | |Administrative element | |Application-specific | | | 280 | | | | |element | | | 281 | | | | | | | | 282 | | +--------------------------+ +----------------------+ | | 283 | | ^ ^ | | 284 | | Admin|records Application|data | | 285 | | | | | | 286 | +----------------v--------------------------v-----------+ | 287 | ^ | 288 | | ADUs | 289 | | | 290 | +-----------------------------v-------------------------+ | 291 | |Bundle Protocol Agent | | 292 | | | | 293 | | | | 294 | +-------------------------------------------------------+ | 295 | ^ ^ ^ | 296 | | Bundles | Bundles Bundles | | 297 | | | | | 298 | +------v-----+ +-----v------+ +-----v-----+ | 299 | |CLA 1 | |CLA 2 | |CLA n | | 300 | | | | | . . . | | | 301 | | | | | | | | 302 +-+------------+-----+------------+-----------+-----------+-+ 303 ^ ^ ^ 304 CL1|PDUs CL2|PDUs CLn|PDUs 305 | | | 306 +------v-----+ +-----v------+ +-----v-----+ 307 Network 1 Network 2 Network n 309 Figure 2: Components of a Bundle Node 311 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 312 the node component that offers the BP services and executes the 313 procedures of the bundle protocol. 315 Convergence layer adapter - A convergence layer adapter (CLA) is a 316 node component that sends and receives bundles on behalf of the BPA, 317 utilizing the services of some 'native' protocol stack that is 318 supported in one of the networks within which the node is 319 functionally located. 321 Application agent - The application agent (AA) of a node is the node 322 component that utilizes the BP services to effect communication for 323 some user purpose. The application agent in turn has two elements, 324 an administrative element and an application-specific element. 326 Application-specific element - The application-specific element of 327 an AA is the node component that constructs, requests transmission 328 of, accepts delivery of, and processes units of user application 329 data. 331 Administrative element - The administrative element of an AA is the 332 node component that constructs and requests transmission of 333 administrative records (defined below), including status reports, 334 and accepts delivery of and processes any administrative records 335 that the node receives. 337 Administrative record - A BP administrative record is an application 338 data unit that is exchanged between the administrative elements of 339 nodes' application agents for some BP administrative purpose. The 340 only administrative record defined in this specification is the 341 status report, discussed later. 343 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 344 of zero or more bundle nodes that all identify themselves for BP 345 purposes by some common identifier, called a "bundle endpoint ID" 346 (or, in this document, simply "endpoint ID"; endpoint IDs are 347 described in detail in Section 4.4.1 below). 349 Singleton endpoint - A singleton endpoint is an endpoint that always 350 contains exactly one member. 352 Registration - A registration is the state machine characterizing a 353 given node's membership in a given endpoint. Any single 354 registration has an associated delivery failure action as defined 355 below and must at any time be in one of two states: Active or 356 Passive. 358 Delivery - A bundle is considered to have been delivered at a node 359 subject to a registration as soon as the application data unit that 360 is the payload of the bundle, together with any relevant metadata 361 (an implementation matter), has been presented to the node's 362 application agent in a manner consistent with the state of that 363 registration. 365 Deliverability - A bundle is considered "deliverable" subject to a 366 registration if and only if (a) the bundle's destination endpoint is 367 the endpoint with which the registration is associated, (b) the 368 bundle has not yet been delivered subject to this registration, and 369 (c) the bundle has not yet been "abandoned" (as defined below) 370 subject to this registration. 372 Abandonment - To abandon a bundle subject to some registration is to 373 assert that the bundle is not deliverable subject to that 374 registration. 376 Delivery failure action - The delivery failure action of a 377 registration is the action that is to be taken when a bundle that is 378 "deliverable" subject to that registration is received at a time 379 when the registration is in the Passive state. 381 Destination - The destination of a bundle is the endpoint comprising 382 the node(s) at which the bundle is to be delivered (as defined 383 above). 385 Transmission - A transmission is an attempt by a node's BPA to cause 386 copies of a bundle to be delivered to one or more of the nodes that 387 are members of some endpoint (the bundle's destination) in response 388 to a transmission request issued by the node's application agent. 390 Forwarding - To forward a bundle to a node is to invoke the services 391 of one or more CLAs in a sustained effort to cause a copy of the 392 bundle to be received by that node. 394 Discarding - To discard a bundle is to cease all operations on the 395 bundle and functionally erase all references to it. The specific 396 procedures by which this is accomplished are an implementation 397 matter. 399 Retention constraint - A retention constraint is an element of the 400 state of a bundle that prevents the bundle from being discarded. 401 That is, a bundle cannot be discarded while it has any retention 402 constraints. 404 Deletion - To delete a bundle is to remove unconditionally all of 405 the bundle's retention constraints, enabling the bundle to be 406 discarded. 408 3.2. Discussion of BP concepts 410 Multiple instances of the same bundle (the same unit of DTN protocol 411 data) might exist concurrently in different parts of a network -- 412 possibly differing in some blocks -- in the memory local to one or 413 more bundle nodes and/or in transit between nodes. In the context of 414 the operation of a bundle node, a bundle is an instance (copy), in 415 that node's local memory, of some bundle that is in the network. 417 The payload for a bundle forwarded in response to a bundle 418 transmission request is the application data unit whose location is 419 provided as a parameter to that request. The payload for a bundle 420 forwarded in response to reception of a bundle is the payload of the 421 received bundle. 423 In the most familiar case, a bundle node is instantiated as a single 424 process running on a general-purpose computer, but in general the 425 definition is meant to be broader: a bundle node might alternatively 426 be a thread, an object in an object-oriented operating system, a 427 special-purpose hardware device, etc. 429 The manner in which the functions of the BPA are performed is wholly 430 an implementation matter. For example, BPA functionality might be 431 coded into each node individually; it might be implemented as a 432 shared library that is used in common by any number of bundle nodes 433 on a single computer; it might be implemented as a daemon whose 434 services are invoked via inter-process or network communication by 435 any number of bundle nodes on one or more computers; it might be 436 implemented in hardware. 438 Every CLA implements its own thin layer of protocol, interposed 439 between BP and the (usually "top") protocol(s) of the underlying 440 native protocol stack; this "CL protocol" may only serve to 441 multiplex and de-multiplex bundles to and from the underlying native 442 protocol, or it may offer additional CL-specific functionality. The 443 manner in which a CLA sends and receives bundles, as well as the 444 definitions of CLAs and CL protocols, are beyond the scope of this 445 specification. 447 Note that the administrative element of a node's application agent 448 may itself, in some cases, function as a convergence-layer adapter. 449 That is, outgoing bundles may be "tunneled" through encapsulating 450 bundles: 452 . An outgoing bundle constitutes a byte array. This byte array 453 may, like any other, be presented to the bundle protocol agent 454 as an application data unit that is to be transmitted to some 455 endpoint. 456 . The original bundle thus forms the payload of an encapsulating 457 bundle that is forwarded using some other convergence-layer 458 protocol(s). 460 . When the encapsulating bundle is received, its payload is 461 delivered to the peer application agent administrative element, 462 which then instructs the bundle protocol agent to dispatch that 463 original bundle in the usual way. 465 The purposes for which this technique may be useful (such as cross- 466 domain security) are beyond the scope of this specification. 468 The only interface between the BPA and the application-specific 469 element of the AA is the BP service interface. But between the BPA 470 and the administrative element of the AA there is a (conceptual) 471 private control interface in addition to the BP service interface. 472 This private control interface enables the BPA and the 473 administrative element of the AA to direct each other to take action 474 under specific circumstances. 476 In the case of a node that serves simply as a BP "router", the AA 477 may have no application-specific element at all. The application- 478 specific elements of other nodes' AAs may perform arbitrarily 479 complex application functions, perhaps even offering multiplexed DTN 480 communication services to a number of other applications. As with 481 the BPA, the manner in which the AA performs its functions is wholly 482 an implementation matter. 484 Singletons are the most familiar sort of endpoint, but in general 485 the endpoint notion is meant to be broader. For example, the nodes 486 in a sensor network might constitute a set of bundle nodes that 487 identify themselves by a single common endpoint ID and thus form a 488 single bundle endpoint. *Note* too that a given bundle node might 489 identify itself by multiple endpoint IDs and thus be a member of 490 multiple bundle endpoints. 492 The destination of every bundle is an endpoint, which may or may not 493 be singleton. The source of every bundle is a node, identified by 494 the endpoint ID for some singleton endpoint that contains that node. 495 Note, though, that the source node ID asserted in a given bundle may 496 be the null endpoint ID (as described later) rather than the 497 endpoint ID of the actual source node; bundles for which the 498 asserted source node ID is the null endpoint ID are termed 499 "anonymous" bundles. 501 Any number of transmissions may be concurrently undertaken by the 502 bundle protocol agent of a given node. 504 When the bundle protocol agent of a node determines that a bundle 505 must be forwarded to a node (either to a node that is a member of 506 the bundle's destination endpoint or to some intermediate forwarding 507 node) in the course of completing the successful transmission of 508 that bundle, the bundle protocol agent invokes the services of one 509 or more CLAs in a sustained effort to cause a copy of the bundle to 510 be received by that node. 512 Upon reception, the processing of a bundle that has been received by 513 a given node depends on whether or not the receiving node is 514 registered in the bundle's destination endpoint. If it is, and if 515 the payload of the bundle is non-fragmentary (possibly as a result 516 of successful payload reassembly from fragmentary payloads, 517 including the original payload of the newly received bundle), then 518 the bundle is normally delivered to the node's application agent 519 subject to the registration characterizing the node's membership in 520 the destination endpoint. 522 The bundle protocol does not natively ensure delivery of a bundle to 523 its destination. Data loss along the path to the destination node 524 can be minimized by utilizing reliable convergence-layer protocols 525 between neighbors on all segments of the end-to-end path, but for 526 end-to-end bundle delivery assurance it will be necessary to develop 527 extensions to the bundle protocol and/or application-layer 528 mechanisms. 530 The bundle protocol is designed for extensibility. Bundle protocol 531 extensions, documented elsewhere, may extend this specification by: 533 . defining additional blocks; 534 . defining additional administrative records; 535 . defining additional bundle processing flags; 536 . defining additional block processing flags; 537 . defining additional types of bundle status reports; 538 . defining additional bundle status report reason codes; 539 . defining additional mandates and constraints on processing 540 that conformant bundle protocol agents must perform at 541 specified points in the inbound and outbound bundle processing 542 cycles. 544 3.3. Services Offered by Bundle Protocol Agents 546 The BPA of each node is expected to provide the following services 547 to the node's application agent: 549 . commencing a registration (registering the node in an 550 endpoint); 551 . terminating a registration; 552 . switching a registration between Active and Passive states; 553 . transmitting a bundle to an identified bundle endpoint; 554 . canceling a transmission; 555 . polling a registration that is in the Passive state; 556 . delivering a received bundle. 558 4. Bundle Format 560 The format of bundles SHALL conform to the Concise Binary Object 561 Representation (CBOR [RFC7049]). 563 Each bundle SHALL be a concatenated sequence of at least two blocks, 564 represented as a CBOR indefinite-length array. The first block in 565 the sequence (the first item of the array) MUST be a primary bundle 566 block in CBOR representation as described below; the bundle MUST 567 have exactly one primary bundle block. The primary block MUST be 568 followed by one or more canonical bundle blocks (additional array 569 items) in CBOR representation as described in 4.2.3 below. The last 570 such block MUST be a payload block; the bundle MUST have exactly one 571 payload block. The last item of the array, immediately following 572 the payload block, SHALL be a CBOR "break" stop code. 574 (Note that, while CBOR permits considerable flexibility in the 575 encoding of bundles, this flexibility must not be interpreted as 576 inviting increased complexity in protocol data unit structure.) 578 An implementation of the Bundle Protocol MAY discard any sequence of 579 bytes that does not conform to the Bundle Protocol specification. 581 An implementation of the Bundle Protocol MAY accept a sequence of 582 bytes that does not conform to the Bundle Protocol specification 583 (e.g., one that represents data elements in fixed-length arrays 584 rather than indefinite-length arrays) and transform it into 585 conformant BP structure before processing it. Procedures for 586 accomplishing such a transformation are beyond the scope of this 587 specification. 589 4.1. BP Fundamental Data Structures 591 4.1.1. CRC Type 593 CRC type is an unsigned integer type code for which the following 594 values (and no others) are valid: 596 . 0 indicates "no CRC is present." 597 . 1 indicates "a standard X-25 CRC-16 is present." [CRC16] 598 . 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present." 599 [RFC4960] 601 CRC type SHALL be represented as a CBOR unsigned integer. 603 For examples of CRC32C CRCs, see Appendix A.4 of [RFC7143]. 605 Note that more robust protection of BP data integrity, as needed, 606 may be provided by means of Block Integrity Blocks as defined in the 607 Bundle Security Protocol [BPSEC]). 609 4.1.2. CRC 611 CRC SHALL be omitted from a block if and only if the block's CRC 612 type code is zero. 614 When not omitted, the CRC SHALL be represented as a CBOR byte string 615 of two bytes (that is, CBOR additional information 2, if CRC type is 616 1) or of four bytes (that is, CBOR additional information 4, if CRC 617 type is 2); in each case the sequence of bytes SHALL constitute an 618 unsigned integer value (of 16 or 32 bits, respectively) in network 619 byte order. 621 4.1.3. Bundle Processing Control Flags 623 Bundle processing control flags assert properties of the bundle as a 624 whole rather than of any particular block of the bundle. They are 625 conveyed in the primary block of the bundle. 627 The following properties are asserted by the bundle processing 628 control flags: 630 . The bundle is a fragment. (Boolean) 632 . The bundle's payload is an administrative record. (Boolean) 634 . The bundle must not be fragmented. (Boolean) 636 . Acknowledgment by the user application is requested. (Boolean) 638 . Status time is requested in all status reports. (Boolean) 640 . Flags requesting types of status reports (all Boolean): 642 o Request reporting of bundle reception. 644 o Request reporting of bundle forwarding. 646 o Request reporting of bundle delivery. 648 o Request reporting of bundle deletion. 650 If the bundle processing control flags indicate that the bundle's 651 application data unit is an administrative record, then all status 652 report request flag values must be zero. 654 If the bundle's source node is omitted (i.e., the source node ID is 655 the ID of the null endpoint, which has no members as discussed 656 below; this option enables anonymous bundle transmission), then the 657 bundle is not uniquely identifiable and all bundle protocol features 658 that rely on bundle identity must therefore be disabled: the "Bundle 659 must not be fragmented" flag value must be 1 and all status report 660 request flag values must be zero. 662 The bundle processing control flags SHALL be represented as a CBOR 663 unsigned integer item, the value of which SHALL be processed as a 664 bit field indicating the control flag values as follows (note that 665 bit numbering in this instance is reversed from the usual practice, 666 beginning with the low-order bit instead of the high-order bit, in 667 recognition of the potential definition of additional control flag 668 values in the future): 670 . Bit 0 (the low-order bit, 0x000001): bundle is a fragment. 671 . Bit 1 (0x000002): payload is an administrative record. 672 . Bit 2 (0x000004): bundle must not be fragmented. 673 . Bit 3 (0x000008): reserved. 674 . Bit 4 (0x000010): reserved. 675 . Bit 5 (0x000020): user application acknowledgement is 676 requested. 677 . Bit 6 (0x000040): status time is requested in all status 678 reports. 679 . Bit 7 (0x000080): reserved. 680 . Bit 8 (0x000100): reserved. 681 . Bit 9 (0x000200): reserved. 682 . Bit 10(0x000400): reserved. 683 . Bit 11(0x000800): reserved. 684 . Bit 12(0x001000): reserved. 685 . Bit 13(0x002000): reserved. 686 . Bit 14(0x004000): bundle reception status reports are 687 requested. 688 . Bit 15(0x008000): reserved. 689 . Bit 16(0x010000): bundle forwarding status reports are 690 requested. 691 . Bit 17(0x020000): bundle delivery status reports are requested. 692 . Bit 18(0x040000): bundle deletion status reports are requested. 693 . Bits 19-20 are reserved. 694 . Bits 21-63 are unassigned. 696 4.1.4. Block Processing Control Flags 698 The block processing control flags assert properties of canonical 699 bundle blocks. They are conveyed in the header of the block to 700 which they pertain. 702 The following properties are asserted by the block processing 703 control flags: 705 . This block must be replicated in every fragment. (Boolean) 707 . Transmission of a status report is requested if this block 708 can't be processed. (Boolean) 710 . Block must be removed from the bundle if it can't be processed. 711 (Boolean) 713 . Bundle must be deleted if this block can't be processed. 714 (Boolean) 716 For each bundle whose bundle processing control flags indicate that 717 the bundle's application data unit is an administrative record, or 718 whose source node ID is the null endpoint ID as defined below, the 719 value of the "Transmit status report if block can't be processed" 720 flag in every canonical block of the bundle must be zero. 722 The block processing control flags SHALL be represented as a CBOR 723 unsigned integer item, the value of which SHALL be processed as a 724 bit field indicating the control flag values as follows (note that 725 bit numbering in this instance is reversed from the usual practice, 726 beginning with the low-order bit instead of the high-order bit, for 727 agreement with the bit numbering of the bundle processing control 728 flags): 730 . Bit 0(the low-order bit, 0x01): block must be replicated in 731 every fragment. 732 . Bit 1(0x02): transmission of a status report is requested if 733 block can't be processed. 734 . Bit 2(0x04): bundle must be deleted if block can't be 735 processed. 736 . Bit 3(0x08): reserved. 737 . Bit 4(0x10): block must be removed from bundle if it can't be 738 processed. 739 . Bit 5(0x20): reserved. 740 . Bit 6 (0x40): reserved. 741 . Bits 7-63 are unassigned. 743 4.1.5. Identifiers 745 4.1.5.1. Endpoint ID 747 The destinations of bundles are bundle endpoints, identified by text 748 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 749 (EID) is a Uniform Resource Identifier (URI; [URI]). As such, each 750 endpoint ID can be characterized as having this general structure: 752 < scheme name > : < scheme-specific part, or "SSP" > 754 The scheme identified by the < scheme name > in an endpoint ID is a 755 set of syntactic and semantic rules that fully explain how to parse 756 and interpret the SSP. The set of allowable schemes is effectively 757 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 758 protocol endpoint ID. 760 Note that, although endpoint IDs are URIs, implementations of the BP 761 service interface may support expression of endpoint IDs in some 762 internationalized manner (e.g., Internationalized Resource 763 Identifiers (IRIs); see [RFC3987]). 765 The endpoint ID "dtn:none" identifies the "null endpoint", the 766 endpoint that by definition never has any members. 768 Each BP endpoint ID (EID) SHALL be represented as a CBOR array 769 comprising a 2-tuple. 771 The first item of the array SHALL be the code number identifying the 772 endpoint's URI scheme [URI], as defined in the registry of URI 773 scheme code numbers for Bundle Protocol maintained by IANA as 774 described in Section 10. [URIREG]. Each URI scheme code number 775 SHALL be represented as a CBOR unsigned integer. 777 The second item of the array SHALL be the applicable CBOR 778 representation of the scheme-specific part (SSP) of the EID, defined 779 as follows: 781 . If the EID's URI scheme is "dtn" then the SSP SHALL be 782 represented as a CBOR text string unless the EID's SSP is 783 "none", in which case the SSP SHALL be represented as a CBOR 784 unsigned integer with the value zero. 785 . If the EID's URI scheme is "ipn" then the SSP SHALL be 786 represented as a CBOR array comprising a 2-tuple. The first 787 item of this array SHALL be the EID's node number represented 788 as a CBOR unsigned integer. The second item of this array 789 SHALL be the EID's service number represented as a CBOR 790 unsigned integer. 791 . Definitions of the CBOR representations of the SSPs of EIDs 792 encoded in other URI schemes are included in the specifications 793 defining those schemes. 795 4.1.5.2. Node ID 797 For many purposes of the Bundle Protocol it is important to identify 798 the node that is operative in some context. 800 As discussed in 3.1 above, nodes are distinct from endpoints; 801 specifically, an endpoint is a set of zero or more nodes. But 802 rather than define a separate namespace for node identifiers, we 803 instead use endpoint identifiers to identify nodes, subject to the 804 following restrictions: 806 . Every node MUST be a member of at least one singleton endpoint. 807 . The EID of any singleton endpoint of which a node is a member 808 MAY be used to identify that node. A "node ID" is an EID that 809 is used in this way. 810 . A node's membership in a given singleton endpoint MUST be 811 sustained at least until the nominal operation of the Bundle 812 Protocol no longer depends on the identification of that node 813 using that endpoint's ID. 815 4.1.6. DTN Time 817 A DTN time is an unsigned integer indicating the number of seconds 818 that have elapsed since the start of the year 2000 on the 819 Coordinated Universal Time (UTC) scale [UTC]. Each DTN time SHALL 820 be represented as a CBOR unsigned integer item. 822 Implementers need to be aware that DTN time values conveyed in CBOR 823 representation in bundles can conceivably exceed (2**32 - 1). 825 4.1.7. Creation Timestamp 827 Each creation timestamp SHALL be represented as a CBOR array item 828 comprising a 2-tuple. 830 The first item of the array SHALL be a DTN time. 832 The second item of the array SHALL be the creation timestamp's 833 sequence number, represented as a CBOR unsigned integer. 835 4.1.8. Block-type-specific Data 837 Block-type-specific data in each block (other than the primary 838 block) SHALL be the applicable CBOR representation of the content of 839 the block. Details of this representation are included in the 840 specification defining the block type. 842 4.2. Bundle Representation 844 This section describes the primary block in detail and non-primary 845 blocks in general. Rules for processing these blocks appear in 846 Section 5 of this document. 848 Note that supplementary DTN protocol specifications (including, but 849 not restricted to, the Bundle Security Protocol [BPSEC]) may require 850 that BP implementations conforming to those protocols construct and 851 process additional blocks. 853 4.2.1. Bundle 855 Each bundle SHALL be represented as a CBOR indefinite-length array. 856 The first item of this array SHALL be the CBOR representation of a 857 Primary Block. Every other item of the array except the last SHALL 858 be the CBOR representation of a Canonical Block. The last item of 859 the array SHALL be a CBOR "break" stop code. 861 Associated with each block of a bundle is a block number. The block 862 number uniquely identifies the block within the bundle, enabling 863 blocks (notably bundle security protocol blocks) to reference other 864 blocks in the same bundle without ambiguity. The block number of 865 the primary block is implicitly zero; the block numbers of all other 866 blocks are explicitly stated in block headers as noted below. Block 867 numbering is unrelated to the order in which blocks are sequenced in 868 the bundle. The block number of the payload block is always 1. 870 4.2.2. Primary Bundle Block 872 The primary bundle block contains the basic information needed to 873 forward bundles to their destinations. 875 Each primary block SHALL be represented as a CBOR array; the number 876 of elements in the array SHALL be 8 (if the bundle is not a fragment 877 and the block has no CRC), 9 (if the block has a CRC and the bundle 878 is not a fragment), 10 (if the bundle is a fragment and the block 879 has no CRC), or 11 (if the bundle is a fragment and the block has a 880 CRC). 882 The primary block of each bundle SHALL be immutable. The values of 883 all fields in the primary block must remain unchanged from the time 884 the block is created to the time it is delivered. 886 The fields of the primary bundle block SHALL be as follows, listed 887 in the order in which they MUST appear: 889 Version: An unsigned integer value indicating the version of the 890 bundle protocol that constructed this block. The present document 891 describes version 7 of the bundle protocol. Version number SHALL be 892 represented as a CBOR unsigned integer item. 894 Bundle Processing Control Flags: The Bundle Processing Control Flags 895 are discussed in Section 4.1.3. above. 897 CRC Type: CRC Type codes are discussed in Section 4.1.1. above. The 898 CRC Type code for the primary block MAY be zero if the bundle 899 contains a BPsec [BPSEC] Block Integrity Block whose target is the 900 primary block; otherwise the CRC Type code for the primary block 901 MUST be non-zero. 903 Destination EID: The Destination EID field identifies the bundle 904 endpoint that is the bundle's destination, i.e., the endpoint that 905 contains the node(s) at which the bundle is to be delivered. 907 Source node ID: The Source node ID field identifies the bundle node 908 at which the bundle was initially transmitted, except that Source 909 node ID may be the null endpoint ID in the event that the bundle's 910 source chooses to remain anonymous. 912 Report-to EID: The Report-to EID field identifies the bundle 913 endpoint to which status reports pertaining to the forwarding and 914 delivery of this bundle are to be transmitted. 916 Creation Timestamp: The creation timestamp (discussed in 4.1.7 917 above) comprises two unsigned integers that, together with the 918 source node ID and (if the bundle is a fragment) the fragment offset 919 and payload length, serve to identify the bundle. The first of these 920 integers is the bundle's creation time, while the second is the 921 bundle's creation timestamp sequence number. Bundle creation time 922 SHALL be the DTN time at which the transmission request was received 923 that resulted in the creation of the bundle. Sequence count SHALL be 924 the latest value (as of the time at which that transmission request 925 was received) of a monotonically increasing positive integer counter 926 managed by the source node's bundle protocol agent that MAY be reset 927 to zero whenever the current time advances by one second. For nodes 928 that lack accurate clocks, it is recommended that bundle creation 929 time be set to zero and that the counter used as the source of the 930 bundle sequence count never be reset to zero. Note that, in general, 931 the creation of two distinct bundles with the same source node ID 932 and bundle creation timestamp may result in unexpected network 933 behavior and/or suboptimal performance. The combination of source 934 node ID and bundle creation timestamp serves to identify a single 935 transmission request, enabling it to be acknowledged by the 936 receiving application (provided the source node ID is not the null 937 endpoint ID). 939 Lifetime: The lifetime field is an unsigned integer that indicates 940 the time at which the bundle's payload will no longer be useful, 941 encoded as a number of microseconds past the creation time. (For 942 high-rate deployments with very brief disruptions, fine-grained 943 expression of bundle lifetime may be useful.) When a bundle's age 944 exceeds its lifetime, bundle nodes need no longer retain or forward 945 the bundle; the bundle SHOULD be deleted from the network. For 946 bundles originating at nodes that lack accurate clocks, it is 947 recommended that bundle age be obtained from the Bundle Age 948 extension block (see 4.3.2 below) rather than from the difference 949 between current time and bundle creation time. Bundle lifetime 950 SHALL be represented as a CBOR unsigned integer item. 952 Fragment offset: If and only if the Bundle Processing Control Flags 953 of this Primary block indicate that the bundle is a fragment, 954 fragment offset SHALL be present in the primary block. Fragment 955 offset SHALL be represented as a CBOR unsigned integer indicating 956 the offset from the start of the original application data unit at 957 which the bytes comprising the payload of this bundle were located. 959 Total Application Data Unit Length: If and only if the Bundle 960 Processing Control Flags of this Primary block indicate that the 961 bundle is a fragment, total application data unit length SHALL be 962 present in the primary block. Total application data unit length 963 SHALL be represented as a CBOR unsigned integer indicating the total 964 length of the original application data unit of which this bundle's 965 payload is a part. 967 CRC: A CRC SHALL be present in the primary block unless the bundle 968 includes a BPsec [BPSEC] Block Integrity Block whose target is the 969 primary block, in which case a CRC MAY be present in the primary 970 block. The length and nature of the CRC SHALL be as indicated by 971 the CRC type. The CRC SHALL be computed over the concatenation of 972 all bytes (including CBOR "break" characters) of the primary block 973 including the CRC field itself, which for this purpose SHALL be 974 temporarily populated with the value zero. 976 4.2.3. Canonical Bundle Block Format 978 Every block other than the primary block (all such blocks are termed 979 "canonical" blocks) SHALL be represented as a CBOR array; the number 980 of elements in the array SHALL be 5 (if CRC type is zero) or 6 981 (otherwise). 983 The fields of every canonical block SHALL be as follows, listed in 984 the order in which they MUST appear: 986 . Block type code, an unsigned integer. Bundle block type code 1 987 indicates that the block is a bundle payload block. Block type 988 codes 2 through 9 are explicitly reserved as noted later in 989 this specification. Block type codes 192 through 255 are not 990 reserved and are available for private and/or experimental use. 991 All other block type code values are reserved for future use. 992 . Block number, an unsigned integer as discussed in 4.2.1 above. 993 Block number SHALL be represented as a CBOR unsigned integer. 994 . Block processing control flags as discussed in Section 4.1.4 995 above. 996 . CRC type as discussed in Section 4.1.1 above. 997 . Block-type-specific data represented as a single definite- 998 length CBOR byte string, i.e., a CBOR byte string that is not 999 of indefinite length. For each type of block, the block-type- 1000 specific data byte string is the serialization, in a block- 1001 type-specific manner, of the data conveyed by that type of 1002 block; definitions of blocks are required to define the manner 1003 in which block-type-specific data are serialized within the 1004 block-type-specific data field. For the Payload Block in 1005 particular (block type 1), the block-type-specific data field, 1006 termed the "payload", SHALL be an application data unit, or 1007 some contiguous extent thereof, represented as a definite- 1008 length CBOR byte string. 1009 . If and only if the value of the CRC type field of this block is 1010 non-zero, a CRC. If present, the length and nature of the CRC 1011 SHALL be as indicated by the CRC type and the CRC SHALL be 1012 computed over the concatenation of all bytes of the block 1013 (including CBOR "break" characters) including the CRC field 1014 itself, which for this purpose SHALL be temporarily populated 1015 with the value zero. 1017 4.3. Extension Blocks 1019 "Extension blocks" are all blocks other than the primary and payload 1020 blocks. Because not all extension blocks are defined in the Bundle 1021 Protocol specification (the present document), not all nodes 1022 conforming to this specification will necessarily instantiate Bundle 1023 Protocol implementations that include procedures for processing 1024 (that is, recognizing, parsing, acting on, and/or producing) all 1025 extension blocks. It is therefore possible for a node to receive a 1026 bundle that includes extension blocks that the node cannot process. 1027 The values of the block processing control flags indicate the action 1028 to be taken by the bundle protocol agent when this is the case. 1030 The following extension blocks are defined in the current document. 1032 4.3.1. Previous Node 1034 The Previous Node block, block type 6, identifies the node that 1035 forwarded this bundle to the local node (i.e., to the node at which 1036 the bundle currently resides); its block-type-specific data is the 1037 node ID of that forwarder node which SHALL take the form of a node 1038 ID represented as described in Section 4.1.5.2. above. If the local 1039 node is the source of the bundle, then the bundle MUST NOT contain 1040 any previous node block. Otherwise the bundle SHOULD contain one 1041 (1) occurrence of this type of block. 1043 4.3.2. Bundle Age 1045 The Bundle Age block, block type 7, contains the number of 1046 microseconds that have elapsed between the time the bundle was 1047 created and time at which it was most recently forwarded. It is 1048 intended for use by nodes lacking access to an accurate clock, to 1049 aid in determining the time at which a bundle's lifetime expires. 1050 The block-type-specific data of this block is an unsigned integer 1051 containing the age of the bundle in microseconds, which SHALL be 1052 represented as a CBOR unsigned integer item. (The age of the bundle 1053 is the sum of all known intervals of the bundle's residence at 1054 forwarding nodes, up to the time at which the bundle was most 1055 recently forwarded, plus the summation of signal propagation time 1056 over all episodes of transmission between forwarding nodes. 1057 Determination of these values is an implementation matter.) If the 1058 bundle's creation time is zero, then the bundle MUST contain exactly 1059 one (1) occurrence of this type of block; otherwise, the bundle MAY 1060 contain at most one (1) occurrence of this type of block. A bundle 1061 MUST NOT contain multiple occurrences of the bundle age block, as 1062 this could result in processing anomalies. 1064 4.3.3. Hop Count 1066 The Hop Count block, block type 10, contains two unsigned integers, 1067 hop limit and hop count. A "hop" is here defined as an occasion on 1068 which a bundle was forwarded from one node to another node. Hop 1069 limit MUST be in the range 1 through 255. The hop limit value SHOULD 1070 NOT be changed at any time after creation of the Hop Count block; 1071 the hop count value SHOULD initially be zero and SHOULD be increased 1072 by 1 on each hop. 1074 The hop count block is mainly intended as a safety mechanism, a 1075 means of identifying bundles for removal from the network that can 1076 never be delivered due to a persistent forwarding error. When a 1077 bundle's hop count exceeds its hop limit, the bundle SHOULD be 1078 deleted for the reason "hop limit exceeded", following the bundle 1079 deletion procedure defined in Section 5.10. . Procedures for 1080 determining the appropriate hop limit for a block are beyond the 1081 scope of this specification. The block-type-specific data in a hop 1082 count block SHALL be represented as a CBOR array comprising a 2- 1083 tuple. The first item of this array SHALL be the bundle's hop 1084 limit, represented as a CBOR unsigned integer. The second item of 1085 this array SHALL be the bundle's hop count, represented as a CBOR 1086 unsigned integer. A bundle MAY contain at most one (1) occurrence of 1087 this type of block. 1089 5. Bundle Processing 1091 The bundle processing procedures mandated in this section and in 1092 Section 6 govern the operation of the Bundle Protocol Agent and the 1093 Application Agent administrative element of each bundle node. They 1094 are neither exhaustive nor exclusive. Supplementary DTN protocol 1095 specifications (including, but not restricted to, the Bundle 1096 Security Protocol [BPSEC]) may augment, override, or supersede the 1097 mandates of this document. 1099 5.1. Generation of Administrative Records 1101 All transmission of bundles is in response to bundle transmission 1102 requests presented by nodes' application agents. When required to 1103 "generate" an administrative record (such as a bundle status 1104 report), the bundle protocol agent itself is responsible for causing 1105 a new bundle to be transmitted, conveying that record. In concept, 1106 the bundle protocol agent discharges this responsibility by 1107 directing the administrative element of the node's application agent 1108 to construct the record and request its transmission as detailed in 1109 Section 6 below. In practice, the manner in which administrative 1110 record generation is accomplished is an implementation matter, 1111 provided the constraints noted in Section 6 are observed. 1113 Note that requesting status reports for any single bundle might 1114 easily result in the generation of (1 + (2 *(N-1))) status report 1115 bundles, where N is the number of nodes on the path from the 1116 bundle's source to its destination, inclusive. That is, the 1117 requesting of status reports for large numbers of bundles could 1118 result in an unacceptable increase in the bundle traffic in the 1119 network. For this reason, the generation of status reports MUST be 1120 disabled by default and enabled only when the risk of excessive 1121 network traffic is deemed acceptable. 1123 When the generation of status reports is enabled, the decision on 1124 whether or not to generate a requested status report is left to the 1125 discretion of the bundle protocol agent. Mechanisms that could 1126 assist in making such decisions, such as pre-placed agreements 1127 authorizing the generation of status reports under specified 1128 circumstances, are beyond the scope of this specification. 1130 Notes on administrative record terminology: 1132 . A "bundle reception status report" is a bundle status report 1133 with the "reporting node received bundle" flag set to 1. 1134 . A "bundle forwarding status report" is a bundle status report 1135 with the "reporting node forwarded the bundle" flag set to 1. 1136 . A "bundle delivery status report" is a bundle status report 1137 with the "reporting node delivered the bundle" flag set to 1. 1138 . A "bundle deletion status report" is a bundle status report 1139 with the "reporting node deleted the bundle" flag set to 1. 1141 5.2. Bundle Transmission 1143 The steps in processing a bundle transmission request are: 1145 Step 1: Transmission of the bundle is initiated. An outbound bundle 1146 MUST be created per the parameters of the bundle transmission 1147 request, with the retention constraint "Dispatch pending". The 1148 source node ID of the bundle MUST be either the null endpoint ID, 1149 indicating that the source of the bundle is anonymous, or else the 1150 EID of a singleton endpoint whose only member is the node of which 1151 the BPA is a component. 1153 Step 2: Processing proceeds from Step 1 of Section 5.4. 1155 5.3. Bundle Dispatching 1157 The steps in dispatching a bundle are: 1159 Step 1: If the bundle's destination endpoint is an endpoint of which 1160 the node is a member, the bundle delivery procedure defined in 1161 Section 5.7 MUST be followed and for the purposes of all subsequent 1162 processing of this bundle at this node the node's membership in the 1163 bundle's destination endpoint SHALL be disavowed; specifically, even 1164 though the node is a member of the bundle's destination endpoint, 1165 the node SHALL NOT undertake to forward the bundle to itself in the 1166 course of performing the procedure described in Section 5.4. 1168 Step 2: Processing proceeds from Step 1 of Section 5.4. 1170 5.4. Bundle Forwarding 1172 The steps in forwarding a bundle are: 1174 Step 1: The retention constraint "Forward pending" MUST be added to 1175 the bundle, and the bundle's "Dispatch pending" retention constraint 1176 MUST be removed. 1178 Step 2: The bundle protocol agent MUST determine whether or not 1179 forwarding is contraindicated (that is, rendered inadvisable) for 1180 any of the reasons listed in Figure 4. In particular: 1182 . The bundle protocol agent MAY choose either to forward the 1183 bundle directly to its destination node(s) (if possible) or to 1184 forward the bundle to some other node(s) for further 1185 forwarding. The manner in which this decision is made may 1186 depend on the scheme name in the destination endpoint ID and/or 1187 on other state but in any case is beyond the scope of this 1188 document. If the BPA elects to forward the bundle to some other 1189 node(s) for further forwarding but finds it impossible to 1190 select any node(s) to forward the bundle to, then forwarding is 1191 contraindicated. 1192 . Provided the bundle protocol agent succeeded in selecting the 1193 node(s) to forward the bundle to, the bundle protocol agent 1194 MUST subsequently select the convergence layer adapter(s) whose 1195 services will enable the node to send the bundle to those 1196 nodes. The manner in which specific appropriate convergence 1197 layer adapters are selected is beyond the scope of this 1198 document. If the agent finds it impossible to select any 1199 appropriate convergence layer adapter(s) to use in forwarding 1200 this bundle, then forwarding is contraindicated. 1202 Step 3: If forwarding of the bundle is determined to be 1203 contraindicated for any of the reasons listed in Figure 4, then the 1204 Forwarding Contraindicated procedure defined in Section 5.4.1 MUST 1205 be followed; the remaining steps of Section 5.4 are skipped at this 1206 time. 1208 Step 4: For each node selected for forwarding, the bundle protocol 1209 agent MUST invoke the services of the selected convergence layer 1210 adapter(s) in order to effect the sending of the bundle to that 1211 node. Determining the time at which the bundle protocol agent 1212 invokes convergence layer adapter services is a BPA implementation 1213 matter. Determining the time at which each convergence layer 1214 adapter subsequently responds to this service invocation by sending 1215 the bundle is a convergence-layer adapter implementation matter. 1216 Note that: 1218 . If the bundle contains a data label extension block (to be 1219 defined in a future document) then that data label value MAY 1220 identify procedures for determining the order in which 1221 convergence layer adapters must send bundles, e.g., considering 1222 bundle source when determining the order in which bundles are 1223 sent. The definition of such procedures is beyond the scope of 1224 this specification. 1225 . If the bundle has a bundle age block, as defined in 4.3.2. 1226 above, then at the last possible moment before the CLA 1227 initiates conveyance of the bundle via the CL protocol the 1228 bundle age value MUST be increased by the difference between 1229 the current time and the time at which the bundle was received 1230 (or, if the local node is the source of the bundle, created). 1232 Step 5: When all selected convergence layer adapters have informed 1233 the bundle protocol agent that they have concluded their data 1234 sending procedures with regard to this bundle, processing may depend 1235 on the results of those procedures. If completion of the data 1236 sending procedures by all selected convergence layer adapters has 1237 not resulted in successful forwarding of the bundle (an 1238 implementation-specific determination that is beyond the scope of 1239 this specification), then the bundle protocol agent MAY choose (in 1240 an implementation-specific manner, again beyond the scope of this 1241 specification) to initiate another attempt to forward the bundle. 1242 In that event, processing proceeds from Step 4 of Section 5.4. 1244 If completion of the data sending procedures by all selected 1245 convergence layer adapters HAS resulted in successful forwarding of 1246 the bundle, or if it has not but the bundle protocol agent does not 1247 choose to initiate another attempt to forward the bundle, then: 1249 . If the "request reporting of bundle forwarding" flag in the 1250 bundle's status report request field is set to 1, and status 1251 reporting is enabled, then a bundle forwarding status report 1252 SHOULD be generated, destined for the bundle's report-to 1253 endpoint ID. The reason code on this bundle forwarding status 1254 report MUST be "no additional information". 1255 . If any applicable bundle protocol extensions mandate generation 1256 of status reports upon conclusion of convergence-layer data 1257 sending procedures, all such status reports SHOULD be generated 1258 with extension-mandated reason codes. 1259 . The bundle's "Forward pending" retention constraint MUST be 1260 removed. 1262 5.4.1. Forwarding Contraindicated 1264 The steps in responding to contraindication of forwarding are: 1266 Step 1: The bundle protocol agent MUST determine whether or not to 1267 declare failure in forwarding the bundle. Note: this decision is 1268 likely to be influenced by the reason for which forwarding is 1269 contraindicated. 1271 Step 2: If forwarding failure is declared, then the Forwarding 1272 Failed procedure defined in Section 5.4.2 MUST be followed. 1274 Otherwise, when -- at some future time - the forwarding of this 1275 bundle ceases to be contraindicated, processing proceeds from Step 4 1276 of Section 5.4. 1278 5.4.2. Forwarding Failed 1280 The steps in responding to a declaration of forwarding failure are: 1282 Step 1: The bundle protocol agent MAY forward the bundle back to the 1283 node that sent it, as identified by the Previous Node block, if 1284 present. This forwarding, if performed, SHALL be accomplished by 1285 performing Step 4 and Step 5 of section 5.4 where the sole node 1286 selected for forwarding SHALL be the node that sent the bundle. 1288 Step 2: If the bundle's destination endpoint is an endpoint of which 1289 the node is a member, then the bundle's "Forward pending" retention 1290 constraint MUST be removed. Otherwise, the bundle MUST be deleted: 1291 the bundle deletion procedure defined in Section 5.10 MUST be 1292 followed, citing the reason for which forwarding was determined to 1293 be contraindicated. 1295 5.5. Bundle Expiration 1297 A bundle expires when the bundle's age exceeds its lifetime as 1298 specified in the primary bundle block. Bundle age MAY be determined 1299 by subtracting the bundle's creation timestamp time from the current 1300 time if (a) that timestamp time is not zero and (b) the local node's 1301 clock is known to be accurate; otherwise bundle age MUST be obtained 1302 from the Bundle Age extension block. Bundle expiration MAY occur at 1303 any point in the processing of a bundle. When a bundle expires, the 1304 bundle protocol agent MUST delete the bundle for the reason 1305 "lifetime expired": the bundle deletion procedure defined in Section 1306 5.10 MUST be followed. 1308 5.6. Bundle Reception 1310 The steps in processing a bundle that has been received from another 1311 node are: 1313 Step 1: The retention constraint "Dispatch pending" MUST be added to 1314 the bundle. 1316 Step 2: If the "request reporting of bundle reception" flag in the 1317 bundle's status report request field is set to 1, and status 1318 reporting is enabled, then a bundle reception status report with 1319 reason code "No additional information" SHOULD be generated, 1320 destined for the bundle's report-to endpoint ID. 1322 Step 3: CRCs SHOULD be computed for every block of the bundle that 1323 has an attached CRC. If any block of the bundle is malformed 1324 according to this specification, or if any block has an attached CRC 1325 and the CRC computed for this block upon reception differs from that 1326 attached CRC, then the bundle protocol agent MUST delete the bundle 1327 for the reason "Block unintelligible". The bundle deletion 1328 procedure defined in Section 5.10 MUST be followed and all remaining 1329 steps of the bundle reception procedure MUST be skipped. 1331 Step 4: For each block in the bundle that is an extension block that 1332 the bundle protocol agent cannot process: 1334 . If the block processing flags in that block indicate that a 1335 status report is requested in this event, and status reporting 1336 is enabled, then a bundle reception status report with reason 1337 code "Block unintelligible" SHOULD be generated, destined for 1338 the bundle's report-to endpoint ID. 1339 . If the block processing flags in that block indicate that the 1340 bundle must be deleted in this event, then the bundle protocol 1341 agent MUST delete the bundle for the reason "Block 1342 unintelligible"; the bundle deletion procedure defined in 1343 Section 5.10 MUST be followed and all remaining steps of the 1344 bundle reception procedure MUST be skipped. 1345 . If the block processing flags in that block do NOT indicate 1346 that the bundle must be deleted in this event but do indicate 1347 that the block must be discarded, then the bundle protocol 1348 agent MUST remove this block from the bundle. 1349 . If the block processing flags in that block indicate neither 1350 that the bundle must be deleted nor that that the block must be 1351 discarded, then processing continues with the next extension 1352 block that the bundle protocol agent cannot process, if any; 1353 otherwise, processing proceeds from step 5. 1355 Step 5: Processing proceeds from Step 1 of Section 5.3. 1357 5.7. Local Bundle Delivery 1359 The steps in processing a bundle that is destined for an endpoint of 1360 which this node is a member are: 1362 Step 1: If the received bundle is a fragment, the application data 1363 unit reassembly procedure described in Section 5.9 MUST be followed. 1364 If this procedure results in reassembly of the entire original 1365 application data unit, processing of this bundle (whose fragmentary 1366 payload has been replaced by the reassembled application data unit) 1367 proceeds from Step 2; otherwise, the retention constraint 1368 "Reassembly pending" MUST be added to the bundle and all remaining 1369 steps of this procedure MUST be skipped. 1371 Step 2: Delivery depends on the state of the registration whose 1372 endpoint ID matches that of the destination of the bundle: 1374 . An additional implementation-specific delivery deferral 1375 procedure MAY optionally be associated with the registration. 1376 . If the registration is in the Active state, then the bundle 1377 MUST be delivered automatically as soon as it is the next 1378 bundle that is due for delivery according to the BPA's bundle 1379 delivery scheduling policy, an implementation matter. 1380 . If the registration is in the Passive state, or if delivery of 1381 the bundle fails for some implementation-specific reason, then 1382 the registration's delivery failure action MUST be taken. 1383 Delivery failure action MUST be one of the following: 1385 o defer delivery of the bundle subject to this registration 1386 until (a) this bundle is the least recently received of 1387 all bundles currently deliverable subject to this 1388 registration and (b) either the registration is polled or 1389 else the registration is in the Active state, and also 1390 perform any additional delivery deferral procedure 1391 associated with the registration; or 1393 o abandon delivery of the bundle subject to this registration 1394 (as defined in 3.1. ). 1396 Step 3: As soon as the bundle has been delivered, if the "request 1397 reporting of bundle delivery" flag in the bundle's status report 1398 request field is set to 1 and bundle status reporting is enabled, 1399 then a bundle delivery status report SHOULD be generated, destined 1400 for the bundle's report-to endpoint ID. Note that this status report 1401 only states that the payload has been delivered to the application 1402 agent, not that the application agent has processed that payload. 1404 5.8. Bundle Fragmentation 1406 It may at times be advantageous for bundle protocol agents to reduce 1407 the sizes of bundles in order to forward them. This might be the 1408 case, for example, if a node to which a bundle is to be forwarded is 1409 accessible only via intermittent contacts and no upcoming contact is 1410 long enough to enable the forwarding of the entire bundle. 1412 The size of a bundle can be reduced by "fragmenting" the bundle. To 1413 fragment a bundle whose payload is of size M is to replace it with 1414 two "fragments" -- new bundles with the same source node ID and 1415 creation timestamp as the original bundle -- whose payloads are the 1416 first N and the last (M - N) bytes of the original bundle's payload, 1417 where 0 < N < M. Note that fragments may themselves be fragmented, 1418 so fragmentation may in effect replace the original bundle with more 1419 than two fragments. (However, there is only one 'level' of 1420 fragmentation, as in IP fragmentation.) 1422 Any bundle whose primary block's bundle processing flags do NOT 1423 indicate that it must not be fragmented MAY be fragmented at any 1424 time, for any purpose, at the discretion of the bundle protocol 1425 agent. NOTE, however, that some combinations of bundle 1426 fragmentation, replication, and routing might result in unexpected 1427 traffic patterns. 1429 Fragmentation SHALL be constrained as follows: 1431 . The concatenation of the payloads of all fragments produced by 1432 fragmentation MUST always be identical to the payload of the 1433 fragmented bundle (that is, the bundle that is being 1434 fragmented). Note that the payloads of fragments resulting from 1435 different fragmentation episodes, in different parts of the 1436 network, may be overlapping subsets of the fragmented bundle's 1437 payload. 1438 . The primary block of each fragment MUST differ from that of the 1439 fragmented bundle, in that the bundle processing flags of the 1440 fragment MUST indicate that the bundle is a fragment and both 1441 fragment offset and total application data unit length must be 1442 provided. Additionally, the CRC of the primary block of the 1443 fragmented bundle, if any, MUST be replaced in each fragment by 1444 a new CRC computed for the primary block of that fragment. 1446 . The payload blocks of fragments will differ from that of the 1447 fragmented bundle as noted above. 1448 . If the fragmented bundle is not a fragment or is the fragment 1449 with offset zero, then all extension blocks of the fragmented 1450 bundle MUST be replicated in the fragment whose offset is zero. 1451 . Each of the fragmented bundle's extension blocks whose "Block 1452 must be replicated in every fragment" flag is set to 1 MUST be 1453 replicated in every fragment. 1454 . Beyond these rules, replication of extension blocks in the 1455 fragments is an implementation matter. 1457 5.9. Application Data Unit Reassembly 1459 If the concatenation -- as informed by fragment offsets and payload 1460 lengths -- of the payloads of all previously received fragments with 1461 the same source node ID and creation timestamp as this fragment, 1462 together with the payload of this fragment, forms a byte array whose 1463 length is equal to the total application data unit length in the 1464 fragment's primary block, then: 1466 . This byte array -- the reassembled application data unit -- 1467 MUST replace the payload of this fragment. 1468 . The "Reassembly pending" retention constraint MUST be removed 1469 from every other fragment whose payload is a subset of the 1470 reassembled application data unit. 1472 Note: reassembly of application data units from fragments occurs at 1473 the nodes that are members of destination endpoints as necessary; an 1474 application data unit MAY also be reassembled at some other node on 1475 the path to the destination. 1477 5.10. Bundle Deletion 1479 The steps in deleting a bundle are: 1481 Step 1: If the "request reporting of bundle deletion" flag in the 1482 bundle's status report request field is set to 1, and if status 1483 reporting is enabled, then a bundle deletion status report citing 1484 the reason for deletion SHOULD be generated, destined for the 1485 bundle's report-to endpoint ID. 1487 Step 2: All of the bundle's retention constraints MUST be removed. 1489 5.11. Discarding a Bundle 1491 As soon as a bundle has no remaining retention constraints it MAY be 1492 discarded, thereby releasing any persistent storage that may have 1493 been allocated to it. 1495 5.12. Canceling a Transmission 1497 When requested to cancel a specified transmission, where the bundle 1498 created upon initiation of the indicated transmission has not yet 1499 been discarded, the bundle protocol agent MUST delete that bundle 1500 for the reason "transmission cancelled". For this purpose, the 1501 procedure defined in Section 5.10 MUST be followed. 1503 6. Administrative Record Processing 1505 6.1. Administrative Records 1507 Administrative records are standard application data units that are 1508 used in providing some of the features of the Bundle Protocol. One 1509 type of administrative record has been defined to date: bundle 1510 status reports. Note that additional types of administrative 1511 records may be defined by supplementary DTN protocol specification 1512 documents. 1514 Every administrative record consists of: 1516 . Record type code (an unsigned integer for which valid values 1517 are as defined below). 1518 . Record content in type-specific format. 1520 Valid administrative record type codes are defined as follows: 1522 +---------+--------------------------------------------+ 1524 | Value | Meaning | 1526 +=========+============================================+ 1528 | 1 | Bundle status report. | 1530 +---------+--------------------------------------------+ 1532 | (other) | Reserved for future use. | 1534 +---------+--------------------------------------------+ 1535 Figure 3: Administrative Record Type Codes 1537 Each BP administrative record SHALL be represented as a CBOR array 1538 comprising a 2-tuple. 1540 The first item of the array SHALL be a record type code, which SHALL 1541 be represented as a CBOR unsigned integer. 1543 The second element of this array SHALL be the applicable CBOR 1544 representation of the content of the record. Details of the CBOR 1545 representation of administrative record type 1 are provided below. 1546 Details of the CBOR representation of other types of administrative 1547 record type are included in the specifications defining those 1548 records. 1550 6.1.1. Bundle Status Reports 1552 The transmission of "bundle status reports" under specified 1553 conditions is an option that can be invoked when transmission of a 1554 bundle is requested. These reports are intended to provide 1555 information about how bundles are progressing through the system, 1556 including notices of receipt, forwarding, final delivery, and 1557 deletion. They are transmitted to the Report-to endpoints of 1558 bundles. 1560 Each bundle status report SHALL be represented as a CBOR array. The 1561 number of elements in the array SHALL be either 6 (if the subject 1562 bundle is a fragment) or 4 (otherwise). 1564 The first item of the bundle status report array SHALL be bundle 1565 status information represented as a CBOR array of at least 4 1566 elements. The first four items of the bundle status information 1567 array shall provide information on the following four status 1568 assertions, in this order: 1570 . Reporting node received bundle. 1571 . Reporting node forwarded the bundle. 1572 . Reporting node delivered the bundle. 1573 . Reporting node deleted the bundle. 1575 Each item of the bundle status information array SHALL be a bundle 1576 status item represented as a CBOR array; the number of elements in 1577 each such array SHALL be either 2 (if the value of the first item of 1578 this bundle status item is 1 AND the "Report status time" flag was 1579 set to 1 in the bundle processing flags of the bundle whose status 1580 is being reported) or 1 (otherwise). The first item of the bundle 1581 status item array SHALL be a status indicator, a Boolean value 1582 indicating whether or not the corresponding bundle status is 1583 asserted, represented as a CBOR Boolean value. The second item of 1584 the bundle status item array, if present, SHALL indicate the time 1585 (as reported by the local system clock, an implementation matter) at 1586 which the indicated status was asserted for this bundle, represented 1587 as a DTN time as described in Section 4.1.6. above. 1589 The second item of the bundle status report array SHALL be the 1590 bundle status report reason code explaining the value of the status 1591 indicator, represented as a CBOR unsigned integer. Valid status 1592 report reason codes are defined in Figure 4 below but the list of 1593 status report reason codes provided here is neither exhaustive nor 1594 exclusive; supplementary DTN protocol specifications (including, but 1595 not restricted to, the Bundle Security Protocol [BPSEC]) may define 1596 additional reason codes. 1598 +---------+--------------------------------------------+ 1600 | Value | Meaning | 1602 +=========+============================================+ 1604 | 0 | No additional information. | 1606 +---------+--------------------------------------------+ 1608 | 1 | Lifetime expired. | 1610 +---------+--------------------------------------------+ 1612 | 2 | Forwarded over unidirectional link. | 1614 +---------+--------------------------------------------+ 1616 | 3 | Transmission canceled. | 1618 +---------+--------------------------------------------+ 1620 | 4 | Depleted storage. | 1622 +---------+--------------------------------------------+ 1624 | 5 | Destination endpoint ID unintelligible. | 1626 +---------+--------------------------------------------+ 1628 | 6 | No known route to destination from here. | 1629 +---------+--------------------------------------------+ 1631 | 7 | No timely contact with next node on route. | 1633 +---------+--------------------------------------------+ 1635 | 8 | Block unintelligible. | 1637 +---------+--------------------------------------------+ 1639 | 9 | Hop limit exceeded. | 1641 +---------+--------------------------------------------+ 1643 | 10 | Traffic pared (e.g., status reports). | 1645 +---------+--------------------------------------------+ 1647 | (other) | Reserved for future use. | 1649 +---------+--------------------------------------------+ 1651 Figure 4: Status Report Reason Codes 1653 The third item of the bundle status report array SHALL be the source 1654 node ID identifying the source of the bundle whose status is being 1655 reported, represented as described in Section 4.1.5.2. above. 1657 The fourth item of the bundle status report array SHALL be the 1658 creation timestamp of the bundle whose status is being reported, 1659 represented as described in Section 4.1.7. above. 1661 The fifth item of the bundle status report array SHALL be present if 1662 and only if the bundle whose status is being reported contained a 1663 fragment offset. If present, it SHALL be the subject bundle's 1664 fragment offset represented as a CBOR unsigned integer item. 1666 The sixth item of the bundle status report array SHALL be present if 1667 and only if the bundle whose status is being reported contained a 1668 fragment offset. If present, it SHALL be the length of the subject 1669 bundle's payload represented as a CBOR unsigned integer item. 1671 Note that the forwarding parameters (such as lifetime, applicable 1672 security measures, etc.) of the bundle whose status is being 1673 reported MAY be reflected in the parameters governing the forwarding 1674 of the bundle that conveys a status report, but this is an 1675 implementation matter. Bundle protocol deployment experience to 1676 date has not been sufficient to suggest any clear guidance on this 1677 topic. 1679 6.2. Generation of Administrative Records 1681 Whenever the application agent's administrative element is directed 1682 by the bundle protocol agent to generate an administrative record 1683 with reference to some bundle, the following procedure must be 1684 followed: 1686 Step 1: The administrative record must be constructed. If the 1687 administrative record references a bundle and the referenced bundle 1688 is a fragment, the administrative record MUST contain the fragment 1689 offset and fragment length. 1691 Step 2: A request for transmission of a bundle whose payload is this 1692 administrative record MUST be presented to the bundle protocol 1693 agent. 1695 7. Services Required of the Convergence Layer 1697 7.1. The Convergence Layer 1699 The successful operation of the end-to-end bundle protocol depends 1700 on the operation of underlying protocols at what is termed the 1701 "convergence layer"; these protocols accomplish communication 1702 between nodes. A wide variety of protocols may serve this purpose, 1703 so long as each convergence layer protocol adapter provides a 1704 defined minimal set of services to the bundle protocol agent. This 1705 convergence layer service specification enumerates those services. 1707 7.2. Summary of Convergence Layer Services 1709 Each convergence layer protocol adapter is expected to provide the 1710 following services to the bundle protocol agent: 1712 . sending a bundle to a bundle node that is reachable via the 1713 convergence layer protocol; 1714 . notifying the bundle protocol agent when it has concluded its 1715 data sending procedures with regard to a bundle; 1716 . delivering to the bundle protocol agent a bundle that was sent 1717 by a bundle node via the convergence layer protocol. 1719 The convergence layer service interface specified here is neither 1720 exhaustive nor exclusive. That is, supplementary DTN protocol 1721 specifications (including, but not restricted to, the Bundle 1722 Security Protocol [BPSEC]) may expect convergence layer adapters 1723 that serve BP implementations conforming to those protocols to 1724 provide additional services such as reporting on the transmission 1725 and/or reception progress of individual bundles (at completion 1726 and/or incrementally), retransmitting data that were lost in 1727 transit, discarding bundle-conveying data units that the convergence 1728 layer protocol determines are corrupt or inauthentic, or reporting 1729 on the integrity and/or authenticity of delivered bundles. 1731 8. Implementation Status 1733 [NOTE to the RFC Editor: please remove this section before 1734 publication, as well as the reference to RFC 7942.] 1736 This section records the status of known implementations of the 1737 protocol defined by this specification at the time of posting of 1738 this Internet-Draft, and is based on a proposal described in RFC 1739 7942. The description of implementations in this section is 1740 intended to assist the IETF in its decision processes in progressing 1741 drafts to RFCs. Please note that the listing of any individual 1742 implementation here does not imply endorsement by the IETF. 1743 Furthermore, no effort has been spent to verify the information 1744 presented here that was supplied by IETF contributors. This is not 1745 intended as, and must not be construed to be, a catalog of available 1746 implementations or their features. Readers are advised to note that 1747 other implementations may exist. 1749 According to RFC 7942, "this will allow reviewers and working groups 1750 to assign due consideration to documents that have the benefit of 1751 running code, which may serve as evidence of valuable 1752 experimentation and feedback that have made the implemented 1753 protocols more mature. It is up to the individual working groups to 1754 use this information as they see fit". 1756 At the time of this writing, there are three known implementations 1757 of the current document. 1759 The first known implementation is microPCN (https://upcn.eu/). 1760 According to the developers: 1762 The Micro Planetary Communication Network (uPCN) is a free 1763 software project intended to offer an implementation of Delay- 1764 tolerant Networking protocols for POSIX operating systems (well, 1765 and for Linux) plus for the ARM Cortex STM32F4 microcontroller 1766 series. More precisely it currently provides an implementation of 1768 . the Bundle Protocol (BP, RFC 5050), 1769 . the Bundle Protocol version 7 specification draft (version 6), 1770 . the DTN IP Neighbor Discovery (IPND) protocol, and 1771 . a routing approach optimized for message-ferry micro LEO 1772 satellites. 1774 uPCN is written in C and is built upon the real-time operating 1775 system FreeRTOS. The source code of uPCN is released under the 1776 "BSD 3-Clause License". 1778 The project depends on an execution environment offering link 1779 layer protocols such as AX.25. The source code uses the USB 1780 subsystem to interact with the environment. 1782 The second known implementation is PyDTN, developed by X-works, 1783 s.r.o (https://x-works.sk/). The final third of the implementation 1784 was developed during the IETF 101 Hackathon. According to the 1785 developers, PyDTN implements bundle coding/decoding and neighbor 1786 discovery. PyDTN is written in Python and has been shown to be 1787 interoperable with uPCN. 1789 The third known implementation is "Terra" 1790 (https://github.com/RightMesh/Terra/), a Java implementation 1791 developed in the context of terrestrial DTN. It includes an 1792 implementation of a "minimal TCP" convergence layer adapter. 1794 9. Security Considerations 1796 The bundle protocol security architecture and the available security 1797 services are specified in an accompanying document, the Bundle 1798 Security Protocol specification [BPSEC]. 1800 The bpsec extensions to Bundle Protocol enable each block of a 1801 bundle (other than a bpsec extension block) to be individually 1802 authenticated by a signature block (Block Integrity Block, or BIB) 1803 and also enable each block of a bundle other than the primary block 1804 (and the bpsec extension blocks themselves) to be individually 1805 encrypted by a BCB. 1807 Because the security mechanisms are extension blocks that are 1808 themselves inserted into the bundle, the integrity and 1809 confidentiality of bundle blocks are protected while the bundle is 1810 at rest, awaiting transmission at the next forwarding opportunity, 1811 as well as in transit. 1813 Additionally, convergence-layer protocols that ensure authenticity 1814 of communication between adjacent nodes in BP network topology 1815 SHOULD be used where available, to minimize the ability of 1816 unauthenticated nodes to introduce inauthentic traffic into the 1817 network. Convergence-layer protocols that ensure confidentiality of 1818 communication between adjacent nodes in BP network topology SHOULD 1819 also be used where available, to minimize exposure of the bundle's 1820 primary block and other clear-text blocks, thereby offering some 1821 defense against traffic analysis. 1823 Note that, while the primary block must remain in the clear for 1824 routing purposes, the Bundle Protocol could be protected against 1825 traffic analysis to some extent by using bundle-in-bundle 1826 encapsulation to tunnel bundles to a safe forward distribution 1827 point: the encapsulated bundle could form the payload of an 1828 encapsulating bundle, and that payload block could be encrypted by a 1829 BCB. Bundle-in-bundle encapsulation is a current research topic. 1831 Note that the generation of bundle status reports is disabled by 1832 default because malicious initiation of bundle status reporting 1833 could result in the transmission of extremely large numbers of 1834 bundles, effecting a denial of service attack. 1836 The bpsec extensions accommodate an open-ended range of 1837 ciphersuites; different ciphersuites may be utilized to protect 1838 different blocks. One possible variation is to sign and/or encrypt 1839 blocks using symmetric keys securely formed by Diffie-Hellman 1840 procedures (such as EKDH) using the public and private keys of the 1841 sending and receiving nodes. For this purpose, the key distribution 1842 problem reduces to the problem of trustworthy delay-tolerant 1843 distribution of public keys, a current research topic. 1845 10. IANA Considerations 1847 The Bundle Protocol includes fields requiring registries managed by 1848 IANA. 1850 10.1. Bundle Block Types 1852 The current Bundle Block Types namespace is augmented by adding a 1853 column identifying the version of the Bundle protocol (Bundle 1854 Protocol Version) that applies to the new values. IANA is requested 1855 to add the following values, as described in section 4.3.1, to the 1856 Bundle Block Types namespace. The current values in the Bundle Block 1857 Types namespace should have the Bundle Protocol Version set to the 1858 value "6", as shown below. 1860 +----------+-------+-----------------------------+---------------+ 1862 | Bundle | Value | Description | Reference | 1863 | Protocol | | | | 1865 | Version | | | | 1867 +----------+-------+-----------------------------+---------------+ 1869 | none | 0 | Reserved | [RFC6255] | 1871 | 6,7 | 1 | Bundle Payload Block | [RFC5050] | 1873 | | | | RFC-to-be | 1875 | 6 | 2 | Bundle Authentication Block | [RFC6257] | 1877 | 6 | 3 | Payload Integrity Block | [RFC6257] | 1879 | 6 | 4 | Payload Confidentiality Blk | [RFC6257] | 1881 | 6 | 5 | Previous-Hop Insertion Block| [RFC6259] | 1883 | 7 | 6 | Previous node (proximate | RFC-to-be | 1885 | | | sender) | | 1887 | 7 | 7 | Bundle age (in seconds) | RFC-to-be | 1889 | 6 | 8 | Metadata Extension Block | [RFC6258] | 1891 | 6 | 9 | Extension Security Block | [RFC6257] | 1893 | 7 | 10 | Hop count (#prior xmit | RFC-to-be | 1895 | | | attempts) | | 1897 | 7 | 11-191| Unassigned | | 1899 | 6 |192-255| Reserved for Private and/or | [RFC5050], | 1901 | | | Experimental Use | RFC-to-be | 1903 +----------+-------+-----------------------------+---------------+ 1905 10.2. Primary Bundle Protocol Version 1907 IANA is requested to add the following value to the Primary Bundle 1908 Protocol Version namespace. 1910 +-------+-------------+---------------+ 1912 | Value | Description | Reference | 1914 +-------+-------------+---------------+ 1916 | 7 | Assigned | RFC-to-be | 1918 +-------+-------------+---------------+ 1920 10.3. Bundle Processing Control Flags 1922 The current Bundle Processing Control Flags namespace is augmented 1923 by adding a column identifying the version of the Bundle protocol 1924 (Bundle Protocol Version) that applies to the new values. IANA is 1925 requested to add the following values, as described in section 4.1.3 1926 to the Bundle Processing Control Flags namespace. The current values 1927 in the Bundle Processing Control Flags namespace should have the 1928 Bundle Protocol Version set to the value 6 or "6, 7", as shown 1929 below. 1931 Bundle Processing Control Flags Registry 1933 +--------------------+----------------------------------+----------+ 1935 | Bundle | Bit | Description | Reference| 1937 | Protocol| Position | | | 1939 | Version | (right | | | 1941 | | to left) | | | 1943 +--------------------+----------------------------------+----------+ 1945 | 6,7 | 0 | Bundle is a fragment |[RFC5050],| 1947 | | | |RFC-to-be | 1949 | 6,7 | 1 | Application data unit is an |[RFC5050],| 1951 | | | administrative record |RFC-to-be | 1953 | 6,7 | 2 | Bundle must not be fragmented |[RFC5050],| 1955 | | | |RFC-to-be | 1956 | 6 | 3 | Custody transfer is requested |[RFC5050] | 1958 | 6 | 4 | Destination endpoint is singleton|[RFC5050] | 1960 | 6,7 | 5 | Acknowledgement by application |[RFC5050],| 1962 | | | is requested |RFC-to-be | 1964 | 7 | 6 | Status time requested in reports |RFC-to-be | 1966 | 6 | 7 | Class of service, priority |[RFC5050],| 1968 | | | |RFC-to-be | 1970 | 6 | 8 | Class of service, priority |[RFC5050],| 1972 | | | |RFC-to-be | 1974 | 6 | 9 | Class of service, reserved |[RFC5050],| 1976 | | | |RFC-to-be | 1978 | 6 | 10 | Class of service, reserved |[RFC5050],| 1980 | | | |RFC-to-be | 1982 | 6 | 11 | Class of service, reserved |[RFC5050],| 1984 | | | |RFC-to-be | 1986 | 6 | 12 | Class of service, reserved |[RFC5050],| 1988 | | | |RFC-to-be | 1990 | 6 | 13 | Class of service, reserved |[RFC5050],| 1992 | | | |RFC-to-be | 1994 | 6,7 | 14 | Request reporting of bundle |[RFC5050],| 1996 | | | reception |RFC-to-be | 1998 | 6,7 | 16 | Request reporting of bundle |[RFC5050],| 2000 | | | forwarding |RFC-to-be | 2002 | 6,7 | 17 | Request reporting of bundle |[RFC5050],| 2003 | | | delivery |RFC-to-be | 2005 | 6,7 | 18 | Request reporting of bundle |[RFC5050],| 2007 | | | deletion |RFC-to-be | 2009 | 6 | 19 | Reserved |[RFC5050],| 2011 | | | |RFC-to-be | 2013 | 6 | 20 | Reserved |[RFC5050],| 2015 | | | |RFC-to-be | 2017 | | 21-63 | Unassigned | | 2019 +--------------------+----------------------------------+----------+ 2021 The registration policy for this namespace is changed to "Standards 2022 Action". Given the limited number of bits available, the allocation 2023 should only be granted for a standards-track RFC approved by the 2024 IESG. 2026 10.4. Block Processing Control Flags 2028 The current Block Processing Control Flags namespace is augmented by 2029 adding a column identifying the version of the Bundle protocol 2030 (Bundle Protocol Version) that applies to the related BP version. 2031 The current values in the Block Processing Control Flags namespace 2032 should have the Bundle Protocol Version set to the value 6 or "6, 2033 7", as shown below. 2035 Block Processing Control Flags Registry 2037 +--------------------+----------------------------------+----------+ 2039 | Bundle | Bit | Description | Reference| 2041 | Protocol| Position | | | 2043 | Version | (right | | | 2045 | | to left) | | | 2047 +--------------------+----------------------------------+----------+ 2049 | 6,7 | 0 | Block must be replicated in |[RFC5050],| 2050 | | | every fragment |RFC-to-be | 2052 | 6,7 | 1 | Transmit status report if block |[RFC5050],| 2054 | | | can't be processed |RFC-to-be | 2056 | 6,7 | 2 | Delete bundle if block can't be |[RFC5050],| 2058 | | | processed |RFC-to-be | 2060 | 6 | 3 | Last block |[RFC5050] | 2062 | 6,7 | 4 | Discard block if it can't be |[RFC5050],| 2064 | | | processed |RFC-to-be | 2066 | 6 | 5 | Block was forwarded without |[RFC5050] | 2068 | | | being processed | | 2070 | 6 | 6 | Block contains an EID reference |[RFC5050] | 2072 | | | field | | 2074 | | 7-63 | Unassigned | | 2076 +--------------------+----------------------------------+----------+ 2078 10.5. Bundle Status Report Reason Codes 2080 The current Bundle Status Report Reason Codes namespace is augmented 2081 by adding a column identifying the version of the Bundle protocol 2082 (Bundle Protocol Version) that applies to the new values. IANA is 2083 requested to add the following values, as described in section 2084 6.1.1, to the Bundle Status Report Reason Codes namespace. The 2085 current values in the Bundle Status Report Reason Codes namespace 2086 should have the Bundle Protocol Version set to the value 6 or 7 or 2087 "6, 7", as shown below. 2089 Bundle Status Report Reason Codes Registry 2091 +--------------------+----------------------------------+----------+ 2093 | Bundle | Value | Description | Reference| 2095 | Protocol| | | | 2096 | Version | | | | 2098 | | | | | 2100 +--------------------+----------------------------------+----------+ 2102 | 6,7 | 0 | No additional information |[RFC5050],| 2104 | | | |RFC-to-be | 2106 | 6,7 | 1 | Lifetime expired |[RFC5050],| 2108 | | | |RFC-to-be | 2110 | 6,7 | 2 | Forwarded over unidirectional |[RFC5050],| 2112 | | | link |RFC-to-be | 2114 | 6,7 | 3 | Transmission canceled |[RFC5050],| 2116 | | | |RFC-to-be | 2118 | 6,7 | 4 | Depleted storage |[RFC5050],| 2120 | | | |RFC-to-be | 2122 | 6,7 | 5 | Destination endpoint ID |[RFC5050],| 2124 | | | unintelligible |RFC-to-be | 2126 | 6,7 | 6 | No known route to destination |[RFC5050],| 2128 | | | from here |RFC-to-be | 2130 | 6,7 | 7 | No timely contact with next node |[RFC5050],| 2132 | | | on route |RFC-to-be | 2134 | 6,7 | 8 | Block unintelligible |[RFC6255],| 2136 | | | |RFC-to-be | 2138 | 7 | 9 | Hop limit exceeded |RFC-to-be | 2140 | 7 | 10 | Traffic pared |RFC-to-be | 2142 | | 11-254 | Unassigned | | 2143 | 6 | 255 | Reserved |[RFC6255] | 2145 +-------+-----------------------------------------------+----------+ 2147 10.6. Bundle Protocol URI scheme types 2149 The Bundle Protocol has a URI scheme type field - an unsigned 2150 integer of undefined length - for which IANA is requested to create 2151 and maintain a new "Bundle Protocol URI Scheme Type " registry. The 2152 "Bundle Protocol URI Scheme Type" registry governs an 8-bit 2153 namespace. Initial values for the Bundle Protocol URI Scheme Type 2154 space are given below. 2156 The registration policy for this namespace is: Specification 2157 Required. The nominated expert(s) verify that a specification exists 2158 and is readily accessible. Specifications for new registrations need 2159 to reference the documents defining the URIs for which new scheme 2160 types are being registered. Expert(s) are encouraged to be biased 2161 towards approving registrations unless they are abusive, frivolous, 2162 or actively harmful (not merely aesthetically displeasing, or 2163 architecturally dubious). 2165 The value range is: unsigned 8-bit integer. 2167 Each assignment consists of a URI scheme type name and its 2168 associated description and reference. 2170 Bundle Protocol URI Scheme Type Registry 2172 +--------------+-----------------------------+-------------------+ 2174 | Value | Description | Reference | 2176 +--------------+-----------------------------+-------------------+ 2178 | 0 | Reserved | | 2180 | 1 | dtn | RFC-to-be | 2182 | 2 | ipn | [RFC6260] | 2184 | 3-254 | Unassigned | | 2186 | 255 | reserved | | 2188 +--------------+-----------------------------+-------------------+ 2190 10.7. URI scheme "dtn" 2192 IANA is requested to update the registration of the URI scheme with 2193 the string "dtn" as the scheme name, as follows: 2195 URI scheme name: "dtn" 2197 Status: permanent 2199 URI scheme syntax: 2201 This specification uses the Augmented Backus-Naur Form (ABNF) 2202 notation of [RFC5234]. 2204 dtn-uri = "dtn:" dtn-hier-part 2206 dtn-hier-part = "//" node-name name-delim demux ; a path-rootless 2208 node-name = 1*VCHAR 2210 name-delim = "/" 2212 demux = *VCHAR 2214 None of the reserved characters defined in the generic URI syntax 2215 are used as delimiters within URIs of the DTN scheme. 2217 URI scheme semantics: URIs of the DTN scheme are used as endpoint 2218 identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol 2219 (BP) as described in Section 4.1.5.1. 2221 Encoding considerations: URIs of the DTN scheme are encoded 2222 exclusively in US-ASCII characters. 2224 Applications and/or protocols that use this URI scheme name: the 2225 Delay-Tolerant Networking (DTN) Bundle Protocol (BP). 2227 Interoperability considerations: as noted above, URIs of the DTN 2228 scheme are encoded exclusively in US-ASCII characters. 2230 Security considerations: 2232 . Reliability and consistency: none of the BP endpoints 2233 identified by the URIs of the DTN scheme are guaranteed to be 2234 reachable at any time, and the identity of the processing 2235 entities operating on those endpoints is never guaranteed by 2236 the Bundle Protocol itself. Bundle authentication as defined by 2237 the Bundle Security Protocol is required for this purpose. 2238 . Malicious construction: malicious construction of a conformant 2239 DTN-scheme URI is limited to the malicious selection of node 2240 names and the malicious selection of demux strings. That is, a 2241 maliciously constructed DTN-scheme URI could be used to direct 2242 a bundle to an endpoint that might be damaged by the arrival of 2243 that bundle or, alternatively, to declare a false source for a 2244 bundle and thereby cause incorrect processing at a node that 2245 receives the bundle. In both cases (and indeed in all bundle 2246 processing), the node that receives a bundle should verify its 2247 authenticity and validity before operating on it in any way. 2248 . Back-end transcoding: the limited expressiveness of URIs of the 2249 DTN scheme effectively eliminates the possibility of threat due 2250 to errors in back-end transcoding. 2251 . Rare IP address formats: not relevant, as IP addresses do not 2252 appear anywhere in conformant DTN-scheme URIs. 2253 . Sensitive information: because DTN-scheme URIs are used only to 2254 represent the identities of Bundle Protocol endpoints, the risk 2255 of disclosure of sensitive information due to interception of 2256 these URIs is minimal. Examination of DTN-scheme URIs could be 2257 used to support traffic analysis; where traffic analysis is a 2258 plausible danger, bundles should be conveyed by secure 2259 convergence-layer protocols that do not expose endpoint IDs. 2260 . Semantic attacks: the simplicity of DTN-scheme URI syntax 2261 minimizes the possibility of misinterpretation of a URI by a 2262 human user. 2264 Contact: 2266 Scott Burleigh 2268 Jet Propulsion Laboratory, 2270 California Institute of Technology 2272 scott.c.burleigh@jpl.nasa.gov 2274 +1 (800) 393-3353 2276 Author/Change controller: 2278 Scott Burleigh 2280 Jet Propulsion Laboratory, 2281 California Institute of Technology 2283 scott.c.burleigh@jpl.nasa.gov 2285 10.8. Change status of URI scheme "ipn" 2287 IANA is requested to change to "permanent" the status of the URI 2288 scheme named "ipn". 2290 11. References 2292 11.1. Normative References 2294 [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work 2295 In Progress, October 2015. 2297 [CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4, 2298 International Telecommunications Union, October 1996. 2300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2301 Requirement Levels", BCP 14, RFC 2119, March 1997. 2303 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 2304 4960, September 2007. 2306 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2307 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2309 [RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object 2310 Representation (CBOR)", RFC 7049, October 2013. 2312 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2313 2119 Key Words", BCP 14, RFC 8174, May 2017. 2315 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2316 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 2317 January 2005. 2319 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2320 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 2321 2015. 2323 11.2. Informative References 2325 [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 2326 4838, April 2007. 2328 [BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", Work In 2329 Progress, June 2017. 2331 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 2332 Identifiers (IRIs)", RFC 3987, January 2005. 2334 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 2335 Specification", RFC 5050, November 2007. 2337 [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol 2338 IANA Registries", RFC 6255, May 2011. 2340 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 2341 "Bundle Security Protocol Specification", RFC 6257, May 2011. 2343 [RFC6258] Symington, S., "Delay-Tolerant Networking Metadata 2344 Extension Block", RFC 6258, May 2011. 2346 [RFC6259] Symington, S., "Delay-Tolerant Networking Previous-Hop 2347 Insertion Block", RFC 6259, May 2011. 2349 [RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", 2350 RFC 6260, May 2011. 2352 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, 2353 "Internet Small Computer System Interface (iSCSI) Protocol 2354 (Consolidated)", RFC 7143, April 2014. 2356 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 2357 Challenged Internets", SIGCOMM 2003. 2359 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 2360 historical background and perspectives" in "Journees systemes de 2361 reference spatio-temporels", 2004. 2363 12. Acknowledgments 2365 This work is freely adapted from RFC 5050, which was an effort of 2366 the Delay Tolerant Networking Research Group. The following DTNRG 2367 participants contributed significant technical material and/or 2368 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 2369 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 2370 Michael Demmer of the University of California at Berkeley, Robert 2371 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 2372 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 2373 College Dublin, Howard Weiss and Peter Lovell of SPARTA, Inc., and 2374 Manikantan Ramadas of Ohio University. 2376 This document was prepared using 2-Word-v2.0.template.dot. 2378 13. Significant Changes from RFC 5050 2380 Points on which this draft significantly differs from RFC 5050 2381 include the following: 2383 . Clarify the difference between transmission and forwarding. 2384 . Migrate custody transfer to the bundle-in-bundle encapsulation 2385 specification [BIBE]. 2386 . Introduce the concept of "node ID" as functionally distinct 2387 from endpoint ID, while having the same syntax. 2388 . Restructure primary block, making it immutable. Add optional 2389 CRC. 2390 . Add optional CRCs to non-primary blocks. 2391 . Add block ID number to canonical block format (to support 2392 BPSEC). 2393 . Add definition of bundle age extension block. 2394 . Add definition of previous node extension block. 2395 . Add definition of hop count extension block. 2396 . Remove Quality of Service markings. 2397 . Change from SDNVs to CBOR representation. 2399 Appendix A. For More Information 2401 Copyright (c) 2020 IETF Trust and the persons identified as authors 2402 of the code. All rights reserved. 2404 Redistribution and use in source and binary forms, with or without 2405 modification, is permitted pursuant to, and subject to the license 2406 terms contained in, the Simplified BSD License set forth in Section 2407 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2408 (http://trustee.ietf.org/license-info). 2410 Appendix B. CDDL expression 2412 For informational purposes, Carsten Bormann and Brian Sipos have 2413 kindly provided an expression of the Bundle Protocol specification 2414 in the Concise Data Definition Language (CDDL). That CDDL 2415 expression is presented below. Note that wherever the CDDL 2416 expression is in disagreement with the textual representation of the 2417 BP specification presented in the earlier sections of this document, 2418 the textual representation rules. 2420 start = bundle / #6.55799(bundle) 2422 ; Times before 2000 are invalid 2424 dtn-time = uint 2426 ; CRC enumerated type 2428 crc-type = &( 2430 crc-none: 0, 2432 crc-16bit: 1, 2434 crc-32bit: 2 2436 ) 2438 ; Either 16-bit or 32-bit 2440 crc-value = (bstr .size 2) / (bstr .size 4) 2442 creation-timestamp = [ 2444 dtn-time, ; absolute time of creation 2446 sequence: uint ; sequence within the time 2448 ] 2450 eid = $eid .within eid-structure 2452 eid-structure = [ 2454 uri-code: uint, 2455 SSP: any 2457 ] 2459 $eid /= [ 2461 uri-code: 1, 2463 SSP: (tstr / 0) 2465 ] 2467 $eid /= [ 2469 uri-code: 2, 2471 SSP: [ 2473 nodenum: uint, 2475 servicenum: uint 2477 ] 2479 ] 2481 ; The root bundle array 2483 bundle = [primary-block, *extension-block, payload-block] 2485 primary-block = [ 2487 version: 7, 2489 bundle-control-flags, 2491 crc-type, 2493 destination: eid, 2495 source-node: eid, 2497 report-to: eid, 2499 creation-timestamp, 2501 lifetime: uint, 2502 ? ( 2504 fragment-offset: uint, 2506 total-application-data-length: uint 2508 ), 2510 ? crc-value, 2512 ] 2514 bundle-control-flags = uint .bits bundleflagbits 2516 bundleflagbits = &( 2518 reserved: 21, 2520 reserved: 20, 2522 reserved: 19, 2524 bundle-deletion-status-reports-are-requested: 18, 2526 bundle-delivery-status-reports-are-requested: 17, 2528 bundle-forwarding-status-reports-are-requested: 16, 2530 reserved: 15, 2532 bundle-reception-status-reports-are-requested: 14, 2534 reserved: 13, 2536 reserved: 12, 2538 reserved: 11, 2540 reserved: 10, 2542 reserved: 9, 2544 reserved: 8, 2546 reserved: 7, 2547 status-time-is-requested-in-all-status-reports: 6, 2549 user-application-acknowledgement-is-requested: 5, 2551 reserved: 4, 2553 reserved: 3, 2555 bundle-must-not-be-fragmented: 2, 2557 payload-is-an-administrative-record: 1, 2559 bundle-is-a-fragment: 0 2561 ) 2563 ; Abstract shared structure of all non-primary blocks 2565 canonical-block-structure = [ 2567 block-type-code: uint, 2569 block-number: uint, 2571 block-control-flags, 2573 crc-type, 2575 ; Each block type defines the content within the bytestring 2577 block-type-specific-data, 2579 ? crc-value 2581 ] 2583 block-control-flags = uint .bits blockflagbits 2585 blockflagbits = &( 2587 reserved: 7, 2589 reserved: 6, 2591 reserved: 5, 2593 block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4, 2594 reserved: 3, 2596 bundle-must-be-deleted-if-block-cannot-be-processed: 2, 2598 status-report-must-be-transmitted-if-block-cannot-be-processed: 1, 2600 block-must-be-replicated-in-every-fragment: 0 2602 ) 2604 block-type-specific-data = bstr / #6.24(bstr) 2606 ; Actual CBOR data embedded in a bytestring, with optional tag to 2607 indicate so 2609 embedded-cbor = (bstr .cbor Item) / #6.24(bstr .cbor Item) 2611 ; Extension block type, which does not specialize other than the 2612 code/number 2614 extension-block = $extension-block-structure .within canonical- 2615 block-structure 2617 ; Generic shared structure of all non-primary blocks 2619 extension-block-use = [ 2621 block-type-code: CodeValue, 2623 block-number: (uint .gt 1), 2625 block-control-flags, 2627 crc-type, 2629 BlockData, 2631 ? crc-value 2633 ] 2635 ; Payload block type 2637 payload-block = payload-block-structure .within canonical-block- 2638 structure 2639 payload-block-structure = [ 2641 block-type-code: 1, 2643 block-number: 1, 2645 block-control-flags, 2647 crc-type, 2649 $payload-block-data, 2651 ? crc-value 2653 ] 2655 ; Arbitrary payload data, including non-CBOR bytestring 2657 $payload-block-data /= block-type-specific-data 2659 ; Administrative record as a payload data specialization 2661 $payload-block-data /= embedded-cbor 2663 admin-record = $admin-record .within admin-record-structure 2665 admin-record-structure = [ 2667 record-type-code: uint, 2669 record-content: any 2671 ] 2673 ; Only one defined record type 2675 $admin-record /= [1, status-record-content] 2677 status-record-content = [ 2679 bundle-status-information, 2681 status-report-reason-code: uint, 2683 source-node-eid: eid, 2685 subject-creation-timestamp: creation-timestamp, 2686 ? ( 2688 subject-payload-offset: uint, 2690 subject-payload-length: uint 2692 ) 2694 ] 2696 bundle-status-information = [ 2698 reporting-node-received-bundle: status-info-content, 2700 reporting-node-forwarded-bundle: status-info-content, 2702 reporting-node-delivered-bundle: status-info-content, 2704 reporting-node-deleted-bundle: status-info-content 2706 ] 2708 status-info-content = [ 2710 status-indicator: bool, 2712 ? timestamp: dtn-time 2714 ] 2716 ; Previous Node extension block 2718 $extension-block-structure /= 2720 extension-block-use<6, embedded-cbor> 2722 ext-data-previous-node = eid 2724 ; Bundle Age extension block 2726 $extension-block-structure /= 2728 extension-block-use<7, embedded-cbor> 2730 ext-data-bundle-age = uint 2732 ; Hop Count extension block 2733 $extension-block-structure /= 2735 extension-block-use<10, embedded-cbor> 2737 ext-data-hop-count = [ 2739 hop-limit: uint, 2741 hop-count: uint 2743 ] 2745 Authors' Addresses 2747 Scott Burleigh 2748 Jet Propulsion Laboratory, California Institute of Technology 2749 4800 Oak Grove Dr. 2750 Pasadena, CA 91109-8099 2751 US 2752 Phone: +1 818 393 3353 2753 Email: Scott.C.Burleigh@jpl.nasa.gov 2755 Kevin Fall 2756 Roland Computing Services 2757 3871 Piedmont Ave. Suite 8 2758 Oakland, CA 94611 2759 US 2760 Email: kfall+rcs@kfall.com 2762 Edward J. Birrane 2763 Johns Hopkins University Applied Physics Laboratory 2764 11100 Johns Hopkins Rd 2765 Laurel, MD 20723 2766 US 2767 Phone: +1 443 778 7423 2768 Email: Edward.Birrane@jhuapl.edu