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