idnits 2.17.1 draft-ietf-dtn-bpbis-25.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 (May 22, 2020) is 1407 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. 'CRC16' ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) -- Possible downref: Non-RFC (?) normative reference: ref. 'SABR' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTC' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay-Tolerant Networking Working Group S. Burleigh 2 Internet Draft JPL, Calif. Inst. Of Technology 3 Intended status: Standards Track K. Fall 4 Expires: November 23, 2020 Roland Computing Services 5 E. Birrane 6 APL, Johns Hopkins University 7 May 22, 2020 9 Bundle Protocol Version 7 10 draft-ietf-dtn-bpbis-25.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 November 23, 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 the Bundle 53 Protocol, adapted from the experimental Bundle Protocol 54 specification developed by the Delay-Tolerant Networking Research 55 group of the Internet Research Task Force and documented in RFC 56 5050. 58 Table of Contents 60 1. Introduction...................................................3 61 2. Conventions used in this document..............................5 62 3. Service Description............................................5 63 3.1. Definitions...............................................5 64 3.2. Discussion of BP concepts.................................9 65 3.3. Services Offered by Bundle Protocol Agents...............12 66 4. Bundle Format.................................................13 67 4.1. BP Fundamental Data Structures...........................13 68 4.1.1. CRC Type............................................13 69 4.1.2. CRC.................................................14 70 4.1.3. Bundle Processing Control Flags.....................14 71 4.1.4. Block Processing Control Flags......................16 72 4.1.5. Identifiers.........................................17 73 4.1.5.1. Endpoint ID....................................17 74 4.1.5.2. Node ID........................................18 75 4.1.6. DTN Time............................................21 76 4.1.7. Creation Timestamp..................................21 77 4.1.8. Block-type-specific Data............................22 78 4.2. Bundle Representation....................................22 79 4.2.1. Bundle..............................................22 80 4.2.2. Primary Bundle Block................................23 81 4.2.3. Canonical Bundle Block Format.......................25 82 4.3. Extension Blocks.........................................26 83 4.3.1. Previous Node.......................................27 84 4.3.2. Bundle Age..........................................27 85 4.3.3. Hop Count...........................................27 86 5. Bundle Processing.............................................28 87 5.1. Generation of Administrative Records.....................28 88 5.2. Bundle Transmission......................................29 89 5.3. Bundle Dispatching.......................................29 90 5.4. Bundle Forwarding........................................30 91 5.4.1. Forwarding Contraindicated..........................32 92 5.4.2. Forwarding Failed...................................32 94 5.5. Bundle Expiration........................................33 95 5.6. Bundle Reception.........................................33 96 5.7. Local Bundle Delivery....................................34 97 5.8. Bundle Fragmentation.....................................35 98 5.9. Application Data Unit Reassembly.........................36 99 5.10. Bundle Deletion.........................................37 100 5.11. Discarding a Bundle.....................................37 101 5.12. Canceling a Transmission................................37 102 6. Administrative Record Processing..............................37 103 6.1. Administrative Records...................................37 104 6.1.1. Bundle Status Reports...............................38 105 6.2. Generation of Administrative Records.....................41 106 7. Services Required of the Convergence Layer....................42 107 7.1. The Convergence Layer....................................42 108 7.2. Summary of Convergence Layer Services....................42 109 8. Implementation Status.........................................43 110 9. Security Considerations.......................................44 111 10. IANA Considerations..........................................45 112 10.1. Bundle Block Types......................................45 113 10.2. Primary Bundle Protocol Version.........................47 114 10.3. Bundle Processing Control Flags.........................47 115 10.4. Block Processing Control Flags..........................49 116 10.5. Bundle Status Report Reason Codes.......................50 117 10.6. Bundle Protocol URI scheme types........................52 118 10.7. URI scheme "dtn"........................................53 119 10.8. URI scheme "ipn"........................................54 120 11. References...................................................54 121 11.1. Normative References....................................54 122 11.2. Informative References..................................55 123 12. Acknowledgments..............................................56 124 13. Significant Changes from RFC 5050............................56 125 Appendix A. For More Information.................................58 126 Appendix B. CDDL expression......................................59 128 1. Introduction 130 Since the publication of the Bundle Protocol Specification 131 (Experimental RFC 5050 [RFC5050]) in 2007, the Delay-Tolerant 132 Networking (DTN) Bundle Protocol has been implemented in multiple 133 programming languages and deployed to a wide variety of computing 134 platforms. This implementation and deployment experience has 135 identified opportunities for making the protocol simpler, more 136 capable, and easier to use. The present document, standardizing the 137 Bundle Protocol (BP), is adapted from RFC 5050 in that context, 138 reflecting lessons learned. Significant changes from the Bundle 139 Protocol specification defined in RFC 5050 are listed in section 13. 141 This document describes version 7 of BP. 143 Delay Tolerant Networking is a network architecture providing 144 communications in and/or through highly stressed environments. 145 Stressed networking environments include those with intermittent 146 connectivity, large and/or variable delays, and high bit error 147 rates. To provide its services, BP may be viewed as sitting at the 148 application layer of some number of constituent networks, forming a 149 store-carry-forward overlay network. Key capabilities of BP 150 include: 152 . Ability to use physical motility for the movement of data 153 . Ability to move the responsibility for error control from one 154 node to another 155 . Ability to cope with intermittent connectivity, including cases 156 where the sender and receiver are not concurrently present in 157 the network 158 . Ability to take advantage of scheduled, predicted, and 159 opportunistic connectivity, whether bidirectional or 160 unidirectional, in addition to continuous connectivity 161 . Late binding of overlay network endpoint identifiers to 162 underlying constituent network addresses 164 For descriptions of these capabilities and the rationale for the DTN 165 architecture, see [ARCH] and [SIGC]. 167 BP's location within the standard protocol stack is as shown in Figure 168 1. BP uses underlying "native" transport and/or network protocols for 169 communications within a given constituent network. The layer at which 170 those underlying protocols are located is here termed the "convergence 171 layer" and the interface between the bundle protocol and a specific 172 underlying protocol is termed a "convergence layer adapter". 174 Figure 1 shows three distinct transport and network protocols 175 (denoted T1/N1, T2/N2, and T3/N3). 177 +-----------+ +-----------+ 178 | BP app | | BP app | 179 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 180 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 181 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 182 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 183 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 184 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 185 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 186 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 187 +-----------+ +-------------+ +-------------+ +-----------+ 188 | | | | 189 |<---- A network ---->| |<---- A network ---->| 190 | | | | 192 Figure 1: The Bundle Protocol in the Protocol Stack Model 194 This document describes the format of the protocol data units 195 (called "bundles") passed between entities participating in BP 196 communications. 198 The entities are referred to as "bundle nodes". This document does 199 not address: 201 . Operations in the convergence layer adapters that bundle nodes 202 use to transport data through specific types of internets. 203 (However, the document does discuss the services that must be 204 provided by each adapter at the convergence layer.) 205 . The bundle route computation algorithm. 206 . Mechanisms for populating the routing or forwarding information 207 bases of bundle nodes. 208 . The mechanisms for securing bundles en route. 209 . The mechanisms for managing bundle nodes. 211 Note that implementations of the specification presented in this 212 document will not be interoperable with implementations of RFC 5050. 214 2. Conventions used in this document 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in 219 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 3. Service Description 224 3.1. Definitions 226 Bundle - A bundle is a protocol data unit of BP, so named because 227 negotiation of the parameters of a data exchange may be impractical 228 in a delay-tolerant network: it is often better practice to "bundle" 229 with a unit of application data all metadata that might be needed in 230 order to make the data immediately usable when delivered to the 231 application. Each bundle comprises a sequence of two or more 232 "blocks" of protocol data, which serve various purposes. 234 Block - A bundle protocol block is one of the protocol data 235 structures that together constitute a well-formed bundle. 237 Application Data Unit (ADU) - An application data unit is the unit 238 of data whose conveyance to the bundle's destination is the purpose 239 for the transmission of some bundle that is not a fragment (as 240 defined below). 242 Bundle payload - A bundle payload (or simply "payload") is the 243 content of the bundle's payload block. The terms "bundle content", 244 "bundle payload", and "payload" are used interchangeably in this 245 document. For a bundle that is not a fragment (as defined below), 246 the payload is an application data unit. 248 Partial payload - A partial payload is a payload that comprises 249 either the first N bytes or the last N bytes of some other payload 250 of length M, such that 0 < N < M. Note that every partial payload 251 is a payload and therefore can be further subdivided into partial 252 payloads. 254 Fragment - A fragment is a bundle whose payload block contains a 255 partial payload. 257 Bundle node - A bundle node (or, in the context of this document, 258 simply a "node") is any entity that can send and/or receive bundles. 259 Each bundle node has three conceptual components, defined below, as 260 shown in Figure 2: a "bundle protocol agent", a set of zero or more 261 "convergence layer adapters", and an "application agent". ("CL1 262 PDUs" are the PDUs of the convergence-layer protocol used in network 263 1.) 265 +-----------------------------------------------------------+ 266 |Node | 267 | | 268 | +-------------------------------------------------------+ | 269 | |Application Agent | | 270 | | | | 271 | | +--------------------------+ +----------------------+ | | 272 | | |Administrative element | |Application-specific | | | 273 | | | | |element | | | 274 | | | | | | | | 275 | | +--------------------------+ +----------------------+ | | 276 | | ^ ^ | | 277 | | Admin|records Application|data | | 278 | | | | | | 279 | +----------------v--------------------------v-----------+ | 280 | ^ | 281 | | ADUs | 282 | | | 283 | +-----------------------------v-------------------------+ | 284 | |Bundle Protocol Agent | | 285 | | | | 286 | | | | 287 | +-------------------------------------------------------+ | 288 | ^ ^ ^ | 289 | | Bundles | Bundles Bundles | | 290 | | | | | 291 | +------v-----+ +-----v------+ +-----v-----+ | 292 | |CLA 1 | |CLA 2 | |CLA n | | 293 | | | | | . . . | | | 294 | | | | | | | | 295 +-+------------+-----+------------+-----------+-----------+-+ 296 ^ ^ ^ 297 CL1|PDUs CL2|PDUs CLn|PDUs 298 | | | 299 +------v-----+ +-----v------+ +-----v-----+ 300 Network 1 Network 2 Network n 302 Figure 2: Components of a Bundle Node 304 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 305 the node component that offers the BP services and executes the 306 procedures of the bundle protocol. 308 Convergence layer adapter - A convergence layer adapter (CLA) is a 309 node component that sends and receives bundles on behalf of the BPA, 310 utilizing the services of some 'native' protocol stack that is 311 supported in one of the networks within which the node is 312 functionally located. 314 Application agent - The application agent (AA) of a node is the node 315 component that utilizes the BP services to effect communication for 316 some user purpose. The application agent in turn has two elements, 317 an administrative element and an application-specific element. 319 Application-specific element - The application-specific element of 320 an AA is the node component that constructs, requests transmission 321 of, accepts delivery of, and processes units of user application 322 data. 324 Administrative element - The administrative element of an AA is the 325 node component that constructs and requests transmission of 326 administrative records (defined below), including status reports, 327 and accepts delivery of and processes any administrative records 328 that the node receives. 330 Administrative record - A BP administrative record is an application 331 data unit that is exchanged between the administrative elements of 332 nodes' application agents for some BP administrative purpose. The 333 only administrative record defined in this specification is the 334 status report, discussed later. 336 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 337 of zero or more bundle nodes that all identify themselves for BP 338 purposes by some common identifier, called a "bundle endpoint ID" 339 (or, in this document, simply "endpoint ID"; endpoint IDs are 340 described in detail in Section 4.5.5.1 below). Note that any bundle 341 node may be a member of multiple endpoints and MUST be a member of 342 at least one singleton endpoint (as defined below), whose identifier 343 serves as a node identifier. 345 Singleton endpoint - A singleton endpoint is an endpoint that always 346 contains exactly one member. 348 Registration - A registration is the state machine characterizing a 349 given node's membership in a given endpoint. Any single 350 registration has an associated delivery failure action as defined 351 below and must at any time be in one of two states: Active or 352 Passive. Registrations are local; information about a node's 353 registrations is not expected to be available at other nodes, and 354 the Bundle Protocol does not include a mechanism for distributing 355 information about registrations. 357 Delivery - A bundle is considered to have been delivered at a node 358 subject to a registration as soon as the application data unit that 359 is the payload of the bundle, together with any relevant metadata 360 (an implementation matter), has been presented to the node's 361 application agent in a manner consistent with the state of that 362 registration. 364 Deliverability - A bundle is considered "deliverable" subject to a 365 registration if and only if (a) the bundle's destination endpoint is 366 the endpoint with which the registration is associated, (b) the 367 bundle has not yet been delivered subject to this registration, and 368 (c) the bundle has not yet been "abandoned" (as defined below) 369 subject to this registration. 371 Abandonment - To abandon a bundle subject to some registration is to 372 assert that the bundle is not deliverable subject to that 373 registration. 375 Delivery failure action - The delivery failure action of a 376 registration is the action that is to be taken when a bundle that is 377 "deliverable" subject to that registration is received at a time 378 when the registration is in the Passive state. 380 Destination - The destination of a bundle is the endpoint comprising 381 the node(s) at which the bundle is to be delivered (as defined 382 above). 384 Transmission - A transmission is an attempt by a node's BPA to cause 385 copies of a bundle to be delivered to one or more of the nodes that 386 are members of some endpoint (the bundle's destination) in response 387 to a transmission request issued by the node's application agent. 389 Forwarding - To forward a bundle to a node is to invoke the services 390 of one or more CLAs in a sustained effort to cause a copy of the 391 bundle to be received by that node. 393 Discarding - To discard a bundle is to cease all operations on the 394 bundle and functionally erase all references to it. The specific 395 procedures by which this is accomplished are an implementation 396 matter. 398 Retention constraint - A retention constraint is an element of the 399 state of a bundle that prevents the bundle from being discarded. 400 That is, a bundle cannot be discarded while it has any retention 401 constraints. 403 Deletion - To delete a bundle is to remove unconditionally all of 404 the bundle's retention constraints, enabling the bundle to be 405 discarded. 407 3.2. Discussion of BP concepts 409 Multiple instances of the same bundle (the same unit of DTN protocol 410 data) might exist concurrently in different parts of a network -- 411 possibly differing in some blocks -- in the memory local to one or 412 more bundle nodes and/or in transit between nodes. In the context of 413 the operation of a bundle node, a bundle is an instance (copy), in 414 that node's local memory, of some bundle that is in the network. 416 The payload for a bundle forwarded in response to a bundle 417 transmission request is the application data unit whose location is 418 provided as a parameter to that request. The payload for a bundle 419 forwarded in response to reception of a bundle is the payload of the 420 received bundle. 422 In the most familiar case, a bundle node is instantiated as a single 423 process running on a general-purpose computer, but in general the 424 definition is meant to be broader: a bundle node might alternatively 425 be a thread, an object in an object-oriented operating system, a 426 special-purpose hardware device, etc. 428 The manner in which the functions of the BPA are performed is wholly 429 an implementation matter. For example, BPA functionality might be 430 coded into each node individually; it might be implemented as a 431 shared library that is used in common by any number of bundle nodes 432 on a single computer; it might be implemented as a daemon whose 433 services are invoked via inter-process or network communication by 434 any number of bundle nodes on one or more computers; it might be 435 implemented in hardware. 437 Every CLA implements its own thin layer of protocol, interposed 438 between BP and the (usually "top") protocol(s) of the underlying 439 native protocol stack; this "CL protocol" may only serve to 440 multiplex and de-multiplex bundles to and from the underlying native 441 protocol, or it may offer additional CL-specific functionality. The 442 manner in which a CLA sends and receives bundles, as well as the 443 definitions of CLAs and CL protocols, are beyond the scope of this 444 specification. 446 Note that the administrative element of a node's application agent 447 may itself, in some cases, function as a convergence-layer adapter. 448 That is, outgoing bundles may be "tunneled" through encapsulating 449 bundles: 451 . An outgoing bundle constitutes a byte array. This byte array 452 may, like any other, be presented to the bundle protocol agent 453 as an application data unit that is to be transmitted to some 454 endpoint. 455 . The original bundle thus forms the payload of an encapsulating 456 bundle that is forwarded using some other convergence-layer 457 protocol(s). 458 . When the encapsulating bundle is received, its payload is 459 delivered to the peer application agent administrative element, 460 which then instructs the bundle protocol agent to dispatch that 461 original bundle in the usual way. 463 The purposes for which this technique may be useful (such as cross- 464 domain security) are beyond the scope of this specification. 466 The only interface between the BPA and the application-specific 467 element of the AA is the BP service interface. But between the BPA 468 and the administrative element of the AA there is a (conceptual) 469 private control interface in addition to the BP service interface. 470 This private control interface enables the BPA and the 471 administrative element of the AA to direct each other to take action 472 under specific circumstances. 474 In the case of a node that serves simply as a BP "router", the AA 475 may have no application-specific element at all. The application- 476 specific elements of other nodes' AAs may perform arbitrarily 477 complex application functions, perhaps even offering multiplexed DTN 478 communication services to a number of other applications. As with 479 the BPA, the manner in which the AA performs its functions is wholly 480 an implementation matter. 482 Singletons are the most familiar sort of endpoint, but in general 483 the endpoint notion is meant to be broader. For example, the nodes 484 in a sensor network might constitute a set of bundle nodes that 485 identify themselves by a single common endpoint ID and thus form a 486 single bundle endpoint. *Note* too that a given bundle node might 487 identify itself by multiple endpoint IDs and thus be a member of 488 multiple bundle endpoints. 490 The destination of every bundle is an endpoint, which may or may not 491 be singleton. The source of every bundle is a node, identified by 492 the endpoint ID for some singleton endpoint that contains that node. 493 Note, though, that the source node ID asserted in a given bundle may 494 be the null endpoint ID (as described later) rather than the 495 endpoint ID of the actual source node; bundles for which the 496 asserted source node ID is the null endpoint ID are termed 497 "anonymous" bundles. 499 Any number of transmissions may be concurrently undertaken by the 500 bundle protocol agent of a given node. 502 When the bundle protocol agent of a node determines that a bundle 503 must be forwarded to a node (either to a node that is a member of 504 the bundle's destination endpoint or to some intermediate forwarding 505 node) in the course of completing the successful transmission of 506 that bundle, the bundle protocol agent invokes the services of one 507 or more CLAs in a sustained effort to cause a copy of the bundle to 508 be received by that node. 510 Upon reception, the processing of a bundle that has been received by 511 a given node depends on whether or not the receiving node is 512 registered in the bundle's destination endpoint. If it is, and if 513 the payload of the bundle is non-fragmentary (possibly as a result 514 of successful payload reassembly from fragmentary payloads, 515 including the original payload of the newly received bundle), then 516 the bundle is normally delivered to the node's application agent 517 subject to the registration characterizing the node's membership in 518 the destination endpoint. 520 The bundle protocol does not natively ensure delivery of a bundle to 521 its destination. Data loss along the path to the destination node 522 can be minimized by utilizing reliable convergence-layer protocols 523 between neighbors on all segments of the end-to-end path, but for 524 end-to-end bundle delivery assurance it will be necessary to develop 525 extensions to the bundle protocol and/or application-layer 526 mechanisms. 528 The bundle protocol is designed for extensibility. Bundle protocol 529 extensions, documented elsewhere, may extend this specification by: 531 . defining additional blocks; 532 . defining additional administrative records; 533 . defining additional bundle processing flags; 534 . defining additional block processing flags; 535 . defining additional types of bundle status reports; 536 . defining additional bundle status report reason codes; 537 . defining additional mandates and constraints on processing 538 that conformant bundle protocol agents must perform at 539 specified points in the inbound and outbound bundle processing 540 cycles. 542 3.3. Services Offered by Bundle Protocol Agents 544 The BPA of each node is expected to provide the following services 545 to the node's application agent: 547 . commencing a registration (registering the node in an 548 endpoint); 549 . terminating a registration; 550 . switching a registration between Active and Passive states; 551 . transmitting a bundle to an identified bundle endpoint; 552 . canceling a transmission; 553 . polling a registration that is in the Passive state; 554 . delivering a received bundle. 556 Note that the details of registration functionality are an 557 implementation matter and are beyond the scope of this 558 specification. 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 payload block SHALL be followed by a CBOR 574 "break" stop code, terminating the array. 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 Bundle processing control flags that are unrecognized MUST be 665 ignored, as future definitions of additional flags might not be 666 integrated simultaneously into the Bundle Protocol implementations 667 operating at all nodes. 669 The bundle processing control flags SHALL be represented as a CBOR 670 unsigned integer item, the value of which SHALL be processed as a 671 bit field indicating the control flag values as follows (note that 672 bit numbering in this instance is reversed from the usual practice, 673 beginning with the low-order bit instead of the high-order bit, in 674 recognition of the potential definition of additional control flag 675 values in the future): 677 . Bit 0 (the low-order bit, 0x000001): bundle is a fragment. 678 . Bit 1 (0x000002): payload is an administrative record. 679 . Bit 2 (0x000004): bundle must not be fragmented. 680 . Bit 3 (0x000008): reserved. 681 . Bit 4 (0x000010): reserved. 682 . Bit 5 (0x000020): user application acknowledgement is 683 requested. 684 . Bit 6 (0x000040): status time is requested in all status 685 reports. 686 . Bit 7 (0x000080): reserved. 687 . Bit 8 (0x000100): reserved. 688 . Bit 9 (0x000200): reserved. 689 . Bit 10(0x000400): reserved. 690 . Bit 11(0x000800): reserved. 691 . Bit 12(0x001000): reserved. 692 . Bit 13(0x002000): reserved. 693 . Bit 14(0x004000): bundle reception status reports are 694 requested. 695 . Bit 15(0x008000): reserved. 696 . Bit 16(0x010000): bundle forwarding status reports are 697 requested. 698 . Bit 17(0x020000): bundle delivery status reports are requested. 700 . Bit 18(0x040000): bundle deletion status reports are requested. 701 . Bits 19-20 are reserved. 702 . Bits 21-63 are unassigned. 704 4.1.4. Block Processing Control Flags 706 The block processing control flags assert properties of canonical 707 bundle blocks. They are conveyed in the header of the block to 708 which they pertain. 710 Block processing control flags that are unrecognized MUST be 711 ignored, as future definitions of additional flags might not be 712 integrated simultaneously into the Bundle Protocol implementations 713 operating at all nodes. 715 The block processing control flags SHALL be represented as a CBOR 716 unsigned integer item, the value of which SHALL be processed as a 717 bit field indicating the control flag values as follows (note that 718 bit numbering in this instance is reversed from the usual practice, 719 beginning with the low-order bit instead of the high-order bit, for 720 agreement with the bit numbering of the bundle processing control 721 flags): 723 . Bit 0(the low-order bit, 0x01): block must be replicated in 724 every fragment. 725 . Bit 1(0x02): transmission of a status report is requested if 726 block can't be processed. 727 . Bit 2(0x04): bundle must be deleted if block can't be 728 processed. 729 . Bit 3(0x08): reserved. 730 . Bit 4(0x10): block must be removed from bundle if it can't be 731 processed. 732 . Bit 5(0x20): reserved. 733 . Bit 6 (0x40): reserved. 734 . Bits 7-63 are unassigned. 736 For each bundle whose bundle processing control flags indicate that 737 the bundle's application data unit is an administrative record, or 738 whose source node ID is the null endpoint ID as defined below, the 739 value of the "Transmit status report if block can't be processed" 740 flag in every canonical block of the bundle MUST be zero. 742 4.1.5. Identifiers 744 4.1.5.1. Endpoint ID 746 The destinations of bundles are bundle endpoints, identified by text 747 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 748 (EID) is a Uniform Resource Identifier (URI; [URI]). As such, each 749 endpoint ID can be characterized as having this general structure: 751 < scheme name > : < scheme-specific part, or "SSP" > 753 The scheme identified by the < scheme name > in an endpoint ID is a 754 set of syntactic and semantic rules that fully explain how to parse 755 and interpret the SSP. Each scheme that may be used to form a BP 756 endpoint ID must be added to the registry of URI scheme code numbers 757 for Bundle Protocol maintained by IANA as described in Section 10; 758 association of a unique URI scheme code number with each scheme name 759 in this registry helps to enable compact representation of endpoint 760 IDs in bundle blocks. Note that the set of allowable schemes is 761 effectively unlimited. Any scheme conforming to [URIREG] may be 762 added to the URI scheme code number registry and thereupon used in a 763 bundle protocol endpoint ID. 765 Each entry in the URI scheme code number registry MUST contain a 766 reference to a scheme code number definition document, which defines 767 the manner in which the scheme-specific part of any URI formed in 768 that scheme is parsed and interpreted and MUST be encoded, in CBOR 769 representation, for transmission as a BP endpoint ID. The scheme 770 code number definition document may also contain information as to 771 (a) which convergence-layer protocol(s) may be used to forward a 772 bundle to a BP destination endpoint identified by such an ID, and 773 (b) how the ID of the convergence-layer protocol endpoint to use for 774 that purpose can be inferred from that destination endpoint ID. 776 Note that, although endpoint IDs are URIs, implementations of the BP 777 service interface may support expression of endpoint IDs in some 778 internationalized manner (e.g., Internationalized Resource 779 Identifiers (IRIs); see [RFC3987]). 781 Each BP endpoint ID (EID) SHALL be represented as a CBOR array 782 comprising two items. 784 The first item of the array SHALL be the code number identifying the 785 endpoint ID's URI scheme, as defined in the registry of URI scheme 786 code numbers for Bundle Protocol. Each URI scheme code number SHALL 787 be represented as a CBOR unsigned integer. 789 The second item of the array SHALL be the applicable CBOR 790 representation of the scheme-specific part (SSP) of the EID, defined 791 as noted in the specification for the EID's URI scheme. 793 4.1.5.1.1. The "dtn" URI scheme 795 The "dtn" scheme supports the identification of BP endpoints by 796 arbitrarily expressive character strings. It is specified as 797 follows: 799 Scheme syntax: This specification uses the Augmented Backus-Naur 800 Form (ABNF) notation of [RFC5234]. 802 dtn-uri = "dtn:" dtn-hier-part 804 dtn-hier-part = "//" node-name name-delim demux ; a path-rootless 806 node-name = 1*VCHAR 808 name-delim = "/" 810 demux = *VCHAR 812 Scheme semantics: URIs of the DTN scheme are used as endpoint 813 identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol 814 (BP) as described in the present document. 816 The endpoint ID "dtn:none" identifies the "null endpoint", the 817 endpoint that by definition never has any members. 819 Encoding considerations: For transmission as a BP endpoint ID, the 820 scheme-specific part of a URI of the dtn scheme SHALL be represented 821 as a CBOR text string unless the EID's SSP is "none", in which case 822 the SSP SHALL be represented as a CBOR unsigned integer with the 823 value zero. For all other purposes, URIs of the dtn scheme are 824 encoded exclusively in US-ASCII characters. 826 Interoperability considerations: none. 828 Security considerations: 830 . Reliability and consistency: none of the BP endpoints 831 identified by the URIs of the DTN scheme are guaranteed to be 832 reachable at any time, and the identity of the processing 833 entities operating on those endpoints is never guaranteed by 834 the Bundle Protocol itself. Bundle authentication as defined by 835 the Bundle Security Protocol is required for this purpose. 837 . Malicious construction: malicious construction of a conformant 838 DTN-scheme URI is limited to the malicious selection of node 839 names and the malicious selection of demux strings. That is, a 840 maliciously constructed DTN-scheme URI could be used to direct 841 a bundle to an endpoint that might be damaged by the arrival of 842 that bundle or, alternatively, to declare a false source for a 843 bundle and thereby cause incorrect processing at a node that 844 receives the bundle. In both cases (and indeed in all bundle 845 processing), the node that receives a bundle should verify its 846 authenticity and validity before operating on it in any way. 847 . Back-end transcoding: the limited expressiveness of URIs of the 848 DTN scheme effectively eliminates the possibility of threat due 849 to errors in back-end transcoding. 850 . Rare IP address formats: not relevant, as IP addresses do not 851 appear anywhere in conformant DTN-scheme URIs. 852 . Sensitive information: because DTN-scheme URIs are used only to 853 represent the identities of Bundle Protocol endpoints, the risk 854 of disclosure of sensitive information due to interception of 855 these URIs is minimal. Examination of DTN-scheme URIs could be 856 used to support traffic analysis; where traffic analysis is a 857 plausible danger, bundles should be conveyed by secure 858 convergence-layer protocols that do not expose endpoint IDs. 859 . Semantic attacks: the simplicity of DTN-scheme URI syntax 860 minimizes the possibility of misinterpretation of a URI by a 861 human user. 863 4.1.5.1.2. The "ipn" URI scheme 865 The "ipn" scheme supports the identification of BP endpoints by 866 pairs of unsigned integers, for compact representation in bundle 867 blocks. It is specified as follows: 869 Scheme syntax: This specification uses the Augmented Backus-Naur 870 Form (ABNF) notation of [RFC5234], including the core ABNF syntax 871 rule for DIGIT defined by that specification. 873 ipn-uri = "ipn:" ipn-hier-part 875 ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless 877 node-nbr = 1*DIGIT 879 nbr-delim = "." 881 service-nbr = 1*DIGIT 882 Scheme semantics: URIs of the ipn scheme are used as endpoint 883 identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol 884 (BP) as described in the present document. 886 All BP endpoints identified by URIs formed in the ipn scheme are 887 singleton endpoints. 889 Encoding considerations: For transmission as a BP endpoint ID, the 890 scheme-specific part of a URI of the dtn scheme the SSP SHALL be 891 represented as a CBOR array comprising two items. The first item of 892 this array SHALL be the EID's node number (a number that identifies 893 the node) represented as a CBOR unsigned integer. The second item 894 of this array SHALL be the EID's service number (a number that 895 identifies some application service) represented as a CBOR unsigned 896 integer. For all other purposes, URIs of the IPN scheme are encoded 897 exclusively in US-ASCII characters. 899 Interoperability considerations: none. 901 Security considerations: 903 . Reliability and consistency: none of the BP endpoints 904 identified by the URIs of the IPN scheme are guaranteed to be 905 reachable at any time, and the identity of the processing 906 entities operating on those endpoints is never guaranteed by 907 the Bundle Protocol itself. Bundle authentication as defined by 908 the Bundle Security Protocol [BPSEC] is required for this 909 purpose. 910 . Malicious construction: malicious construction of a conformant 911 IPN-scheme URI is limited to the malicious selection of node 912 numbers and the malicious selection of service numbers. That 913 is, a maliciously constructed IPN-scheme URI could be used to 914 direct a bundle to an endpoint that might be damaged by the 915 arrival of that bundle or, alternatively, to declare a false 916 source for a bundle and thereby cause incorrect processing at a 917 node that receives the bundle. In both cases (and indeed in 918 all bundle processing), the node that receives a bundle should 919 verify its authenticity and validity before operating on it in 920 any way. 921 . Back-end transcoding: the limited expressiveness of URIs of the 922 IPN scheme effectively eliminates the possibility of threat due 923 to errors in back-end transcoding. 924 . Rare IP address formats: not relevant, as IP addresses do not 925 appear anywhere in conformant IPN-scheme URIs. 926 . Sensitive information: because IPN-scheme URIs are used only to 927 represent the identities of Bundle Protocol endpoints, the risk 928 of disclosure of sensitive information due to interception of 929 these URIs is minimal. Examination of IPN-scheme URIs could be 930 used to support traffic analysis; where traffic analysis is a 931 plausible danger, bundles should be conveyed by secure 932 convergence-layer protocols that do not expose endpoint IDs. 933 . Semantic attacks: the simplicity of IPN-scheme URI syntax 934 minimizes the possibility of misinterpretation of a URI by a 935 human user. 937 4.1.5.2. Node ID 939 For many purposes of the Bundle Protocol it is important to identify 940 the node that is operative in some context. 942 As discussed in 3.1 above, nodes are distinct from endpoints; 943 specifically, an endpoint is a set of zero or more nodes. But 944 rather than define a separate namespace for node identifiers, we 945 instead use endpoint identifiers to identify nodes, subject to the 946 following restrictions: 948 . As noted in 3.1 above, every node MUST be a member of at least 949 one singleton endpoint. 950 . The EID of any singleton endpoint of which a node is a member 951 MAY be used to identify that node. A "node ID" is an EID that 952 is used in this way. 953 . A node's membership in a given singleton endpoint MUST be 954 sustained at least until the nominal operation of the Bundle 955 Protocol no longer depends on the identification of that node 956 using that endpoint's ID. 958 4.1.6. DTN Time 960 A DTN time is an unsigned integer indicating the number of seconds 961 that have elapsed since the start of the year 2000 on the 962 Coordinated Universal Time (UTC) scale [UTC]. Each DTN time SHALL 963 be represented as a CBOR unsigned integer item. 965 Implementers need to be aware that DTN time values conveyed in CBOR 966 representation in bundles can conceivably exceed (2**32 - 1). 968 4.1.7. Creation Timestamp 970 Each bundle's creation timestamp SHALL be represented as a CBOR 971 array comprising two items. 973 The first item of the array, termed "bundle creation time", SHALL be 974 the DTN time at which the transmission request was received that 975 resulted in the creation of the bundle, represented as a CBOR 976 unsigned integer. 978 The second item of the array, termed the creation timestamp's 979 "sequence number", SHALL be the latest value (as of the time at 980 which the transmission request was received) of a monotonically 981 increasing positive integer counter managed by the source node's 982 bundle protocol agent, represented as a CBOR unsigned integer. The 983 sequence counter MAY be reset to zero whenever the current time 984 advances by one second. 986 For nodes that lack accurate clocks, it is recommended that bundle 987 creation time be set to zero and that the counter used as the source 988 of the bundle sequence count never be reset to zero. 990 Note that, in general, the creation of two distinct bundles with the 991 same source node ID and bundle creation timestamp may result in 992 unexpected network behavior and/or suboptimal performance. The 993 combination of source node ID and bundle creation timestamp serves 994 to identify a single transmission request, enabling it to be 995 acknowledged by the receiving application (provided the source node 996 ID is not the null endpoint ID). 998 4.1.8. Block-type-specific Data 1000 Block-type-specific data in each block (other than the primary 1001 block) SHALL be the applicable CBOR representation of the content of 1002 the block. Details of this representation are included in the 1003 specification defining the block type. 1005 4.2. Bundle Representation 1007 This section describes the primary block in detail and non-primary 1008 blocks in general. Rules for processing these blocks appear in 1009 Section 5 of this document. 1011 Note that supplementary DTN protocol specifications (including, but 1012 not restricted to, the Bundle Security Protocol [BPSEC]) may require 1013 that BP implementations conforming to those protocols construct and 1014 process additional blocks. 1016 4.2.1. Bundle 1018 Each bundle SHALL be represented as a CBOR indefinite-length array. 1019 The first item of this array SHALL be the CBOR representation of a 1020 Primary Block. Every other item of the array SHALL be the CBOR 1021 representation of a Canonical Block. The last block of the bundle 1022 SHALL be followed by a CBOR "break" stop code, terminating the 1023 array. 1025 Associated with each block of a bundle is a block number. The block 1026 number uniquely identifies the block within the bundle, enabling 1027 blocks (notably bundle security protocol blocks) to reference other 1028 blocks in the same bundle without ambiguity. The block number of 1029 the primary block is implicitly zero; the block numbers of all other 1030 blocks are explicitly stated in block headers as noted below. Block 1031 numbering is unrelated to the order in which blocks are sequenced in 1032 the bundle. The block number of the payload block is always 1. 1034 4.2.2. Primary Bundle Block 1036 The primary bundle block contains the basic information needed to 1037 forward bundles to their destinations. 1039 Each primary block SHALL be represented as a CBOR array; the number 1040 of elements in the array SHALL be 8 (if the bundle is not a fragment 1041 and the block has no CRC), 9 (if the block has a CRC and the bundle 1042 is not a fragment), 10 (if the bundle is a fragment and the block 1043 has no CRC), or 11 (if the bundle is a fragment and the block has a 1044 CRC). 1046 The primary block of each bundle SHALL be immutable. The values of 1047 all fields in the primary block must remain unchanged from the time 1048 the block is created to the time it is delivered. 1050 The fields of the primary bundle block SHALL be as follows, listed 1051 in the order in which they MUST appear: 1053 Version: An unsigned integer value indicating the version of the 1054 bundle protocol that constructed this block. The present document 1055 describes version 7 of the bundle protocol. Version number SHALL be 1056 represented as a CBOR unsigned integer item. 1058 Bundle Processing Control Flags: The Bundle Processing Control Flags 1059 are discussed in Section 4.1.3. above. 1061 CRC Type: CRC Type codes are discussed in Section 4.1.1. above. The 1062 CRC Type code for the primary block MAY be zero if the bundle 1063 contains a BPsec [BPSEC] Block Integrity Block whose target is the 1064 primary block; otherwise the CRC Type code for the primary block 1065 MUST be non-zero. 1067 Destination EID: The Destination EID field identifies the bundle 1068 endpoint that is the bundle's destination, i.e., the endpoint that 1069 contains the node(s) at which the bundle is to be delivered. 1071 Source node ID: The Source node ID field identifies the bundle node 1072 at which the bundle was initially transmitted, except that Source 1073 node ID may be the null endpoint ID in the event that the bundle's 1074 source chooses to remain anonymous. 1076 Report-to EID: The Report-to EID field identifies the bundle 1077 endpoint to which status reports pertaining to the forwarding and 1078 delivery of this bundle are to be transmitted. 1080 Creation Timestamp: The creation timestamp (discussed in 4.1.7 1081 above) comprises two unsigned integers that, together with the 1082 source node ID and (if the bundle is a fragment) the fragment offset 1083 and payload length, serve to identify the bundle. The first of these 1084 integers is the bundle's creation time, while the second is the 1085 bundle's creation timestamp sequence number. Bundle creation time 1086 SHALL be the DTN time at which the transmission request was received 1087 that resulted in the creation of the bundle. Sequence count SHALL be 1088 the latest value (as of the time at which that transmission request 1089 was received) of a monotonically increasing positive integer counter 1090 managed by the source node's bundle protocol agent that MAY be reset 1091 to zero whenever the current time advances by one second. For nodes 1092 that lack accurate clocks, it is recommended that bundle creation 1093 time be set to zero and that the counter used as the source of the 1094 bundle sequence count never be reset to zero. Note that, in general, 1095 the creation of two distinct bundles with the same source node ID 1096 and bundle creation timestamp may result in unexpected network 1097 behavior and/or suboptimal performance. The combination of source 1098 node ID and bundle creation timestamp serves to identify a single 1099 transmission request, enabling it to be acknowledged by the 1100 receiving application (provided the source node ID is not the null 1101 endpoint ID). 1103 Lifetime: The lifetime field is an unsigned integer that indicates 1104 the time at which the bundle's payload will no longer be useful, 1105 encoded as a number of microseconds past the creation time. (For 1106 high-rate deployments with very brief disruptions, fine-grained 1107 expression of bundle lifetime may be useful.) When a bundle's age 1108 exceeds its lifetime, bundle nodes need no longer retain or forward 1109 the bundle; the bundle SHOULD be deleted from the network. 1111 If the asserted lifetime for a received bundle is so lengthy that 1112 retention of the bundle until its expiration time might degrade 1113 operation of the node, the bundle protocol agent of the node at 1114 which the bundle is received MAY impose a temporary overriding 1115 lifetime of shorter duration; such override lifetime SHALL NOT 1116 replace the lifetime asserted in the bundle but SHALL serve as the 1117 bundle's effective lifetime while the bundle resides at that node. 1118 Procedures for imposing lifetime overrides are beyond the scope of 1119 this specification. 1121 For bundles originating at nodes that lack accurate clocks, it is 1122 recommended that bundle age be obtained from the Bundle Age 1123 extension block (see 4.3.2 below) rather than from the difference 1124 between current time and bundle creation time. Bundle lifetime 1125 SHALL be represented as a CBOR unsigned integer item. 1127 Fragment offset: If and only if the Bundle Processing Control Flags 1128 of this Primary block indicate that the bundle is a fragment, 1129 fragment offset SHALL be present in the primary block. Fragment 1130 offset SHALL be represented as a CBOR unsigned integer indicating 1131 the offset from the start of the original application data unit at 1132 which the bytes comprising the payload of this bundle were located. 1134 Total Application Data Unit Length: If and only if the Bundle 1135 Processing Control Flags of this Primary block indicate that the 1136 bundle is a fragment, total application data unit length SHALL be 1137 present in the primary block. Total application data unit length 1138 SHALL be represented as a CBOR unsigned integer indicating the total 1139 length of the original application data unit of which this bundle's 1140 payload is a part. 1142 CRC: A CRC SHALL be present in the primary block unless the bundle 1143 includes a BPsec [BPSEC] Block Integrity Block whose target is the 1144 primary block, in which case a CRC MAY be present in the primary 1145 block. The length and nature of the CRC SHALL be as indicated by 1146 the CRC type. The CRC SHALL be computed over the concatenation of 1147 all bytes (including CBOR "break" characters) of the primary block 1148 including the CRC field itself, which for this purpose SHALL be 1149 temporarily populated with all bytes set to zero. 1151 4.2.3. Canonical Bundle Block Format 1153 Every block other than the primary block (all such blocks are termed 1154 "canonical" blocks) SHALL be represented as a CBOR array; the number 1155 of elements in the array SHALL be 5 (if CRC type is zero) or 6 1156 (otherwise). 1158 The fields of every canonical block SHALL be as follows, listed in 1159 the order in which they MUST appear: 1161 . Block type code, an unsigned integer. Bundle block type code 1 1162 indicates that the block is a bundle payload block. Block type 1163 codes 2 through 9 are explicitly reserved as noted later in 1164 this specification. Block type codes 192 through 255 are not 1165 reserved and are available for private and/or experimental use. 1166 All other block type code values are reserved for future use. 1167 . Block number, an unsigned integer as discussed in 4.2.1 above. 1168 Block number SHALL be represented as a CBOR unsigned integer. 1169 . Block processing control flags as discussed in Section 4.1.4 1170 above. 1171 . CRC type as discussed in Section 4.1.1 above. 1172 . Block-type-specific data represented as a single definite- 1173 length CBOR byte string, i.e., a CBOR byte string that is not 1174 of indefinite length. For each type of block, the block-type- 1175 specific data byte string is the serialization, in a block- 1176 type-specific manner, of the data conveyed by that type of 1177 block; definitions of blocks are required to define the manner 1178 in which block-type-specific data are serialized within the 1179 block-type-specific data field. For the Payload Block in 1180 particular (block type 1), the block-type-specific data field, 1181 termed the "payload", SHALL be an application data unit, or 1182 some contiguous extent thereof, represented as a definite- 1183 length CBOR byte string. 1184 . If and only if the value of the CRC type field of this block is 1185 non-zero, a CRC. If present, the length and nature of the CRC 1186 SHALL be as indicated by the CRC type and the CRC SHALL be 1187 computed over the concatenation of all bytes of the block 1188 (including CBOR "break" characters) including the CRC field 1189 itself, which for this purpose SHALL be temporarily populated 1190 with all bytes set to zero. 1192 4.3. Extension Blocks 1194 "Extension blocks" are all blocks other than the primary and payload 1195 blocks. Because not all extension blocks are defined in the Bundle 1196 Protocol specification (the present document), not all nodes 1197 conforming to this specification will necessarily instantiate Bundle 1198 Protocol implementations that include procedures for processing 1199 (that is, recognizing, parsing, acting on, and/or producing) all 1200 extension blocks. It is therefore possible for a node to receive a 1201 bundle that includes extension blocks that the node cannot process. 1202 The values of the block processing control flags indicate the action 1203 to be taken by the bundle protocol agent when this is the case. 1205 The following extension blocks are defined in the current document. 1207 4.3.1. Previous Node 1209 The Previous Node block, block type 6, identifies the node that 1210 forwarded this bundle to the local node (i.e., to the node at which 1211 the bundle currently resides); its block-type-specific data is the 1212 node ID of that forwarder node which SHALL take the form of a node 1213 ID represented as described in Section 4.1.5.1.1. above. If the 1214 local node is the source of the bundle, then the bundle MUST NOT 1215 contain any Previous Node block. Otherwise the bundle SHOULD 1216 contain one (1) occurrence of this type of block and MUST NOT 1217 contain more than one. 1219 4.3.2. Bundle Age 1221 The Bundle Age block, block type 7, contains the number of 1222 microseconds that have elapsed between the time the bundle was 1223 created and time at which it was most recently forwarded. It is 1224 intended for use by nodes lacking access to an accurate clock, to 1225 aid in determining the time at which a bundle's lifetime expires. 1226 The block-type-specific data of this block is an unsigned integer 1227 containing the age of the bundle in microseconds, which SHALL be 1228 represented as a CBOR unsigned integer item. (The age of the bundle 1229 is the sum of all known intervals of the bundle's residence at 1230 forwarding nodes, up to the time at which the bundle was most 1231 recently forwarded, plus the summation of signal propagation time 1232 over all episodes of transmission between forwarding nodes. 1233 Determination of these values is an implementation matter.) If the 1234 bundle's creation time is zero, then the bundle MUST contain exactly 1235 one (1) occurrence of this type of block; otherwise, the bundle MAY 1236 contain at most one (1) occurrence of this type of block. A bundle 1237 MUST NOT contain multiple occurrences of the bundle age block, as 1238 this could result in processing anomalies. 1240 4.3.3. Hop Count 1242 The Hop Count block, block type 10, contains two unsigned integers, 1243 hop limit and hop count. A "hop" is here defined as an occasion on 1244 which a bundle was forwarded from one node to another node. Hop 1245 limit MUST be in the range 1 through 255. The hop limit value SHOULD 1246 NOT be changed at any time after creation of the Hop Count block; 1247 the hop count value SHOULD initially be zero and SHOULD be increased 1248 by 1 on each hop. 1250 The hop count block is mainly intended as a safety mechanism, a 1251 means of identifying bundles for removal from the network that can 1252 never be delivered due to a persistent forwarding error. Hop count 1253 is particularly valuable as a defense against routing anomalies that 1254 might cause a bundle to be forwarded in a cyclical "ping-pong" 1255 fashion between two nodes. When a bundle's hop count exceeds its 1256 hop limit, the bundle SHOULD be deleted for the reason "hop limit 1257 exceeded", following the bundle deletion procedure defined in 1258 Section 5.10. 1260 Procedures for determining the appropriate hop limit for a bundle 1261 are beyond the scope of this specification. 1263 The block-type-specific data in a hop count block SHALL be 1264 represented as a CBOR array comprising two items. The first item of 1265 this array SHALL be the bundle's hop limit, represented as a CBOR 1266 unsigned integer. The second item of this array SHALL be the 1267 bundle's hop count, represented as a CBOR unsigned integer. A bundle 1268 MAY contain one occurrence of this type of block but MUST NOT 1269 contain more than one. 1271 5. Bundle Processing 1273 The bundle processing procedures mandated in this section and in 1274 Section 6 govern the operation of the Bundle Protocol Agent and the 1275 Application Agent administrative element of each bundle node. They 1276 are neither exhaustive nor exclusive. Supplementary DTN protocol 1277 specifications (including, but not restricted to, the Bundle 1278 Security Protocol [BPSEC]) may augment, override, or supersede the 1279 mandates of this document. 1281 5.1. Generation of Administrative Records 1283 All transmission of bundles is in response to bundle transmission 1284 requests presented by nodes' application agents. When required to 1285 "generate" an administrative record (such as a bundle status 1286 report), the bundle protocol agent itself is responsible for causing 1287 a new bundle to be transmitted, conveying that record. In concept, 1288 the bundle protocol agent discharges this responsibility by 1289 directing the administrative element of the node's application agent 1290 to construct the record and request its transmission as detailed in 1291 Section 6 below. In practice, the manner in which administrative 1292 record generation is accomplished is an implementation matter, 1293 provided the constraints noted in Section 6 are observed. 1295 Status reports are relatively small bundles. Moreover, even when 1296 the generation of status reports is enabled the decision on whether 1297 or not to generate a requested status report is left to the 1298 discretion of the bundle protocol agent. Nonetheless, note that 1299 requesting status reports for any single bundle might easily result 1300 in the generation of (1 + (2 *(N-1))) status report bundles, where N 1301 is the number of nodes on the path from the bundle's source to its 1302 destination, inclusive. That is, the requesting of status reports 1303 for large numbers of bundles could result in an unacceptable 1304 increase in the bundle traffic in the network. For this reason, the 1305 generation of status reports MUST be disabled by default and enabled 1306 only when the risk of excessive network traffic is deemed 1307 acceptable. Mechanisms that could assist in assessing and 1308 mitigating this risk, such as pre-placed agreements authorizing the 1309 generation of status reports under specified circumstances, are 1310 beyond the scope of this specification. 1312 Notes on administrative record terminology: 1314 . A "bundle reception status report" is a bundle status report 1315 with the "reporting node received bundle" flag set to 1. 1316 . A "bundle forwarding status report" is a bundle status report 1317 with the "reporting node forwarded the bundle" flag set to 1. 1318 . A "bundle delivery status report" is a bundle status report 1319 with the "reporting node delivered the bundle" flag set to 1. 1320 . A "bundle deletion status report" is a bundle status report 1321 with the "reporting node deleted the bundle" flag set to 1. 1323 5.2. Bundle Transmission 1325 The steps in processing a bundle transmission request are: 1327 Step 1: Transmission of the bundle is initiated. An outbound bundle 1328 MUST be created per the parameters of the bundle transmission 1329 request, with the retention constraint "Dispatch pending". The 1330 source node ID of the bundle MUST be either the null endpoint ID, 1331 indicating that the source of the bundle is anonymous, or else the 1332 EID of a singleton endpoint whose only member is the node of which 1333 the BPA is a component. 1335 Step 2: Processing proceeds from Step 1 of Section 5.4. 1337 5.3. Bundle Dispatching 1339 The steps in dispatching a bundle are: 1341 Step 1: If the bundle's destination endpoint is an endpoint of which 1342 the node is a member, the bundle delivery procedure defined in 1343 Section 5.7 MUST be followed and for the purposes of all subsequent 1344 processing of this bundle at this node the node's membership in the 1345 bundle's destination endpoint SHALL be disavowed; specifically, even 1346 though the node is a member of the bundle's destination endpoint, 1347 the node SHALL NOT undertake to forward the bundle to itself in the 1348 course of performing the procedure described in Section 5.4. 1350 Step 2: Processing proceeds from Step 1 of Section 5.4. 1352 5.4. Bundle Forwarding 1354 The steps in forwarding a bundle are: 1356 Step 1: The retention constraint "Forward pending" MUST be added to 1357 the bundle, and the bundle's "Dispatch pending" retention constraint 1358 MUST be removed. 1360 Step 2: The bundle protocol agent MUST determine whether or not 1361 forwarding is contraindicated (that is, rendered inadvisable) for 1362 any of the reasons listed in the IANA registry of Bundle Status 1363 Report Reason Codes (see section 10.5 below), whose initial contents 1364 are listed in Figure 4. In particular: 1366 . The bundle protocol agent MAY choose either to forward the 1367 bundle directly to its destination node(s) (if possible) or to 1368 forward the bundle to some other node(s) for further 1369 forwarding. The manner in which this decision is made may 1370 depend on the scheme name in the destination endpoint ID and/or 1371 on other state but in any case is beyond the scope of this 1372 document; one possible mechanism is described in [SABR]. If the 1373 BPA elects to forward the bundle to some other node(s) for 1374 further forwarding but finds it impossible to select any 1375 node(s) to forward the bundle to, then forwarding is 1376 contraindicated. 1377 . Provided the bundle protocol agent succeeded in selecting the 1378 node(s) to forward the bundle to, the bundle protocol agent 1379 MUST subsequently select the convergence layer adapter(s) whose 1380 services will enable the node to send the bundle to those 1381 nodes. The manner in which specific appropriate convergence 1382 layer adapters are selected is beyond the scope of this 1383 document; the TCP convergence-layer adapter [TCPCL] MUST be 1384 implemented but may not be appropriate for the forwarding of 1385 any particular bundle. If the agent finds it impossible to 1386 select any appropriate convergence layer adapter(s) to use in 1387 forwarding this bundle, then forwarding is contraindicated. 1389 Step 3: If forwarding of the bundle is determined to be 1390 contraindicated for any of the reasons listed in the IANA registry 1391 of Bundle Status Report Reason Codes (see section 10.5 below), then 1392 the Forwarding Contraindicated procedure defined in Section 5.4.1 1393 MUST be followed; the remaining steps of Section 5.4 are skipped at 1394 this time. 1396 Step 4: For each node selected for forwarding, the bundle protocol 1397 agent MUST invoke the services of the selected convergence layer 1398 adapter(s) in order to effect the sending of the bundle to that 1399 node. Determining the time at which the bundle protocol agent 1400 invokes convergence layer adapter services is a BPA implementation 1401 matter. Determining the time at which each convergence layer 1402 adapter subsequently responds to this service invocation by sending 1403 the bundle is a convergence-layer adapter implementation matter. 1404 Note that: 1406 . If the bundle has a Previous Node block, as defined in 4.3.1 1407 above, then that block MUST be removed from the bundle before 1408 the bundle is forwarded. 1409 . If the bundle protocol agent is configured to attach Previous 1410 Node blocks to forwarded bundles, then a Previous Node block 1411 containing the node ID of the forwarding node MUST be inserted 1412 into the bundle before the bundle is forwarded. 1413 . If the bundle has a bundle age block, as defined in 4.3.2. 1414 above, then at the last possible moment before the CLA 1415 initiates conveyance of the bundle via the CL protocol the 1416 bundle age value MUST be increased by the difference between 1417 the current time and the time at which the bundle was received 1418 (or, if the local node is the source of the bundle, created). 1420 Step 5: When all selected convergence layer adapters have informed 1421 the bundle protocol agent that they have concluded their data 1422 sending procedures with regard to this bundle, processing may depend 1423 on the results of those procedures. 1425 If completion of the data sending procedures by all selected 1426 convergence layer adapters has not resulted in successful forwarding 1427 of the bundle (an implementation-specific determination that is 1428 beyond the scope of this specification), then the bundle protocol 1429 agent MAY choose (in an implementation-specific manner, again beyond 1430 the scope of this specification) to initiate another attempt to 1431 forward the bundle. In that event, processing proceeds from Step 4 1432 of Section 5.4. The minimum number of times a given node will 1433 initiate another forwarding attempt for any single bundle in this 1434 event (a number which may be zero) is a node configuration parameter 1435 that MUST be exposed to other nodes in the network to the extent 1436 that this is required by the operating environment. 1438 If completion of the data sending procedures by all selected 1439 convergence layer adapters HAS resulted in successful forwarding of 1440 the bundle, or if it has not but the bundle protocol agent does not 1441 choose to initiate another attempt to forward the bundle, then: 1443 . If the "request reporting of bundle forwarding" flag in the 1444 bundle's status report request field is set to 1, and status 1445 reporting is enabled, then a bundle forwarding status report 1446 SHOULD be generated, destined for the bundle's report-to 1447 endpoint ID. The reason code on this bundle forwarding status 1448 report MUST be "no additional information". 1449 . If any applicable bundle protocol extensions mandate generation 1450 of status reports upon conclusion of convergence-layer data 1451 sending procedures, all such status reports SHOULD be generated 1452 with extension-mandated reason codes. 1453 . The bundle's "Forward pending" retention constraint MUST be 1454 removed. 1456 5.4.1. Forwarding Contraindicated 1458 The steps in responding to contraindication of forwarding are: 1460 Step 1: The bundle protocol agent MUST determine whether or not to 1461 declare failure in forwarding the bundle. Note: this decision is 1462 likely to be influenced by the reason for which forwarding is 1463 contraindicated. 1465 Step 2: If forwarding failure is declared, then the Forwarding 1466 Failed procedure defined in Section 5.4.2 MUST be followed. 1468 Otherwise, when - at some future time - the forwarding of this 1469 bundle ceases to be contraindicated, processing proceeds from Step 4 1470 of Section 5.4. 1472 5.4.2. Forwarding Failed 1474 The steps in responding to a declaration of forwarding failure are: 1476 Step 1: The bundle protocol agent MAY forward the bundle back to the 1477 node that sent it, as identified by the Previous Node block, if 1478 present. This forwarding, if performed, SHALL be accomplished by 1479 performing Step 4 and Step 5 of section 5.4 where the sole node 1480 selected for forwarding SHALL be the node that sent the bundle. 1482 Step 2: If the bundle's destination endpoint is an endpoint of which 1483 the node is a member, then the bundle's "Forward pending" retention 1484 constraint MUST be removed. Otherwise, the bundle MUST be deleted: 1485 the bundle deletion procedure defined in Section 5.10 MUST be 1486 followed, citing the reason for which forwarding was determined to 1487 be contraindicated. 1489 5.5. Bundle Expiration 1491 A bundle expires when the bundle's age exceeds its lifetime as 1492 specified in the primary bundle block. Bundle age MAY be determined 1493 by subtracting the bundle's creation timestamp time from the current 1494 time if (a) that timestamp time is not zero and (b) the local node's 1495 clock is known to be accurate; otherwise bundle age MUST be obtained 1496 from the Bundle Age extension block. Bundle expiration MAY occur at 1497 any point in the processing of a bundle. When a bundle expires, the 1498 bundle protocol agent MUST delete the bundle for the reason 1499 "lifetime expired": the bundle deletion procedure defined in Section 1500 5.10 MUST be followed. 1502 5.6. Bundle Reception 1504 The steps in processing a bundle that has been received from another 1505 node are: 1507 Step 1: The retention constraint "Dispatch pending" MUST be added to 1508 the bundle. 1510 Step 2: If the "request reporting of bundle reception" flag in the 1511 bundle's status report request field is set to 1, and status 1512 reporting is enabled, then a bundle reception status report with 1513 reason code "No additional information" SHOULD be generated, 1514 destined for the bundle's report-to endpoint ID. 1516 Step 3: CRCs SHOULD be computed for every block of the bundle that 1517 has an attached CRC. If any block of the bundle is malformed 1518 according to this specification (including syntactically invalid 1519 CBOR), or if any block has an attached CRC and the CRC computed for 1520 this block upon reception differs from that attached CRC, then the 1521 bundle protocol agent MUST delete the bundle for the reason "Block 1522 unintelligible". The bundle deletion procedure defined in Section 1523 5.10 MUST be followed and all remaining steps of the bundle 1524 reception procedure MUST be skipped. 1526 Step 4: For each block in the bundle that is an extension block that 1527 the bundle protocol agent cannot process: 1529 . If the block processing flags in that block indicate that a 1530 status report is requested in this event, and status reporting 1531 is enabled, then a bundle reception status report with reason 1532 code "Block unintelligible" SHOULD be generated, destined for 1533 the bundle's report-to endpoint ID. 1534 . If the block processing flags in that block indicate that the 1535 bundle must be deleted in this event, then the bundle protocol 1536 agent MUST delete the bundle for the reason "Block 1537 unintelligible"; the bundle deletion procedure defined in 1538 Section 5.10 MUST be followed and all remaining steps of the 1539 bundle reception procedure MUST be skipped. 1540 . If the block processing flags in that block do NOT indicate 1541 that the bundle must be deleted in this event but do indicate 1542 that the block must be discarded, then the bundle protocol 1543 agent MUST remove this block from the bundle. 1544 . If the block processing flags in that block indicate neither 1545 that the bundle must be deleted nor that that the block must be 1546 discarded, then processing continues with the next extension 1547 block that the bundle protocol agent cannot process, if any; 1548 otherwise, processing proceeds from step 5. 1550 Step 5: Processing proceeds from Step 1 of Section 5.3. 1552 5.7. Local Bundle Delivery 1554 The steps in processing a bundle that is destined for an endpoint of 1555 which this node is a member are: 1557 Step 1: If the received bundle is a fragment, the application data 1558 unit reassembly procedure described in Section 5.9 MUST be followed. 1559 If this procedure results in reassembly of the entire original 1560 application data unit, processing of the fragmentary bundle whose 1561 payload has been replaced by the reassembled application data unit 1562 (whether this bundle or a previously received fragment) proceeds 1563 from Step 2; otherwise, the retention constraint "Reassembly 1564 pending" MUST be added to the bundle and all remaining steps of this 1565 procedure MUST be skipped. 1567 Step 2: Delivery depends on the state of the registration whose 1568 endpoint ID matches that of the destination of the bundle: 1570 . An additional implementation-specific delivery deferral 1571 procedure MAY optionally be associated with the registration. 1572 . If the registration is in the Active state, then the bundle 1573 MUST be delivered automatically as soon as it is the next 1574 bundle that is due for delivery according to the BPA's bundle 1575 delivery scheduling policy, an implementation matter. 1576 . If the registration is in the Passive state, or if delivery of 1577 the bundle fails for some implementation-specific reason, then 1578 the registration's delivery failure action MUST be taken. 1579 Delivery failure action MUST be one of the following: 1581 o defer delivery of the bundle subject to this registration 1582 until (a) this bundle is the least recently received of 1583 all bundles currently deliverable subject to this 1584 registration and (b) either the registration is polled or 1585 else the registration is in the Active state, and also 1586 perform any additional delivery deferral procedure 1587 associated with the registration; or 1589 o abandon delivery of the bundle subject to this registration 1590 (as defined in 3.1. ). 1592 Step 3: As soon as the bundle has been delivered, if the "request 1593 reporting of bundle delivery" flag in the bundle's status report 1594 request field is set to 1 and bundle status reporting is enabled, 1595 then a bundle delivery status report SHOULD be generated, destined 1596 for the bundle's report-to endpoint ID. Note that this status report 1597 only states that the payload has been delivered to the application 1598 agent, not that the application agent has processed that payload. 1600 5.8. Bundle Fragmentation 1602 It may at times be advantageous for bundle protocol agents to reduce 1603 the sizes of bundles in order to forward them. This might be the 1604 case, for example, if a node to which a bundle is to be forwarded is 1605 accessible only via intermittent contacts and no upcoming contact is 1606 long enough to enable the forwarding of the entire bundle. 1608 The size of a bundle can be reduced by "fragmenting" the bundle. To 1609 fragment a bundle whose payload is of size M is to replace it with 1610 two "fragments" - new bundles with the same source node ID and 1611 creation timestamp as the original bundle, a.k.a. "fragmentary 1612 bundles" - whose payloads are the first N and the last (M - N) bytes 1613 of the original bundle's payload, where 0 < N < M. 1615 Note that fragments are bundles and therefore may themselves be 1616 fragmented, so multiple episodes of fragmentation may in effect 1617 replace the original bundle with more than two fragments. (However, 1618 there is only one 'level' of fragmentation, as in IP fragmentation.) 1620 Any bundle whose primary block's bundle processing flags do NOT 1621 indicate that it must not be fragmented MAY be fragmented at any 1622 time, for any purpose, at the discretion of the bundle protocol 1623 agent. NOTE, however, that some combinations of bundle 1624 fragmentation, replication, and routing might result in unexpected 1625 traffic patterns. 1627 Fragmentation SHALL be constrained as follows: 1629 . The concatenation of the payloads of all fragments produced by 1630 fragmentation MUST always be identical to the payload of the 1631 fragmented bundle (that is, the bundle that is being 1632 fragmented). Note that the payloads of fragments resulting from 1633 different fragmentation episodes, in different parts of the 1634 network, may be overlapping subsets of the fragmented bundle's 1635 payload. 1636 . The primary block of each fragment MUST differ from that of the 1637 fragmented bundle, in that the bundle processing flags of the 1638 fragment MUST indicate that the bundle is a fragment and both 1639 fragment offset and total application data unit length must be 1640 provided. Additionally, the CRC of the primary block of the 1641 fragmented bundle, if any, MUST be replaced in each fragment by 1642 a new CRC computed for the primary block of that fragment. 1643 . The payload blocks of fragments will differ from that of the 1644 fragmented bundle as noted above. 1645 . If the fragmented bundle is not a fragment or is the fragment 1646 with offset zero, then all extension blocks of the fragmented 1647 bundle MUST be replicated in the fragment whose offset is zero. 1648 . Each of the fragmented bundle's extension blocks whose "Block 1649 must be replicated in every fragment" flag is set to 1 MUST be 1650 replicated in every fragment. 1651 . Beyond these rules, rules for the replication of extension 1652 blocks in the fragments must be defined in the specifications 1653 for those extension block types. 1655 5.9. Application Data Unit Reassembly 1657 Note that the bundle fragmentation procedure described in 5.8 above 1658 may result in the replacement of a single original bundle with an 1659 arbitrarily large number of fragmentary bundles. In order to be 1660 delivered at a destination node, the original bundle's payload must 1661 be reassembled from the payloads of those fragments. 1663 If the concatenation - as informed by fragment offsets and payload 1664 lengths - of the non-overlapping portions of the payloads of all 1665 previously received fragments with the same source node ID and 1666 creation timestamp as this fragment, together with the non- 1667 overlapping portion of the payload of this fragment, forms a 1668 continuous byte array whose length is equal to the total application 1669 data unit length in the fragment's primary block, then: 1671 . This byte array -- the reassembled application data unit -- 1672 MUST replace the payload of that fragment whose payload is a 1673 subset, starting at offset zero, of the reassembled application 1674 data unit. Note that this will enable delivery of the 1675 reconstituted original bundle as described in Step 1 of 5.7. 1676 . The "Reassembly pending" retention constraint MUST be removed 1677 from every previously received fragment whose payload is a 1678 subset of the reassembled application data unit. 1680 Note: reassembly of application data units from fragments occurs at 1681 the nodes that are members of destination endpoints as necessary; an 1682 application data unit MAY also be reassembled at some other node on 1683 the path to the destination. 1685 5.10. Bundle Deletion 1687 The steps in deleting a bundle are: 1689 Step 1: If the "request reporting of bundle deletion" flag in the 1690 bundle's status report request field is set to 1, and if status 1691 reporting is enabled, then a bundle deletion status report citing 1692 the reason for deletion SHOULD be generated, destined for the 1693 bundle's report-to endpoint ID. 1695 Step 2: All of the bundle's retention constraints MUST be removed. 1697 5.11. Discarding a Bundle 1699 As soon as a bundle has no remaining retention constraints it MAY be 1700 discarded, thereby releasing any persistent storage that may have 1701 been allocated to it. 1703 5.12. Canceling a Transmission 1705 When requested to cancel a specified transmission, where the bundle 1706 created upon initiation of the indicated transmission has not yet 1707 been discarded, the bundle protocol agent MUST delete that bundle 1708 for the reason "transmission cancelled". For this purpose, the 1709 procedure defined in Section 5.10 MUST be followed. 1711 6. Administrative Record Processing 1713 6.1. Administrative Records 1715 Administrative records are standard application data units that are 1716 used in providing some of the features of the Bundle Protocol. One 1717 type of administrative record has been defined to date: bundle 1718 status reports. Note that additional types of administrative 1719 records may be defined by supplementary DTN protocol specification 1720 documents. 1722 Every administrative record consists of: 1724 . Record type code (an unsigned integer for which valid values 1725 are as defined below). 1726 . Record content in type-specific format. 1728 Valid administrative record type codes are defined as follows: 1730 +---------+--------------------------------------------+ 1732 | Value | Meaning | 1734 +=========+============================================+ 1736 | 1 | Bundle status report. | 1738 +---------+--------------------------------------------+ 1740 | (other) | Reserved for future use. | 1742 +---------+--------------------------------------------+ 1744 Figure 3: Administrative Record Type Codes 1746 Each BP administrative record SHALL be represented as a CBOR array 1747 comprising two items. 1749 The first item of the array SHALL be a record type code, which SHALL 1750 be represented as a CBOR unsigned integer. 1752 The second element of this array SHALL be the applicable CBOR 1753 representation of the content of the record. Details of the CBOR 1754 representation of administrative record type 1 are provided below. 1755 Details of the CBOR representation of other types of administrative 1756 record type are included in the specifications defining those 1757 records. 1759 6.1.1. Bundle Status Reports 1761 The transmission of "bundle status reports" under specified 1762 conditions is an option that can be invoked when transmission of a 1763 bundle is requested. These reports are intended to provide 1764 information about how bundles are progressing through the system, 1765 including notices of receipt, forwarding, final delivery, and 1766 deletion. They are transmitted to the Report-to endpoints of 1767 bundles. 1769 Each bundle status report SHALL be represented as a CBOR array. The 1770 number of elements in the array SHALL be either 6 (if the subject 1771 bundle is a fragment) or 4 (otherwise). 1773 The first item of the bundle status report array SHALL be bundle 1774 status information represented as a CBOR array of at least 4 1775 elements. The first four items of the bundle status information 1776 array shall provide information on the following four status 1777 assertions, in this order: 1779 . Reporting node received bundle. 1780 . Reporting node forwarded the bundle. 1781 . Reporting node delivered the bundle. 1782 . Reporting node deleted the bundle. 1784 Each item of the bundle status information array SHALL be a bundle 1785 status item represented as a CBOR array; the number of elements in 1786 each such array SHALL be either 2 (if the value of the first item of 1787 this bundle status item is 1 AND the "Report status time" flag was 1788 set to 1 in the bundle processing flags of the bundle whose status 1789 is being reported) or 1 (otherwise). The first item of the bundle 1790 status item array SHALL be a status indicator, a Boolean value 1791 indicating whether or not the corresponding bundle status is 1792 asserted, represented as a CBOR Boolean value. The second item of 1793 the bundle status item array, if present, SHALL indicate the time 1794 (as reported by the local system clock, an implementation matter) at 1795 which the indicated status was asserted for this bundle, represented 1796 as a DTN time as described in Section 4.1.6. above. 1798 The second item of the bundle status report array SHALL be the 1799 bundle status report reason code explaining the value of the status 1800 indicator, represented as a CBOR unsigned integer. Valid status 1801 report reason codes are registered in the IANA Bundle Status Report 1802 Reason Codes registry in the Bundle Protocol Namespace (see 10.5 1803 below). The initial contents of that registry are listed in Figure 1804 4 below but the list of status report reason codes provided here is 1805 neither exhaustive nor exclusive; supplementary DTN protocol 1806 specifications (including, but not restricted to, the Bundle 1807 Security Protocol [BPSEC]) may define additional reason codes. 1809 +---------+--------------------------------------------+ 1811 | Value | Meaning | 1812 +=========+============================================+ 1814 | 0 | No additional information. | 1816 +---------+--------------------------------------------+ 1818 | 1 | Lifetime expired. | 1820 +---------+--------------------------------------------+ 1822 | 2 | Forwarded over unidirectional link. | 1824 +---------+--------------------------------------------+ 1826 | 3 | Transmission canceled. | 1828 +---------+--------------------------------------------+ 1830 | 4 | Depleted storage. | 1832 +---------+--------------------------------------------+ 1834 | 5 | Destination endpoint ID unavailable. | 1836 +---------+--------------------------------------------+ 1838 | 6 | No known route to destination from here. | 1840 +---------+--------------------------------------------+ 1842 | 7 | No timely contact with next node on route. | 1844 +---------+--------------------------------------------+ 1846 | 8 | Block unintelligible. | 1848 +---------+--------------------------------------------+ 1850 | 9 | Hop limit exceeded. | 1852 +---------+--------------------------------------------+ 1854 | 10 | Traffic pared (e.g., status reports). | 1856 +---------+--------------------------------------------+ 1858 | (other) | Reserved for future use. | 1859 +---------+--------------------------------------------+ 1861 Figure 4: Status Report Reason Codes 1863 The third item of the bundle status report array SHALL be the source 1864 node ID identifying the source of the bundle whose status is being 1865 reported, represented as described in Section 4.1.5.1.1. above. 1867 The fourth item of the bundle status report array SHALL be the 1868 creation timestamp of the bundle whose status is being reported, 1869 represented as described in Section 4.1.7. above. 1871 The fifth item of the bundle status report array SHALL be present if 1872 and only if the bundle whose status is being reported contained a 1873 fragment offset. If present, it SHALL be the subject bundle's 1874 fragment offset represented as a CBOR unsigned integer item. 1876 The sixth item of the bundle status report array SHALL be present if 1877 and only if the bundle whose status is being reported contained a 1878 fragment offset. If present, it SHALL be the length of the subject 1879 bundle's payload represented as a CBOR unsigned integer item. 1881 Note that the forwarding parameters (such as lifetime, applicable 1882 security measures, etc.) of the bundle whose status is being 1883 reported MAY be reflected in the parameters governing the forwarding 1884 of the bundle that conveys a status report, but this is an 1885 implementation matter. Bundle protocol deployment experience to 1886 date has not been sufficient to suggest any clear guidance on this 1887 topic. 1889 6.2. Generation of Administrative Records 1891 Whenever the application agent's administrative element is directed 1892 by the bundle protocol agent to generate an administrative record, 1893 the following procedure must be followed: 1895 Step 1: The administrative record must be constructed. If the 1896 administrative record references a bundle and the referenced bundle 1897 is a fragment, the administrative record MUST contain the fragment 1898 offset and fragment length. 1900 Step 2: A request for transmission of a bundle whose payload is this 1901 administrative record MUST be presented to the bundle protocol 1902 agent. 1904 7. Services Required of the Convergence Layer 1906 7.1. The Convergence Layer 1908 The successful operation of the end-to-end bundle protocol depends 1909 on the operation of underlying protocols at what is termed the 1910 "convergence layer"; these protocols accomplish communication 1911 between nodes. A wide variety of protocols may serve this purpose, 1912 so long as each convergence layer protocol adapter provides a 1913 defined minimal set of services to the bundle protocol agent. This 1914 convergence layer service specification enumerates those services. 1916 7.2. Summary of Convergence Layer Services 1918 Each convergence layer protocol adapter is expected to provide the 1919 following services to the bundle protocol agent: 1921 . sending a bundle to a bundle node that is reachable via the 1922 convergence layer protocol; 1923 . notifying the bundle protocol agent of the disposition of its 1924 data sending procedures with regard to a bundle, upon 1925 concluding those procedures; 1926 . delivering to the bundle protocol agent a bundle that was sent 1927 by a bundle node via the convergence layer protocol. 1929 The convergence layer service interface specified here is neither 1930 exhaustive nor exclusive. That is, supplementary DTN protocol 1931 specifications (including, but not restricted to, the Bundle 1932 Security Protocol [BPSEC]) may expect convergence layer adapters 1933 that serve BP implementations conforming to those protocols to 1934 provide additional services such as reporting on the transmission 1935 and/or reception progress of individual bundles (at completion 1936 and/or incrementally), retransmitting data that were lost in 1937 transit, discarding bundle-conveying data units that the convergence 1938 layer protocol determines are corrupt or inauthentic, or reporting 1939 on the integrity and/or authenticity of delivered bundles. 1941 In addition, bundle protocol relies on the capabilities of protocols 1942 at the convergence layer to minimize congestion in the store-carry- 1943 forward overlay network. The potentially long round-trip times 1944 characterizing delay-tolerant networks are incompatible with end-to- 1945 end reactive congestion control mechanisms, so convergence-layer 1946 protocols MUST provide rate limiting or congestion control. 1948 Implementation of the TCP convergence-layer adapter [TCPCL] is 1949 mandatory. 1951 8. Implementation Status 1953 [NOTE to the RFC Editor: please remove this section before 1954 publication, as well as the reference to RFC 7942.] 1956 This section records the status of known implementations of the 1957 protocol defined by this specification at the time of posting of 1958 this Internet-Draft, and is based on a proposal described in RFC 1959 7942. The description of implementations in this section is 1960 intended to assist the IETF in its decision processes in progressing 1961 drafts to RFCs. Please note that the listing of any individual 1962 implementation here does not imply endorsement by the IETF. 1963 Furthermore, no effort has been spent to verify the information 1964 presented here that was supplied by IETF contributors. This is not 1965 intended as, and must not be construed to be, a catalog of available 1966 implementations or their features. Readers are advised to note that 1967 other implementations may exist. 1969 According to RFC 7942, "this will allow reviewers and working groups 1970 to assign due consideration to documents that have the benefit of 1971 running code, which may serve as evidence of valuable 1972 experimentation and feedback that have made the implemented 1973 protocols more mature. It is up to the individual working groups to 1974 use this information as they see fit". 1976 At the time of this writing, there are six known implementations of 1977 the current document. 1979 The first known implementation is microPCN (https://upcn.eu/). 1980 According to the developers: 1982 The Micro Planetary Communication Network (uPCN) is a free 1983 software project intended to offer an implementation of Delay- 1984 tolerant Networking protocols for POSIX operating systems (well, 1985 and for Linux) plus for the ARM Cortex STM32F4 microcontroller 1986 series. More precisely it currently provides an implementation of 1988 . the Bundle Protocol (BP, RFC 5050), 1989 . version 6 of the Bundle Protocol version 7 specification 1990 draft, 1991 . the DTN IP Neighbor Discovery (IPND) protocol, and 1992 . a routing approach optimized for message-ferry micro LEO 1993 satellites. 1995 uPCN is written in C and is built upon the real-time operating 1996 system FreeRTOS. The source code of uPCN is released under the 1997 "BSD 3-Clause License". 1999 The project depends on an execution environment offering link 2000 layer protocols such as AX.25. The source code uses the USB 2001 subsystem to interact with the environment. 2003 The second known implementation is PyDTN, developed by X-works, 2004 s.r.o (https://x-works.sk/). The final third of the implementation 2005 was developed during the IETF 101 Hackathon. According to the 2006 developers, PyDTN implements bundle coding/decoding and neighbor 2007 discovery. PyDTN is written in Python and has been shown to be 2008 interoperable with uPCN. 2010 The third known implementation is "Terra" 2011 (https://github.com/RightMesh/Terra/), a Java implementation 2012 developed in the context of terrestrial DTN. It includes an 2013 implementation of a "minimal TCP" convergence layer adapter. 2015 The fourth and fifth known implementations are products of 2016 cooperating groups at two German universities: 2018 . An implementation written in Go, licensed under GPLv3, is 2019 focused on being easily extensible suitable for research. It 2020 is maintained at the University of Marburg and can be accessed 2021 from https://github.com/dtn7/dtn7-go. 2022 . An implementation written in Rust, licensed under the 2023 MIT/Apache license, is intended for environments with limited 2024 resources or demanding safety and/or performance requirements. 2025 It is maintained at the Technical University of Darmstadt and 2026 can be accessed at https://github.com/dtn7/dtn7-rs/. 2028 The sixth known implementation is the "bpv7" module in version 4.0.0 2029 of the Interplanetary Overlay Network (ION) software maintained at 2030 the Jet Propulsion Laboratory, California Institute of Technology, 2031 for the U.S. National Aeronautics and Space Administration (NASA). 2033 9. Security Considerations 2035 The bundle protocol security architecture and the available security 2036 services are specified in an accompanying document, the Bundle 2037 Security Protocol specification [BPSEC]. 2039 The BPsec extensions to Bundle Protocol enable each block of a 2040 bundle (other than a BPsec extension block) to be individually 2041 authenticated by a signature block (Block Integrity Block, or BIB) 2042 and also enable each block of a bundle other than the primary block 2043 (and the BPsec extension blocks themselves) to be individually 2044 encrypted by a BCB. 2046 Because the security mechanisms are extension blocks that are 2047 themselves inserted into the bundle, the protections they afford 2048 apply while the bundle is at rest, awaiting transmission at the next 2049 forwarding opportunity, as well as in transit. 2051 Additionally, convergence-layer protocols that ensure authenticity 2052 of communication between adjacent nodes in BP network topology 2053 SHOULD be used where available, to minimize the ability of 2054 unauthenticated nodes to introduce inauthentic traffic into the 2055 network. Convergence-layer protocols that ensure confidentiality of 2056 communication between adjacent nodes in BP network topology SHOULD 2057 also be used where available, to minimize exposure of the bundle's 2058 primary block and other clear-text blocks, thereby offering some 2059 defense against traffic analysis. 2061 Note that, while the primary block must remain in the clear for 2062 routing purposes, the Bundle Protocol could be protected against 2063 traffic analysis to some extent by using bundle-in-bundle 2064 encapsulation [BIBE] to tunnel bundles to a safe forward 2065 distribution point: the encapsulated bundle could form the payload 2066 of an encapsulating bundle, and that payload block could be 2067 encrypted by a BCB. 2069 Note that the generation of bundle status reports is disabled by 2070 default because malicious initiation of bundle status reporting 2071 could result in the transmission of extremely large numbers of 2072 bundles, effecting a denial of service attack. Imposing bundle 2073 lifetime overrides would constitute one defense against such an 2074 attack. 2076 Note also that the reception of large numbers of fragmentary bundles 2077 with very long lifetimes could constitute a denial of service 2078 attack, occupying storage while pending reassembly that will never 2079 occur. Imposing bundle lifetime overrides would constitute one 2080 defense against such an attack. 2082 10. IANA Considerations 2084 The Bundle Protocol includes fields requiring registries managed by 2085 IANA. 2087 10.1. Bundle Block Types 2089 The current Bundle Block Types registry in the Bundle Protocol 2090 Namespace is augmented by adding a column identifying the version of 2091 the Bundle protocol (Bundle Protocol Version) that applies to the 2092 new values. IANA is requested to add the following values, as 2093 described in section 4.3.1, to the Bundle Block Types registry. The 2094 current values in the Bundle Block Types registry should have the 2095 Bundle Protocol Version set to the value "6", as shown below. 2097 +----------+-------+-----------------------------+---------------+ 2099 | Bundle | Value | Description | Reference | 2101 | Protocol | | | | 2103 | Version | | | | 2105 +----------+-------+-----------------------------+---------------+ 2107 | none | 0 | Reserved | [RFC6255] | 2109 | 6,7 | 1 | Bundle Payload Block | [RFC5050] | 2111 | | | | RFC-to-be | 2113 | 6 | 2 | Bundle Authentication Block | [RFC6257] | 2115 | 6 | 3 | Payload Integrity Block | [RFC6257] | 2117 | 6 | 4 | Payload Confidentiality | [RFC6257] | 2119 | | | Block | RFC-to-be | 2121 | 6 | 5 | Previous-Hop Insertion Block| [RFC6259] | 2123 | 7 | 6 | Previous node (proximate | RFC-to-be | 2125 | | | sender) | | 2127 | 7 | 7 | Bundle age (in seconds) | RFC-to-be | 2129 | 6 | 8 | Metadata Extension Block | [RFC6258] | 2131 | 6 | 9 | Extension Security Block | [RFC6257] | 2133 | 7 | 10 | Hop count (#prior xmit | RFC-to-be | 2135 | | | attempts) | | 2137 | 7 | 11-191| Unassigned | | 2139 | 6 |192-255| Reserved for Private and/or | [RFC5050], | 2140 | | | Experimental Use | RFC-to-be | 2142 +----------+-------+-----------------------------+---------------+ 2144 10.2. Primary Bundle Protocol Version 2146 IANA is requested to add the following value to the Primary Bundle 2147 Protocol Version registry in the Bundle Protocol Namespace. 2149 +-------+-------------+---------------+ 2151 | Value | Description | Reference | 2153 +-------+-------------+---------------+ 2155 | 7 | Assigned | RFC-to-be | 2157 +-------+-------------+---------------+ 2159 10.3. Bundle Processing Control Flags 2161 The current Bundle Processing Control Flags registry in the Bundle 2162 Protocol Namespace is augmented by adding a column identifying the 2163 version of the Bundle protocol (Bundle Protocol Version) that 2164 applies to the new values. IANA is requested to add the following 2165 values, as described in section 4.1.3, to the Bundle Processing 2166 Control Flags registry. The current values in the Bundle Processing 2167 Control Flags registry should have the Bundle Protocol Version set 2168 to the value 6 or "6, 7", as shown below. 2170 Bundle Processing Control Flags Registry 2172 +--------------------+----------------------------------+----------+ 2174 | Bundle | Bit | Description | Reference| 2176 | Protocol| Position | | | 2178 | Version | (right | | | 2180 | | to left) | | | 2182 +--------------------+----------------------------------+----------+ 2184 | 6,7 | 0 | Bundle is a fragment |[RFC5050],| 2186 | | | |RFC-to-be | 2187 | 6,7 | 1 | Application data unit is an |[RFC5050],| 2189 | | | administrative record |RFC-to-be | 2191 | 6,7 | 2 | Bundle must not be fragmented |[RFC5050],| 2193 | | | |RFC-to-be | 2195 | 6 | 3 | Custody transfer is requested |[RFC5050] | 2197 | 6 | 4 | Destination endpoint is singleton|[RFC5050] | 2199 | 6,7 | 5 | Acknowledgement by application |[RFC5050],| 2201 | | | is requested |RFC-to-be | 2203 | 7 | 6 | Status time requested in reports |RFC-to-be | 2205 | 6 | 7 | Class of service, priority |[RFC5050],| 2207 | | | |RFC-to-be | 2209 | 6 | 8 | Class of service, priority |[RFC5050],| 2211 | | | |RFC-to-be | 2213 | 6 | 9 | Class of service, reserved |[RFC5050],| 2215 | | | |RFC-to-be | 2217 | 6 | 10 | Class of service, reserved |[RFC5050],| 2219 | | | |RFC-to-be | 2221 | 6 | 11 | Class of service, reserved |[RFC5050],| 2223 | | | |RFC-to-be | 2225 | 6 | 12 | Class of service, reserved |[RFC5050],| 2227 | | | |RFC-to-be | 2229 | 6 | 13 | Class of service, reserved |[RFC5050],| 2231 | | | |RFC-to-be | 2233 | 6,7 | 14 | Request reporting of bundle |[RFC5050],| 2234 | | | reception |RFC-to-be | 2236 | 6,7 | 16 | Request reporting of bundle |[RFC5050],| 2238 | | | forwarding |RFC-to-be | 2240 | 6,7 | 17 | Request reporting of bundle |[RFC5050],| 2242 | | | delivery |RFC-to-be | 2244 | 6,7 | 18 | Request reporting of bundle |[RFC5050],| 2246 | | | deletion |RFC-to-be | 2248 | 6 | 19 | Reserved |[RFC5050],| 2250 | | | |RFC-to-be | 2252 | 6 | 20 | Reserved |[RFC5050],| 2254 | | | |RFC-to-be | 2256 | | 21-63 | Unassigned | | 2258 +--------------------+----------------------------------+----------+ 2260 The registration policy for this registry is changed to "Standards 2261 Action". Given the limited number of bits available, the allocation 2262 should only be granted for a standards-track RFC approved by the 2263 IESG. 2265 10.4. Block Processing Control Flags 2267 The current Block Processing Control Flags registry in the Bundle 2268 Protocol Namespace is augmented by adding a column identifying the 2269 version of the Bundle protocol (Bundle Protocol Version) that 2270 applies to the related BP version. The current values in the Block 2271 Processing Control Flags registry should have the Bundle Protocol 2272 Version set to the value 6 or "6, 7", as shown below. 2274 Block Processing Control Flags Registry 2276 +--------------------+----------------------------------+----------+ 2278 | Bundle | Bit | Description | Reference| 2280 | Protocol| Position | | | 2281 | Version | (right | | | 2283 | | to left) | | | 2285 +--------------------+----------------------------------+----------+ 2287 | 6,7 | 0 | Block must be replicated in |[RFC5050],| 2289 | | | every fragment |RFC-to-be | 2291 | 6,7 | 1 | Transmit status report if block |[RFC5050],| 2293 | | | can't be processed |RFC-to-be | 2295 | 6,7 | 2 | Delete bundle if block can't be |[RFC5050],| 2297 | | | processed |RFC-to-be | 2299 | 6 | 3 | Last block |[RFC5050] | 2301 | 6,7 | 4 | Discard block if it can't be |[RFC5050],| 2303 | | | processed |RFC-to-be | 2305 | 6 | 5 | Block was forwarded without |[RFC5050] | 2307 | | | being processed | | 2309 | 6 | 6 | Block contains an EID reference |[RFC5050] | 2311 | | | field | | 2313 | | 7-63 | Unassigned | | 2315 +--------------------+----------------------------------+----------+ 2317 The registration policy for this registry is changed to "Standards 2318 Action". Given the limited number of bits available, the allocation 2319 should only be granted for a standards-track RFC approved by the 2320 IESG. 2322 10.5. Bundle Status Report Reason Codes 2324 The current Bundle Status Report Reason Codes registry in the Bundle 2325 Protocol Namespace is augmented by adding a column identifying the 2326 version of the Bundle protocol (Bundle Protocol Version) that 2327 applies to the new values. IANA is requested to add the following 2328 values, as described in section 6.1.1, to the Bundle Status Report 2329 Reason Codes registry. The current values in the Bundle Status 2330 Report Reason Codes registry should have the Bundle Protocol Version 2331 set to the value 6 or 7 or "6, 7", as shown below. 2333 Bundle Status Report Reason Codes Registry 2335 +--------------------+----------------------------------+----------+ 2337 | Bundle | Value | Description | Reference| 2339 | Protocol| | | | 2341 | Version | | | | 2343 | | | | | 2345 +--------------------+----------------------------------+----------+ 2347 | 6,7 | 0 | No additional information |[RFC5050],| 2349 | | | |RFC-to-be | 2351 | 6,7 | 1 | Lifetime expired |[RFC5050],| 2353 | | | |RFC-to-be | 2355 | 6,7 | 2 | Forwarded over unidirectional |[RFC5050],| 2357 | | | link |RFC-to-be | 2359 | 6,7 | 3 | Transmission canceled |[RFC5050],| 2361 | | | |RFC-to-be | 2363 | 6,7 | 4 | Depleted storage |[RFC5050],| 2365 | | | |RFC-to-be | 2367 | 6,7 | 5 | Destination endpoint ID |[RFC5050],| 2369 | | | unavailable |RFC-to-be | 2371 | 6,7 | 6 | No known route to destination |[RFC5050],| 2373 | | | from here |RFC-to-be | 2374 | 6,7 | 7 | No timely contact with next node |[RFC5050],| 2376 | | | on route |RFC-to-be | 2378 | 6,7 | 8 | Block unintelligible |[RFC5050],| 2380 | | | |RFC-to-be | 2382 | 7 | 9 | Hop limit exceeded |RFC-to-be | 2384 | 7 | 10 | Traffic pared |RFC-to-be | 2386 | | 11-254 | Unassigned | | 2388 | 6 | 255 | Reserved |[RFC6255],| 2390 | | | |RFC-to-be | 2392 +-------+-----------------------------------------------+----------+ 2394 10.6. Bundle Protocol URI scheme types 2396 The Bundle Protocol has a URI scheme type field - an unsigned 2397 integer of indefinite length - for which IANA is requested to create 2398 and maintain a new "Bundle Protocol URI Scheme Type" registry in the 2399 Bundle Protocol Namespace. The "Bundle Protocol URI Scheme Type" 2400 registry governs an 8-bit namespace. Initial values for the Bundle 2401 Protocol URI Scheme Type registry are given below. 2403 The registration policy for this registry is: Standards Action. 2404 Given the limited number of bits available, the allocation should 2405 only be granted for a standards-track RFC approved by the IESG. 2407 The value range is: unsigned 8-bit integer. 2409 Each assignment consists of a URI scheme type name and its 2410 associated description, a reference to the document that defines the 2411 URI scheme, and a reference to the document that defines the use of 2412 this URI scheme in BP endpoint IDs (including the CBOR 2413 representation of those endpoint IDs in transmitted bundles). 2415 Bundle Protocol URI Scheme Type Registry 2417 +---------+-------------+----------------+------------------+ 2419 | | | BP Utilization | URI Definition | 2420 | Value | Description | Reference | Reference | 2422 +---------+-------------+----------------+------------------+ 2424 | 0 | Reserved | n/a | | 2426 | 1 | dtn | RFC-to-be | RFC-to-be | 2428 | 2 | ipn | RFC-to-be | [RFC6260], | 2430 | | | | RFC-to-be | 2432 | 3-254 | Unassigned | n/a | | 2434 | 255 | reserved | n/a | | 2436 +---------+-------------+----------------+------------------+ 2438 10.7. URI scheme "dtn" 2440 IANA is requested to update the registration of the URI scheme with 2441 the string "dtn" as the scheme name, as follows: 2443 URI scheme name: "dtn" 2445 Status: permanent 2447 Applications and/or protocols that use this URI scheme name: the 2448 Delay-Tolerant Networking (DTN) Bundle Protocol (BP). 2450 Contact: 2452 Scott Burleigh 2454 Jet Propulsion Laboratory, 2456 California Institute of Technology 2458 scott.c.burleigh@jpl.nasa.gov 2460 +1 (800) 393-3353 2462 Change controller: 2464 IETF, iesg@ietf.org 2466 10.8. URI scheme "ipn" 2468 IANA is requested to update the registration of the URI scheme with 2469 the string "ipn" as the scheme name, originally documented in RFC 2470 6260 [RFC6260], as follows. 2472 URI scheme name: "ipn" 2474 Status: permanent 2476 Applications and/or protocols that use this URI scheme name: the 2477 Delay-Tolerant Networking (DTN) Bundle Protocol (BP). 2479 Contact: 2481 Scott Burleigh 2483 Jet Propulsion Laboratory, 2485 California Institute of Technology 2487 scott.c.burleigh@jpl.nasa.gov 2489 +1 (800) 393-3353 2491 Change controller: 2493 IETF, iesg@ietf.org 2495 11. References 2497 11.1. Normative References 2499 [BPSEC] Birrane, E., "Bundle Security Protocol Specification", 2500 draft-ietf-dtn-bpsec, January 2020. 2502 [CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4, 2503 International Telecommunications Union, October 1996. 2505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2506 Requirement Levels", BCP 14, RFC 2119, March 1997. 2508 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 2509 4960, September 2007. 2511 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2512 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2514 [RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object 2515 Representation (CBOR)", RFC 7049, October 2013. 2517 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2518 2119 Key Words", BCP 14, RFC 8174, May 2017. 2520 [SABR] "Schedule-Aware Bundle Routing", CCSDS Recommended Standard 2521 734.3-B-1, Consultative Committee for Space Data Systems, July 2019. 2523 [TCPCL] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 2524 Tolerant Networking TCP Convergence Layer Protocol Version 4", 2525 draft-ietf-dtn-tcpclv4, January 2020. 2527 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2528 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 2529 January 2005. 2531 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2532 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 2533 2015. 2535 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 2536 historical background and perspectives" in "Journees systemes de 2537 reference spatio-temporels", 2004. 2539 11.2. Informative References 2541 [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 2542 4838, April 2007. 2544 [BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", draft-ietf- 2545 dtn-bibect, August 2019. 2547 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 2548 Identifiers (IRIs)", RFC 3987, January 2005. 2550 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 2551 Specification", RFC 5050, November 2007. 2553 [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol 2554 IANA Registries", RFC 6255, May 2011. 2556 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 2557 "Bundle Security Protocol Specification", RFC 6257, May 2011. 2559 [RFC6258] Symington, S., "Delay-Tolerant Networking Metadata 2560 Extension Block", RFC 6258, May 2011. 2562 [RFC6259] Symington, S., "Delay-Tolerant Networking Previous-Hop 2563 Insertion Block", RFC 6259, May 2011. 2565 [RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", 2566 RFC 6260, May 2011. 2568 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, 2569 "Internet Small Computer System Interface (iSCSI) Protocol 2570 (Consolidated)", RFC 7143, April 2014. 2572 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 2573 Challenged Internets", SIGCOMM 2003. 2575 12. Acknowledgments 2577 This work is freely adapted from RFC 5050, which was an effort of 2578 the Delay Tolerant Networking Research Group. The following DTNRG 2579 participants contributed significant technical material and/or 2580 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 2581 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 2582 Michael Demmer of the University of California at Berkeley, Robert 2583 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 2584 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 2585 College Dublin, Howard Weiss and Peter Lovell of SPARTA, Inc., and 2586 Manikantan Ramadas of Ohio University. 2588 This document was prepared using 2-Word-v2.0.template.dot. 2590 13. Significant Changes from RFC 5050 2592 Points on which this draft significantly differs from RFC 5050 2593 include the following: 2595 . Clarify the difference between transmission and forwarding. 2596 . Migrate custody transfer to the bundle-in-bundle encapsulation 2597 specification [BIBE]. 2598 . Introduce the concept of "node ID" as functionally distinct 2599 from endpoint ID, while having the same syntax. 2600 . Restructure primary block, making it immutable. Add optional 2601 CRC. 2602 . Add optional CRCs to non-primary blocks. 2603 . Add block ID number to canonical block format (to support 2604 BPsec). 2605 . Add definition of bundle age extension block. 2606 . Add definition of previous node extension block. 2607 . Add definition of hop count extension block. 2608 . Remove Quality of Service markings. 2610 . Change from SDNVs to CBOR representation. 2611 . Add lifetime overrides. 2613 Appendix A. For More Information 2615 Copyright (c) 2020 IETF Trust and the persons identified as authors 2616 of the code. All rights reserved. 2618 Redistribution and use in source and binary forms, with or without 2619 modification, is permitted pursuant to, and subject to the license 2620 terms contained in, the Simplified BSD License set forth in Section 2621 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2622 (http://trustee.ietf.org/license-info). 2624 Appendix B. CDDL expression 2626 For informational purposes, Carsten Bormann and Brian Sipos have 2627 kindly provided an expression of the Bundle Protocol specification 2628 in the Concise Data Definition Language (CDDL). That CDDL 2629 expression is presented below. Note that wherever the CDDL 2630 expression is in disagreement with the textual representation of the 2631 BP specification presented in the earlier sections of this document, 2632 the textual representation rules. 2634 start = bundle / #6.55799(bundle) 2636 ; Times before 2000 are invalid 2638 dtn-time = uint 2640 ; CRC enumerated type 2642 crc-type = &( 2644 crc-none: 0, 2646 crc-16bit: 1, 2648 crc-32bit: 2 2650 ) 2652 ; Either 16-bit or 32-bit 2654 crc-value = (bstr .size 2) / (bstr .size 4) 2656 creation-timestamp = [ 2658 dtn-time, ; absolute time of creation 2660 sequence: uint ; sequence within the time 2662 ] 2664 eid = $eid .within eid-structure 2666 eid-structure = [ 2668 uri-code: uint, 2669 SSP: any 2671 ] 2673 $eid /= [ 2675 uri-code: 1, 2677 SSP: (tstr / 0) 2679 ] 2681 $eid /= [ 2683 uri-code: 2, 2685 SSP: [ 2687 nodenum: uint, 2689 servicenum: uint 2691 ] 2693 ] 2695 ; The root bundle array 2697 bundle = [primary-block, *extension-block, payload-block] 2699 primary-block = [ 2701 version: 7, 2703 bundle-control-flags, 2705 crc-type, 2707 destination: eid, 2709 source-node: eid, 2711 report-to: eid, 2713 creation-timestamp, 2715 lifetime: uint, 2716 ? ( 2718 fragment-offset: uint, 2720 total-application-data-length: uint 2722 ), 2724 ? crc-value, 2726 ] 2728 bundle-control-flags = uint .bits bundleflagbits 2730 bundleflagbits = &( 2732 reserved: 21, 2734 reserved: 20, 2736 reserved: 19, 2738 bundle-deletion-status-reports-are-requested: 18, 2740 bundle-delivery-status-reports-are-requested: 17, 2742 bundle-forwarding-status-reports-are-requested: 16, 2744 reserved: 15, 2746 bundle-reception-status-reports-are-requested: 14, 2748 reserved: 13, 2750 reserved: 12, 2752 reserved: 11, 2754 reserved: 10, 2756 reserved: 9, 2758 reserved: 8, 2760 reserved: 7, 2761 status-time-is-requested-in-all-status-reports: 6, 2763 user-application-acknowledgement-is-requested: 5, 2765 reserved: 4, 2767 reserved: 3, 2769 bundle-must-not-be-fragmented: 2, 2771 payload-is-an-administrative-record: 1, 2773 bundle-is-a-fragment: 0 2775 ) 2777 ; Abstract shared structure of all non-primary blocks 2779 canonical-block-structure = [ 2781 block-type-code: uint, 2783 block-number: uint, 2785 block-control-flags, 2787 crc-type, 2789 ; Each block type defines the content within the bytestring 2791 block-type-specific-data, 2793 ? crc-value 2795 ] 2797 block-control-flags = uint .bits blockflagbits 2799 blockflagbits = &( 2801 reserved: 7, 2803 reserved: 6, 2805 reserved: 5, 2807 block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4, 2808 reserved: 3, 2810 bundle-must-be-deleted-if-block-cannot-be-processed: 2, 2812 status-report-must-be-transmitted-if-block-cannot-be-processed: 1, 2814 block-must-be-replicated-in-every-fragment: 0 2816 ) 2818 block-type-specific-data = bstr / #6.24(bstr) 2820 ; Actual CBOR data embedded in a bytestring, with optional tag to 2821 indicate so 2823 embedded-cbor = (bstr .cbor Item) / #6.24(bstr .cbor Item) 2825 ; Extension block type, which does not specialize other than the 2826 code/number 2828 extension-block = $extension-block-structure .within canonical- 2829 block-structure 2831 ; Generic shared structure of all non-primary blocks 2833 extension-block-use = [ 2835 block-type-code: CodeValue, 2837 block-number: (uint .gt 1), 2839 block-control-flags, 2841 crc-type, 2843 BlockData, 2845 ? crc-value 2847 ] 2849 ; Payload block type 2851 payload-block = payload-block-structure .within canonical-block- 2852 structure 2853 payload-block-structure = [ 2855 block-type-code: 1, 2857 block-number: 1, 2859 block-control-flags, 2861 crc-type, 2863 $payload-block-data, 2865 ? crc-value 2867 ] 2869 ; Arbitrary payload data, including non-CBOR bytestring 2871 $payload-block-data /= block-type-specific-data 2873 ; Administrative record as a payload data specialization 2875 $payload-block-data /= embedded-cbor 2877 admin-record = $admin-record .within admin-record-structure 2879 admin-record-structure = [ 2881 record-type-code: uint, 2883 record-content: any 2885 ] 2887 ; Only one defined record type 2889 $admin-record /= [1, status-record-content] 2891 status-record-content = [ 2893 bundle-status-information, 2895 status-report-reason-code: uint, 2897 source-node-eid: eid, 2899 subject-creation-timestamp: creation-timestamp, 2900 ? ( 2902 subject-payload-offset: uint, 2904 subject-payload-length: uint 2906 ) 2908 ] 2910 bundle-status-information = [ 2912 reporting-node-received-bundle: status-info-content, 2914 reporting-node-forwarded-bundle: status-info-content, 2916 reporting-node-delivered-bundle: status-info-content, 2918 reporting-node-deleted-bundle: status-info-content 2920 ] 2922 status-info-content = [ 2924 status-indicator: bool, 2926 ? timestamp: dtn-time 2928 ] 2930 ; Previous Node extension block 2932 $extension-block-structure /= 2934 extension-block-use<6, embedded-cbor> 2936 ext-data-previous-node = eid 2938 ; Bundle Age extension block 2940 $extension-block-structure /= 2942 extension-block-use<7, embedded-cbor> 2944 ext-data-bundle-age = uint 2946 ; Hop Count extension block 2947 $extension-block-structure /= 2949 extension-block-use<10, embedded-cbor> 2951 ext-data-hop-count = [ 2953 hop-limit: uint, 2955 hop-count: uint 2957 ] 2959 Authors' Addresses 2961 Scott Burleigh 2962 Jet Propulsion Laboratory, California Institute of Technology 2963 4800 Oak Grove Dr. 2964 Pasadena, CA 91109-8099 2965 US 2966 Phone: +1 818 393 3353 2967 Email: Scott.C.Burleigh@jpl.nasa.gov 2969 Kevin Fall 2970 Roland Computing Services 2971 3871 Piedmont Ave. Suite 8 2972 Oakland, CA 94611 2973 US 2974 Email: kfall+rcs@kfall.com 2976 Edward J. Birrane 2977 Johns Hopkins University Applied Physics Laboratory 2978 11100 Johns Hopkins Rd 2979 Laurel, MD 20723 2980 US 2981 Phone: +1 443 778 7423 2982 Email: Edward.Birrane@jhuapl.edu