idnits 2.17.1 draft-ietf-dtn-bpbis-29.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2020) is 1255 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 (~~), 2 warnings (==), 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: May 21, 2021 Roland Computing Services 5 E. Birrane 6 APL, Johns Hopkins University 7 November 17, 2020 9 Bundle Protocol Version 7 10 draft-ietf-dtn-bpbis-29.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 May 21, 2021. 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...........................14 68 4.1.1. CRC Type............................................14 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.1.1. The "dtn" URI scheme......................18 75 4.1.5.1.2. The "ipn" URI scheme......................20 76 4.1.5.2. Node ID........................................21 77 4.1.6. DTN Time............................................22 78 4.1.7. Creation Timestamp..................................22 79 4.1.8. Block-type-specific Data............................23 80 4.2. Bundle Representation....................................23 81 4.2.1. Bundle..............................................23 82 4.2.2. Primary Bundle Block................................24 83 4.2.3. Canonical Bundle Block Format.......................26 84 4.3. Extension Blocks.........................................27 85 4.3.1. Previous Node.......................................27 86 4.3.2. Bundle Age..........................................28 87 4.3.3. Hop Count...........................................28 88 5. Bundle Processing.............................................29 89 5.1. Generation of Administrative Records.....................29 90 5.2. Bundle Transmission......................................30 91 5.3. Bundle Dispatching.......................................30 92 5.4. Bundle Forwarding........................................30 93 5.4.1. Forwarding Contraindicated..........................33 94 5.4.2. Forwarding Failed...................................33 95 5.5. Bundle Expiration........................................33 96 5.6. Bundle Reception.........................................34 97 5.7. Local Bundle Delivery....................................35 98 5.8. Bundle Fragmentation.....................................36 99 5.9. Application Data Unit Reassembly.........................37 100 5.10. Bundle Deletion.........................................38 101 5.11. Discarding a Bundle.....................................38 102 5.12. Canceling a Transmission................................38 103 6. Administrative Record Processing..............................38 104 6.1. Administrative Records...................................38 105 6.1.1. Bundle Status Reports...............................39 106 6.2. Generation of Administrative Records.....................42 107 7. Services Required of the Convergence Layer....................42 108 7.1. The Convergence Layer....................................42 109 7.2. Summary of Convergence Layer Services....................43 110 8. Implementation Status.........................................43 111 9. Security Considerations.......................................45 112 10. IANA Considerations..........................................47 113 10.1. Bundle Block Types......................................47 114 10.2. Primary Bundle Protocol Version.........................48 115 10.3. Bundle Processing Control Flags.........................48 116 10.4. Block Processing Control Flags..........................50 117 10.5. Bundle Status Report Reason Codes.......................52 118 10.6. Bundle Protocol URI scheme types........................53 119 10.7. URI scheme "dtn"........................................54 120 10.8. URI scheme "ipn"........................................55 121 11. References...................................................56 122 11.1. Normative References....................................56 123 11.2. Informative References..................................57 124 12. Acknowledgments..............................................57 125 13. Significant Changes from RFC 5050............................58 126 Appendix A. For More Information.................................59 127 Appendix B. CDDL expression......................................60 129 1. Introduction 131 Since the publication of the Bundle Protocol Specification 132 (Experimental RFC 5050 [RFC5050]) in 2007, the Delay-Tolerant 133 Networking (DTN) Bundle Protocol has been implemented in multiple 134 programming languages and deployed to a wide variety of computing 135 platforms. This implementation and deployment experience has 136 identified opportunities for making the protocol simpler, more 137 capable, and easier to use. The present document, standardizing the 138 Bundle Protocol (BP), is adapted from RFC 5050 in that context, 139 reflecting lessons learned. Significant changes from the Bundle 140 Protocol specification defined in RFC 5050 are listed in section 13. 142 This document describes version 7 of BP. 144 Delay Tolerant Networking is a network architecture providing 145 communications in and/or through highly stressed environments. 146 Stressed networking environments include those with intermittent 147 connectivity, large and/or variable delays, and high bit error 148 rates. To provide its services, BP may be viewed as sitting at the 149 application layer of some number of constituent networks, forming a 150 store-carry-forward overlay network. Key capabilities of BP 151 include: 153 . Ability to use physical motility for the movement of data 154 . Ability to move the responsibility for error control from one 155 node to another 156 . Ability to cope with intermittent connectivity, including cases 157 where the sender and receiver are not concurrently present in 158 the network 159 . Ability to take advantage of scheduled, predicted, and 160 opportunistic connectivity, whether bidirectional or 161 unidirectional, in addition to continuous connectivity 162 . Late binding of overlay network endpoint identifiers to 163 underlying constituent network addresses 165 For descriptions of these capabilities and the rationale for the DTN 166 architecture, see [ARCH] and [SIGC]. 168 BP's location within the standard protocol stack is as shown in 169 Figure 1. BP uses underlying "native" transport and/or network 170 protocols for communications within a given constituent network. 171 The layer at which those underlying protocols are located is here 172 termed the "convergence layer" and the interface between the bundle 173 protocol and a specific underlying protocol is termed a "convergence 174 layer adapter". 176 Figure 1 shows three distinct transport and network protocols 177 (denoted T1/N1, T2/N2, and T3/N3). 179 +-----------+ +-----------+ 180 | BP app | | BP app | 181 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 182 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 183 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 184 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 185 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 186 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 187 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 188 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 189 +-----------+ +-------------+ +-------------+ +-----------+ 190 | | | | 191 |<---- A network ---->| |<---- A network ---->| 192 | | | | 194 Figure 1: The Bundle Protocol in the Protocol Stack Model 196 This document describes the format of the protocol data units 197 (called "bundles") passed between entities participating in BP 198 communications. 200 The entities are referred to as "bundle nodes". This document does 201 not address: 203 . Operations in the convergence layer adapters that bundle nodes 204 use to transport data through specific types of internets. 205 (However, the document does discuss the services that must be 206 provided by each adapter at the convergence layer.) 207 . The bundle route computation algorithm. 208 . Mechanisms for populating the routing or forwarding information 209 bases of bundle nodes. 210 . The mechanisms for securing bundles en route. 211 . The mechanisms for managing bundle nodes. 213 Note that implementations of the specification presented in this 214 document will not be interoperable with implementations of RFC 5050. 216 2. Conventions used in this document 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 220 "OPTIONAL" in this document are to be interpreted as described in 221 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 222 capitals, as shown here. 224 3. Service Description 226 3.1. Definitions 228 Bundle - A bundle is a protocol data unit of BP, so named because 229 negotiation of the parameters of a data exchange may be impractical 230 in a delay-tolerant network: it is often better practice to "bundle" 231 with a unit of application data all metadata that might be needed in 232 order to make the data immediately usable when delivered to the 233 application. Each bundle comprises a sequence of two or more 234 "blocks" of protocol data, which serve various purposes. 236 Block - A bundle protocol block is one of the protocol data 237 structures that together constitute a well-formed bundle. 239 Application Data Unit (ADU) - An application data unit is the unit 240 of data whose conveyance to the bundle's destination is the purpose 241 for the transmission of some bundle that is not a fragment (as 242 defined below). 244 Bundle payload - A bundle payload (or simply "payload") is the 245 content of the bundle's payload block. The terms "bundle content", 246 "bundle payload", and "payload" are used interchangeably in this 247 document. For a bundle that is not a fragment (as defined below), 248 the payload is an application data unit. 250 Partial payload - A partial payload is a payload that comprises 251 either the first N bytes or the last N bytes of some other payload 252 of length M, such that 0 < N < M. Note that every partial payload 253 is a payload and therefore can be further subdivided into partial 254 payloads. 256 Fragment - A fragment, a.k.a. "fragmentary bundle", is a bundle 257 whose payload block contains a partial payload. 259 Bundle node - A bundle node (or, in the context of this document, 260 simply a "node") is any entity that can send and/or receive bundles. 261 Each bundle node has three conceptual components, defined below, as 262 shown in Figure 2: a "bundle protocol agent", a set of zero or more 263 "convergence layer adapters", and an "application agent". ("CL1 264 PDUs" are the PDUs of the convergence-layer protocol used in network 265 1.) 267 +-----------------------------------------------------------+ 268 |Node | 269 | | 270 | +-------------------------------------------------------+ | 271 | |Application Agent | | 272 | | | | 273 | | +--------------------------+ +----------------------+ | | 274 | | |Administrative element | |Application-specific | | | 275 | | | | |element | | | 276 | | | | | | | | 277 | | +--------------------------+ +----------------------+ | | 278 | | ^ ^ | | 279 | | Admin|records Application|data | | 280 | | | | | | 281 | +----------------v--------------------------v-----------+ | 282 | ^ | 283 | | ADUs | 284 | | | 285 | +-----------------------------v-------------------------+ | 286 | |Bundle Protocol Agent | | 287 | | | | 288 | | | | 289 | +-------------------------------------------------------+ | 290 | ^ ^ ^ | 291 | | Bundles | Bundles Bundles | | 292 | | | | | 293 | +------v-----+ +-----v------+ +-----v-----+ | 294 | |CLA 1 | |CLA 2 | |CLA n | | 295 | | | | | . . . | | | 296 | | | | | | | | 297 +-+------------+-----+------------+-----------+-----------+-+ 298 ^ ^ ^ 299 CL1|PDUs CL2|PDUs CLn|PDUs 300 | | | 301 +------v-----+ +-----v------+ +-----v-----+ 302 Network 1 Network 2 Network n 304 Figure 2: Components of a Bundle Node 306 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 307 the node component that offers the BP services and executes the 308 procedures of the bundle protocol. 310 Convergence layer adapter - A convergence layer adapter (CLA) is a 311 node component that sends and receives bundles on behalf of the BPA, 312 utilizing the services of some 'native' protocol stack that is 313 supported in one of the networks within which the node is 314 functionally located. 316 Application agent - The application agent (AA) of a node is the node 317 component that utilizes the BP services to effect communication for 318 some user purpose. The application agent in turn has two elements, 319 an administrative element and an application-specific element. 321 Application-specific element - The application-specific element of 322 an AA is the node component that constructs, requests transmission 323 of, accepts delivery of, and processes units of user application 324 data. 326 Administrative element - The administrative element of an AA is the 327 node component that constructs and requests transmission of 328 administrative records (defined below), including status reports, 329 and accepts delivery of and processes any administrative records 330 that the node receives. 332 Administrative record - A BP administrative record is an application 333 data unit that is exchanged between the administrative elements of 334 nodes' application agents for some BP administrative purpose. The 335 only administrative record defined in this specification is the 336 status report, discussed later. 338 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 339 of zero or more bundle nodes that all identify themselves for BP 340 purposes by some common identifier, called a "bundle endpoint ID" 341 (or, in this document, simply "endpoint ID"; endpoint IDs are 342 described in detail in Section 4.5.5.1 below. 344 Singleton endpoint - A singleton endpoint is an endpoint that always 345 contains exactly one member. 347 Registration - A registration is the state machine characterizing a 348 given node's membership in a given endpoint. Any single 349 registration has an associated delivery failure action as defined 350 below and must at any time be in one of two states: Active or 351 Passive. Registrations are local; information about a node's 352 registrations is not expected to be available at other nodes, and 353 the Bundle Protocol does not include a mechanism for distributing 354 information about registrations. 356 Delivery - A bundle is considered to have been delivered at a node 357 subject to a registration as soon as the application data unit that 358 is the payload of the bundle, together with any relevant metadata 359 (an implementation matter), has been presented to the node's 360 application agent in a manner consistent with the state of that 361 registration. 363 Deliverability - A bundle is considered "deliverable" subject to a 364 registration if and only if (a) the bundle's destination endpoint is 365 the endpoint with which the registration is associated, (b) the 366 bundle has not yet been delivered subject to this registration, and 367 (c) the bundle has not yet been "abandoned" (as defined below) 368 subject to this registration. 370 Abandonment - To abandon a bundle subject to some registration is to 371 assert that the bundle is not deliverable subject to that 372 registration. 374 Delivery failure action - The delivery failure action of a 375 registration is the action that is to be taken when a bundle that is 376 "deliverable" subject to that registration is received at a time 377 when the registration is in the Passive state. 379 Destination - The destination of a bundle is the endpoint comprising 380 the node(s) at which the bundle is to be delivered (as defined 381 above). 383 Transmission - A transmission is an attempt by a node's BPA to cause 384 copies of a bundle to be delivered to one or more of the nodes that 385 are members of some endpoint (the bundle's destination) in response 386 to a transmission request issued by the node's application agent. 388 Forwarding - To forward a bundle to a node is to invoke the services 389 of one or more CLAs in a sustained effort to cause a copy of the 390 bundle to be received by that node. 392 Discarding - To discard a bundle is to cease all operations on the 393 bundle and functionally erase all references to it. The specific 394 procedures by which this is accomplished are an implementation 395 matter. 397 Retention constraint - A retention constraint is an element of the 398 state of a bundle that prevents the bundle from being discarded. 399 That is, a bundle cannot be discarded while it has any retention 400 constraints. 402 Deletion - To delete a bundle is to remove unconditionally all of 403 the bundle's retention constraints, enabling the bundle to be 404 discarded. 406 3.2. Discussion of BP concepts 408 Multiple instances of the same bundle (the same unit of DTN protocol 409 data) might exist concurrently in different parts of a network -- 410 possibly differing in some blocks -- in the memory local to one or 411 more bundle nodes and/or in transit between nodes. In the context of 412 the operation of a bundle node, a bundle is an instance (copy), in 413 that node's local memory, of some bundle that is in the network. 415 The payload for a bundle forwarded in response to a bundle 416 transmission request is the application data unit whose location is 417 provided as a parameter to that request. The payload for a bundle 418 forwarded in response to reception of a bundle is the payload of the 419 received bundle. 421 In the most familiar case, a bundle node is instantiated as a single 422 process running on a general-purpose computer, but in general the 423 definition is meant to be broader: a bundle node might alternatively 424 be a thread, an object in an object-oriented operating system, a 425 special-purpose hardware device, etc. 427 The manner in which the functions of the BPA are performed is wholly 428 an implementation matter. For example, BPA functionality might be 429 coded into each node individually; it might be implemented as a 430 shared library that is used in common by any number of bundle nodes 431 on a single computer; it might be implemented as a daemon whose 432 services are invoked via inter-process or network communication by 433 any number of bundle nodes on one or more computers; it might be 434 implemented in hardware. 436 Every CLA implements its own thin layer of protocol, interposed 437 between BP and the (usually "top") protocol(s) of the underlying 438 native protocol stack; this "CL protocol" may only serve to 439 multiplex and de-multiplex bundles to and from the underlying native 440 protocol, or it may offer additional CL-specific functionality. The 441 manner in which a CLA sends and receives bundles, as well as the 442 definitions of CLAs and CL protocols, are beyond the scope of this 443 specification. 445 Note that the administrative element of a node's application agent 446 may itself, in some cases, function as a convergence-layer adapter. 447 That is, outgoing bundles may be "tunneled" through encapsulating 448 bundles: 450 . An outgoing bundle constitutes a byte array. This byte array 451 may, like any other, be presented to the bundle protocol agent 452 as an application data unit that is to be transmitted to some 453 endpoint. 454 . The original bundle thus forms the payload of an encapsulating 455 bundle that is forwarded using some other convergence-layer 456 protocol(s). 457 . When the encapsulating bundle is received, its payload is 458 delivered to the peer application agent administrative element, 459 which then instructs the bundle protocol agent to dispatch that 460 original bundle in the usual way. 462 The purposes for which this technique may be useful (such as cross- 463 domain security) are beyond the scope of this specification. 465 The only interface between the BPA and the application-specific 466 element of the AA is the BP service interface. But between the BPA 467 and the administrative element of the AA there is a (conceptual) 468 private control interface in addition to the BP service interface. 469 This private control interface enables the BPA and the 470 administrative element of the AA to direct each other to take action 471 under specific circumstances. 473 In the case of a node that serves simply as a BP "router", the AA 474 may have no application-specific element at all. The application- 475 specific elements of other nodes' AAs may perform arbitrarily 476 complex application functions, perhaps even offering multiplexed DTN 477 communication services to a number of other applications. As with 478 the BPA, the manner in which the AA performs its functions is wholly 479 an implementation matter. 481 Singletons are the most familiar sort of endpoint, but in general 482 the endpoint notion is meant to be broader. For example, the nodes 483 in a sensor network might constitute a set of bundle nodes that are 484 all registered in a single common endpoint and will all receive any 485 data delivered at that endpoint. *Note* too that any given bundle 486 node might be registered in multiple bundle endpoints and receive 487 all data delivered at each of those endpoints. 489 Recall that every node, by definition, includes an application agent 490 which in turn includes an administrative element, which exchanges 491 administrative records with the administrative elements of other 492 nodes. As such, every node is permanently, structurally registered 493 in the singleton endpoint at which administrative records received 494 from other nodes are delivered. Registration in no other endpoint 495 can ever be assumed to be permanent. This endpoint, termed the 496 node's "administrative endpoint", is therefore uniquely and 497 permanently associated with the node, and for this reason the ID of 498 a node's administrative endpoint additionally serves as the "node 499 ID" (see 4.1.5.2 below) of the node. 501 The destination of every bundle is an endpoint, which may or may not 502 be singleton. The source of every bundle is a node, identified by 503 node ID. Note, though, that the source node ID asserted in a given 504 bundle may be the null endpoint ID (as described later) rather than 505 the ID of the source node; bundles for which the asserted source 506 node ID is the null endpoint ID are termed "anonymous" bundles. 508 Any number of transmissions may be concurrently undertaken by the 509 bundle protocol agent of a given node. 511 When the bundle protocol agent of a node determines that a bundle 512 must be forwarded to a node (either to a node that is a member of 513 the bundle's destination endpoint or to some intermediate forwarding 514 node) in the course of completing the successful transmission of 515 that bundle, the bundle protocol agent invokes the services of one 516 or more CLAs in a sustained effort to cause a copy of the bundle to 517 be received by that node. 519 Upon reception, the processing of a bundle that has been received by 520 a given node depends on whether or not the receiving node is 521 registered in the bundle's destination endpoint. If it is, and if 522 the payload of the bundle is non-fragmentary (possibly as a result 523 of successful payload reassembly from fragmentary payloads, 524 including the original payload of the newly received bundle), then 525 the bundle is normally delivered to the node's application agent 526 subject to the registration characterizing the node's membership in 527 the destination endpoint. 529 The bundle protocol does not natively ensure delivery of a bundle to 530 its destination. Data loss along the path to the destination node 531 can be minimized by utilizing reliable convergence-layer protocols 532 between neighbors on all segments of the end-to-end path, but for 533 end-to-end bundle delivery assurance it will be necessary to develop 534 extensions to the bundle protocol and/or application-layer 535 mechanisms. 537 The bundle protocol is designed for extensibility. Bundle protocol 538 extensions, documented elsewhere, may extend this specification by: 540 . defining additional blocks; 541 . defining additional administrative records; 542 . defining additional bundle processing flags; 543 . defining additional block processing flags; 544 . defining additional types of bundle status reports; 545 . defining additional bundle status report reason codes; 546 . defining additional mandates and constraints on processing 547 that conformant bundle protocol agents must perform at 548 specified points in the inbound and outbound bundle processing 549 cycles. 551 3.3. Services Offered by Bundle Protocol Agents 553 The BPA of each node is expected to provide the following services 554 to the node's application agent: 556 . commencing a registration (registering the node in an 557 endpoint); 558 . terminating a registration; 559 . switching a registration between Active and Passive states; 560 . transmitting a bundle to an identified bundle endpoint; 561 . canceling a transmission; 562 . polling a registration that is in the Passive state; 563 . delivering a received bundle. 565 Note that the details of registration functionality are an 566 implementation matter and are beyond the scope of this 567 specification. 569 4. Bundle Format 571 The format of bundles SHALL conform to the Concise Binary Object 572 Representation (CBOR [RFC7049]). 574 Cryptographic verification of a block is possible only if the 575 sequence of octets on which the verifying node computes its hash - 576 the canonicalized representation of the block - is identical to the 577 sequence of octets on which the hash declared for that block was 578 computed. To ensure that blocks are always in canonical 579 representation when they are transmitted and received, the CBOR 580 representations of the values of all fields in all blocks must 581 conform to the rules for Canonical CBOR as specified in [RFC7049]. 583 Each bundle SHALL be a concatenated sequence of at least two blocks, 584 represented as a CBOR indefinite-length array. The first block in 585 the sequence (the first item of the array) MUST be a primary bundle 586 block in CBOR representation as described below; the bundle MUST 587 have exactly one primary bundle block. The primary block MUST be 588 followed by one or more canonical bundle blocks (additional array 589 items) in CBOR representation as described in 4.2.3 below. The last 590 such block MUST be a payload block; the bundle MUST have exactly one 591 payload block. The payload block SHALL be followed by a CBOR 592 "break" stop code, terminating the array. 594 (Note that, while CBOR permits considerable flexibility in the 595 encoding of bundles, this flexibility must not be interpreted as 596 inviting increased complexity in protocol data unit structure.) 598 An implementation of the Bundle Protocol MAY discard any sequence of 599 bytes that does not conform to the Bundle Protocol specification. 601 An implementation of the Bundle Protocol MAY accept a sequence of 602 bytes that does not conform to the Bundle Protocol specification 603 (e.g., one that represents data elements in fixed-length arrays 604 rather than indefinite-length arrays) and transform it into 605 conformant BP structure before processing it. Procedures for 606 accomplishing such a transformation are beyond the scope of this 607 specification. 609 4.1. BP Fundamental Data Structures 611 4.1.1. CRC Type 613 CRC type is an unsigned integer type code for which the following 614 values (and no others) are valid: 616 . 0 indicates "no CRC is present." 617 . 1 indicates "a standard X-25 CRC-16 is present." [CRC16] 618 . 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present." 619 [RFC4960] 621 CRC type SHALL be represented as a CBOR unsigned integer. 623 For examples of CRC32C CRCs, see Appendix A.4 of [RFC7143]. 625 Note that more robust protection of BP data integrity, as needed, 626 may be provided by means of Block Integrity Blocks as defined in the 627 Bundle Security Protocol [BPSEC]). 629 4.1.2. CRC 631 CRC SHALL be omitted from a block if and only if the block's CRC 632 type code is zero. 634 When not omitted, the CRC SHALL be represented as a CBOR byte string 635 of two bytes (that is, CBOR additional information 2, if CRC type is 636 1) or of four bytes (that is, CBOR additional information 4, if CRC 637 type is 2); in each case the sequence of bytes SHALL constitute an 638 unsigned integer value (of 16 or 32 bits, respectively) in network 639 byte order. 641 4.1.3. Bundle Processing Control Flags 643 Bundle processing control flags assert properties of the bundle as a 644 whole rather than of any particular block of the bundle. They are 645 conveyed in the primary block of the bundle. 647 The following properties are asserted by the bundle processing 648 control flags: 650 . The bundle is a fragment. (Boolean) 652 . The bundle's payload is an administrative record. (Boolean) 654 . The bundle must not be fragmented. (Boolean) 655 . Acknowledgment by the user application is requested. (Boolean) 657 . Status time is requested in all status reports. (Boolean) 659 . Flags requesting types of status reports (all Boolean): 661 o Request reporting of bundle reception. 663 o Request reporting of bundle forwarding. 665 o Request reporting of bundle delivery. 667 o Request reporting of bundle deletion. 669 If the bundle processing control flags indicate that the bundle's 670 application data unit is an administrative record, then all status 671 report request flag values MUST be zero. 673 If the bundle's source node is omitted (i.e., the source node ID is 674 the ID of the null endpoint, which has no members as discussed 675 below; this option enables anonymous bundle transmission), then the 676 bundle is not uniquely identifiable and all bundle protocol features 677 that rely on bundle identity must therefore be disabled: the "Bundle 678 must not be fragmented" flag value MUST be 1 and all status report 679 request flag values MUST be zero. 681 Bundle processing control flags that are unrecognized MUST be 682 ignored, as future definitions of additional flags might not be 683 integrated simultaneously into the Bundle Protocol implementations 684 operating at all nodes. 686 The bundle processing control flags SHALL be represented as a CBOR 687 unsigned integer item, the value of which SHALL be processed as a 688 bit field indicating the control flag values as follows (note that 689 bit numbering in this instance is reversed from the usual practice, 690 beginning with the low-order bit instead of the high-order bit, in 691 recognition of the potential definition of additional control flag 692 values in the future): 694 . Bit 0 (the low-order bit, 0x000001): bundle is a fragment. 695 . Bit 1 (0x000002): payload is an administrative record. 696 . Bit 2 (0x000004): bundle must not be fragmented. 697 . Bit 3 (0x000008): reserved. 698 . Bit 4 (0x000010): reserved. 699 . Bit 5 (0x000020): user application acknowledgement is 700 requested. 702 . Bit 6 (0x000040): status time is requested in all status 703 reports. 704 . Bit 7 (0x000080): reserved. 705 . Bit 8 (0x000100): reserved. 706 . Bit 9 (0x000200): reserved. 707 . Bit 10(0x000400): reserved. 708 . Bit 11(0x000800): reserved. 709 . Bit 12(0x001000): reserved. 710 . Bit 13(0x002000): reserved. 711 . Bit 14(0x004000): bundle reception status reports are 712 requested. 713 . Bit 15(0x008000): reserved. 714 . Bit 16(0x010000): bundle forwarding status reports are 715 requested. 716 . Bit 17(0x020000): bundle delivery status reports are requested. 717 . Bit 18(0x040000): bundle deletion status reports are requested. 718 . Bits 19-20 are reserved. 719 . Bits 21-63 are unassigned. 721 4.1.4. Block Processing Control Flags 723 The block processing control flags assert properties of canonical 724 bundle blocks. They are conveyed in the header of the block to 725 which they pertain. 727 Block processing control flags that are unrecognized MUST be 728 ignored, as future definitions of additional flags might not be 729 integrated simultaneously into the Bundle Protocol implementations 730 operating at all nodes. 732 The block processing control flags SHALL be represented as a CBOR 733 unsigned integer item, the value of which SHALL be processed as a 734 bit field indicating the control flag values as follows (note that 735 bit numbering in this instance is reversed from the usual practice, 736 beginning with the low-order bit instead of the high-order bit, for 737 agreement with the bit numbering of the bundle processing control 738 flags): 740 . Bit 0(the low-order bit, 0x01): block must be replicated in 741 every fragment. 742 . Bit 1(0x02): transmission of a status report is requested if 743 block can't be processed. 744 . Bit 2(0x04): bundle must be deleted if block can't be 745 processed. 746 . Bit 3(0x08): reserved. 747 . Bit 4(0x10): block must be removed from bundle if it can't be 748 processed. 750 . Bit 5(0x20): reserved. 751 . Bit 6 (0x40): reserved. 752 . Bits 7-63 are unassigned. 754 For each bundle whose bundle processing control flags indicate that 755 the bundle's application data unit is an administrative record, or 756 whose source node ID is the null endpoint ID as defined below, the 757 value of the "Transmit status report if block can't be processed" 758 flag in every canonical block of the bundle MUST be zero. 760 4.1.5. Identifiers 762 4.1.5.1. Endpoint ID 764 The destinations of bundles are bundle endpoints, identified by text 765 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 766 (EID) is a Uniform Resource Identifier (URI; [URI]). As such, each 767 endpoint ID can be characterized as having this general structure: 769 < scheme name > : < scheme-specific part, or "SSP" > 771 The scheme identified by the < scheme name > in an endpoint ID is a 772 set of syntactic and semantic rules that fully explain how to parse 773 and interpret the SSP. Each scheme that may be used to form a BP 774 endpoint ID must be added to the registry of URI scheme code numbers 775 for Bundle Protocol maintained by IANA as described in Section 10; 776 association of a unique URI scheme code number with each scheme name 777 in this registry helps to enable compact representation of endpoint 778 IDs in bundle blocks. Note that the set of allowable schemes is 779 effectively unlimited. Any scheme conforming to [URIREG] may be 780 added to the URI scheme code number registry and thereupon used in a 781 bundle protocol endpoint ID. 783 Each entry in the URI scheme code number registry MUST contain a 784 reference to a scheme code number definition document, which defines 785 the manner in which the scheme-specific part of any URI formed in 786 that scheme is parsed and interpreted and MUST be encoded, in CBOR 787 representation, for transmission as a BP endpoint ID. The scheme 788 code number definition document may also contain information as to 789 (a) which convergence-layer protocol(s) may be used to forward a 790 bundle to a BP destination endpoint identified by such an ID, and 791 (b) how the ID of the convergence-layer protocol endpoint to use for 792 that purpose can be inferred from that destination endpoint ID. 794 Note that, although endpoint IDs are URIs, implementations of the BP 795 service interface may support expression of endpoint IDs in some 796 internationalized manner (e.g., Internationalized Resource 797 Identifiers (IRIs); see [RFC3987]). 799 Each BP endpoint ID (EID) SHALL be represented as a CBOR array 800 comprising two items. 802 The first item of the array SHALL be the code number identifying the 803 endpoint ID's URI scheme, as defined in the registry of URI scheme 804 code numbers for Bundle Protocol. Each URI scheme code number SHALL 805 be represented as a CBOR unsigned integer. 807 The second item of the array SHALL be the applicable CBOR 808 representation of the scheme-specific part (SSP) of the EID, defined 809 as noted in the references(s) for the URI scheme code number 810 registry entry for the EID's URI scheme. 812 4.1.5.1.1. The "dtn" URI scheme 814 The "dtn" scheme supports the identification of BP endpoints by 815 arbitrarily expressive character strings. It is specified as 816 follows: 818 Scheme syntax: This specification uses the Augmented Backus-Naur 819 Form (ABNF) notation of [RFC5234]. 821 dtn-uri = "dtn:" ("none" / dtn-hier-part) 823 dtn-hier-part = "//" node-name name-delim demux ; a path-rootless 825 node-name = 1*(ALPHA/DIGIT/"-"/"."/"_") reg-name 827 name-delim = "/" 829 demux = *VCHAR 831 Scheme semantics: URIs of the dtn scheme are used as endpoint 832 identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol 833 (BP) as described in the present document. 835 The endpoint ID "dtn:none" identifies the "null endpoint", the 836 endpoint that by definition never has any members. 838 All BP endpoints identified by all other dtn-scheme endpoint IDs for 839 which the first character of demux is a character other than '~' 840 (tilde) are singleton endpoints. All BP endpoints identified by dtn- 841 scheme endpoint IDs for which the first character *is* '~' (tilde) 842 are *not* singleton endpoints. 844 A dtn-scheme endpoint ID for which the demux is of length zero MAY 845 identify the administrative endpoint for the node identified by 846 node-name, and as such may serve as a node ID. No dtn-scheme 847 endpoint ID for which the demux is of non-zero length may do so. 849 Note that these syntactic rules impose constraints on dtn-scheme 850 endpoint IDs that were not imposed by the original specification of 851 the dtn scheme as provided in [RFC5050]. It is believed that the 852 dtn-scheme endpoint IDs employed by BP applications conforming to 853 [RFC5050] are in most cases unlikely to be in violation of these 854 rules, but the developers of such applications are advised of the 855 potential for compromised interoperation. 857 Encoding considerations: For transmission as a BP endpoint ID, the 858 scheme-specific part of a URI of the dtn scheme SHALL be represented 859 as a CBOR text string unless the EID's SSP is "none", in which case 860 the SSP SHALL be represented as a CBOR unsigned integer with the 861 value zero. For all other purposes, URIs of the dtn scheme are 862 encoded exclusively in US-ASCII characters. 864 Interoperability considerations: none. 866 Security considerations: 868 . Reliability and consistency: none of the BP endpoints 869 identified by the URIs of the DTN scheme are guaranteed to be 870 reachable at any time, and the identity of the processing 871 entities operating on those endpoints is never guaranteed by 872 the Bundle Protocol itself. Bundle authentication as defined by 873 the Bundle Security Protocol is required for this purpose. 874 . Malicious construction: malicious construction of a conformant 875 DTN-scheme URI is limited to the malicious selection of node 876 names and the malicious selection of demux strings. That is, a 877 maliciously constructed DTN-scheme URI could be used to direct 878 a bundle to an endpoint that might be damaged by the arrival of 879 that bundle or, alternatively, to declare a false source for a 880 bundle and thereby cause incorrect processing at a node that 881 receives the bundle. In both cases (and indeed in all bundle 882 processing), the node that receives a bundle should verify its 883 authenticity and validity before operating on it in any way. 884 . Back-end transcoding: the limited expressiveness of URIs of the 885 DTN scheme effectively eliminates the possibility of threat due 886 to errors in back-end transcoding. 887 . Rare IP address formats: not relevant, as IP addresses do not 888 appear anywhere in conformant DTN-scheme URIs. 889 . Sensitive information: because DTN-scheme URIs are used only to 890 represent the identities of Bundle Protocol endpoints, the risk 891 of disclosure of sensitive information due to interception of 892 these URIs is minimal. Examination of DTN-scheme URIs could be 893 used to support traffic analysis; where traffic analysis is a 894 plausible danger, bundles should be conveyed by secure 895 convergence-layer protocols that do not expose endpoint IDs. 896 . Semantic attacks: the simplicity of DTN-scheme URI syntax 897 minimizes the possibility of misinterpretation of a URI by a 898 human user. 900 4.1.5.1.2. The "ipn" URI scheme 902 The "ipn" scheme supports the identification of BP endpoints by 903 pairs of unsigned integers, for compact representation in bundle 904 blocks. It is specified as follows: 906 Scheme syntax: This specification uses the Augmented Backus-Naur 907 Form (ABNF) notation of [RFC5234], including the core ABNF syntax 908 rule for DIGIT defined by that specification. 910 ipn-uri = "ipn:" ipn-hier-part 912 ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless 914 node-nbr = 1*DIGIT 916 nbr-delim = "." 918 service-nbr = 1*DIGIT 920 Scheme semantics: URIs of the ipn scheme are used as endpoint 921 identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol 922 (BP) as described in the present document. 924 All BP endpoints identified by ipn-scheme endpoint IDs are singleton 925 endpoints. 927 An ipn-scheme endpoint ID for which service-nbr is zero MAY identify 928 the administrative endpoint for the node identified by node-nbr, and 929 as such may serve as a node ID. No ipn-scheme endpoint ID for which 930 service-nbr is non-zero may do so. 932 Encoding considerations: For transmission as a BP endpoint ID, the 933 scheme-specific part of a URI of the dtn scheme the SSP SHALL be 934 represented as a CBOR array comprising two items. The first item of 935 this array SHALL be the EID's node number (a number that identifies 936 the node) represented as a CBOR unsigned integer. The second item 937 of this array SHALL be the EID's service number (a number that 938 identifies some application service) represented as a CBOR unsigned 939 integer. For all other purposes, URIs of the IPN scheme are encoded 940 exclusively in US-ASCII characters. 942 Interoperability considerations: none. 944 Security considerations: 946 . Reliability and consistency: none of the BP endpoints 947 identified by the URIs of the IPN scheme are guaranteed to be 948 reachable at any time, and the identity of the processing 949 entities operating on those endpoints is never guaranteed by 950 the Bundle Protocol itself. Bundle authentication as defined by 951 the Bundle Security Protocol [BPSEC] is required for this 952 purpose. 953 . Malicious construction: malicious construction of a conformant 954 IPN-scheme URI is limited to the malicious selection of node 955 numbers and the malicious selection of service numbers. That 956 is, a maliciously constructed IPN-scheme URI could be used to 957 direct a bundle to an endpoint that might be damaged by the 958 arrival of that bundle or, alternatively, to declare a false 959 source for a bundle and thereby cause incorrect processing at a 960 node that receives the bundle. In both cases (and indeed in 961 all bundle processing), the node that receives a bundle should 962 verify its authenticity and validity before operating on it in 963 any way. 964 . Back-end transcoding: the limited expressiveness of URIs of the 965 IPN scheme effectively eliminates the possibility of threat due 966 to errors in back-end transcoding. 967 . Rare IP address formats: not relevant, as IP addresses do not 968 appear anywhere in conformant IPN-scheme URIs. 969 . Sensitive information: because IPN-scheme URIs are used only to 970 represent the identities of Bundle Protocol endpoints, the risk 971 of disclosure of sensitive information due to interception of 972 these URIs is minimal. Examination of IPN-scheme URIs could be 973 used to support traffic analysis; where traffic analysis is a 974 plausible danger, bundles should be conveyed by secure 975 convergence-layer protocols that do not expose endpoint IDs. 976 . Semantic attacks: the simplicity of IPN-scheme URI syntax 977 minimizes the possibility of misinterpretation of a URI by a 978 human user. 980 4.1.5.2. Node ID 982 For many purposes of the Bundle Protocol it is important to identify 983 the node that is operative in some context. 985 As discussed in 3.1 above, nodes are distinct from endpoints; 986 specifically, an endpoint is a set of zero or more nodes. But 987 rather than define a separate namespace for node identifiers, we 988 instead use endpoint identifiers to identify nodes as discussed in 989 3.2 above. Formally: 991 . Every node is, by definition, permanently registered in the 992 singleton endpoint at which administrative records are 993 delivered to its application agent's administrative element, 994 termed the node's "administrative endpoint". 995 . As such, the EID of a node's administrative endpoint SHALL 996 uniquely identify that node. 997 . A "node ID" is an EID that identifies the administrative 998 endpoint of a node. 1000 4.1.6. DTN Time 1002 A DTN time is an unsigned integer indicating the number of 1003 milliseconds that have elapsed since the start of the year 2000 on 1004 the Coordinated Universal Time (UTC) scale [UTC]. Each DTN time 1005 SHALL be represented as a CBOR unsigned integer item. 1007 Implementers need to be aware that DTN time values conveyed in CBOR 1008 representation in bundles will nearly always exceed (2**32 - 1). 1010 4.1.7. Creation Timestamp 1012 Each bundle's creation timestamp SHALL be represented as a CBOR 1013 array comprising two items. 1015 The first item of the array, termed "bundle creation time", SHALL be 1016 the DTN time at which the transmission request was received that 1017 resulted in the creation of the bundle, represented as a CBOR 1018 unsigned integer. 1020 The second item of the array, termed the creation timestamp's 1021 "sequence number", SHALL be the latest value (as of the time at 1022 which the transmission request was received) of a monotonically 1023 increasing positive integer counter managed by the source node's 1024 bundle protocol agent, represented as a CBOR unsigned integer. The 1025 sequence counter MAY be reset to zero whenever the current time 1026 advances by one millisecond. 1028 For nodes that lack accurate clocks, it is recommended that bundle 1029 creation time be set to zero and that the counter used as the source 1030 of the bundle sequence count never be reset to zero. 1032 Note that, in general, the creation of two distinct bundles with the 1033 same source node ID and bundle creation timestamp may result in 1034 unexpected network behavior and/or suboptimal performance. The 1035 combination of source node ID and bundle creation timestamp serves 1036 to identify a single transmission request, enabling it to be 1037 acknowledged by the receiving application (provided the source node 1038 ID is not the null endpoint ID). 1040 4.1.8. Block-type-specific Data 1042 Block-type-specific data in each block (other than the primary 1043 block) SHALL be the applicable CBOR representation of the content of 1044 the block. Details of this representation are included in the 1045 specification defining the block type. 1047 4.2. Bundle Representation 1049 This section describes the primary block in detail and non-primary 1050 blocks in general. Rules for processing these blocks appear in 1051 Section 5 of this document. 1053 Note that supplementary DTN protocol specifications (including, but 1054 not restricted to, the Bundle Security Protocol [BPSEC]) may require 1055 that BP implementations conforming to those protocols construct and 1056 process additional blocks. 1058 4.2.1. Bundle 1060 Each bundle SHALL be represented as a CBOR indefinite-length array. 1061 The first item of this array SHALL be the CBOR representation of a 1062 Primary Block. Every other item of the array SHALL be the CBOR 1063 representation of a Canonical Block. The last block of the bundle 1064 SHALL be followed by a CBOR "break" stop code, terminating the 1065 array. 1067 Associated with each block of a bundle is a block number. The block 1068 number uniquely identifies the block within the bundle, enabling 1069 blocks (notably bundle security protocol blocks) to reference other 1070 blocks in the same bundle without ambiguity. The block number of 1071 the primary block is implicitly zero; the block numbers of all other 1072 blocks are explicitly stated in block headers as noted below. Block 1073 numbering is unrelated to the order in which blocks are sequenced in 1074 the bundle. The block number of the payload block is always 1. 1076 4.2.2. Primary Bundle Block 1078 The primary bundle block contains the basic information needed to 1079 forward bundles to their destinations. 1081 Each primary block SHALL be represented as a CBOR array; the number 1082 of elements in the array SHALL be 8 (if the bundle is not a fragment 1083 and the block has no CRC), 9 (if the block has a CRC and the bundle 1084 is not a fragment), 10 (if the bundle is a fragment and the block 1085 has no CRC), or 11 (if the bundle is a fragment and the block has a 1086 CRC). 1088 The primary block of each bundle SHALL be immutable. The CBOR- 1089 encoded values of all fields in the primary block MUST remain 1090 unchanged from the time the block is created to the time it is 1091 delivered. 1093 The fields of the primary bundle block SHALL be as follows, listed 1094 in the order in which they MUST appear: 1096 Version: An unsigned integer value indicating the version of the 1097 bundle protocol that constructed this block. The present document 1098 describes version 7 of the bundle protocol. Version number SHALL be 1099 represented as a CBOR unsigned integer item. 1101 Bundle Processing Control Flags: The Bundle Processing Control Flags 1102 are discussed in Section 4.1.3. above. 1104 CRC Type: CRC Type codes are discussed in Section 4.1.1. above. The 1105 CRC Type code for the primary block MAY be zero if the bundle 1106 contains a BPsec [BPSEC] Block Integrity Block whose target is the 1107 primary block; otherwise the CRC Type code for the primary block 1108 MUST be non-zero. 1110 Destination EID: The Destination EID field identifies the bundle 1111 endpoint that is the bundle's destination, i.e., the endpoint that 1112 contains the node(s) at which the bundle is to be delivered. 1114 Source node ID: The Source node ID field identifies the bundle node 1115 at which the bundle was initially transmitted, except that Source 1116 node ID may be the null endpoint ID in the event that the bundle's 1117 source chooses to remain anonymous. 1119 Report-to EID: The Report-to EID field identifies the bundle 1120 endpoint to which status reports pertaining to the forwarding and 1121 delivery of this bundle are to be transmitted. 1123 Creation Timestamp: The creation timestamp (discussed in 4.1.7 1124 above) comprises two unsigned integers that, together with the 1125 source node ID and (if the bundle is a fragment) the fragment offset 1126 and payload length, serve to identify the bundle. The first of these 1127 integers is the bundle's creation time, while the second is the 1128 bundle's creation timestamp sequence number. Bundle creation time 1129 SHALL be the DTN time at which the transmission request was received 1130 that resulted in the creation of the bundle. Sequence count SHALL be 1131 the latest value (as of the time at which that transmission request 1132 was received) of a monotonically increasing positive integer counter 1133 managed by the source node's bundle protocol agent that MAY be reset 1134 to zero whenever the current time advances by one millisecond. For 1135 nodes that lack accurate clocks, it is recommended that bundle 1136 creation time be set to zero and that the counter used as the source 1137 of the bundle sequence count never be reset to zero. Note that, in 1138 general, the creation of two distinct bundles with the same source 1139 node ID and bundle creation timestamp may result in unexpected 1140 network behavior and/or suboptimal performance. The combination of 1141 source node ID and bundle creation timestamp serves to identify a 1142 single transmission request, enabling it to be acknowledged by the 1143 receiving application (provided the source node ID is not the null 1144 endpoint ID). 1146 Lifetime: The lifetime field is an unsigned integer that indicates 1147 the time at which the bundle's payload will no longer be useful, 1148 encoded as a number of milliseconds past the creation time. (For 1149 high-rate deployments with very brief disruptions, fine-grained 1150 expression of bundle lifetime may be useful.) When a bundle's age 1151 exceeds its lifetime, bundle nodes need no longer retain or forward 1152 the bundle; the bundle SHOULD be deleted from the network. 1154 If the asserted lifetime for a received bundle is so lengthy that 1155 retention of the bundle until its expiration time might degrade 1156 operation of the node at which the bundle is received, or if the 1157 bundle protocol agent of that node determines that the bundle must 1158 be deleted in order to prevent network performance degradation 1159 (e.g., the bundle appears to be part of a denial-of-service attack), 1160 then that bundle protocol agent MAY impose a temporary overriding 1161 lifetime of shorter duration; such overriding lifetime SHALL NOT 1162 replace the lifetime asserted in the bundle but SHALL serve as the 1163 bundle's effective lifetime while the bundle resides at that node. 1164 Procedures for imposing lifetime overrides are beyond the scope of 1165 this specification. 1167 For bundles originating at nodes that lack accurate clocks, it is 1168 recommended that bundle age be obtained from the Bundle Age 1169 extension block (see 4.3.2 below) rather than from the difference 1170 between current time and bundle creation time. Bundle lifetime 1171 SHALL be represented as a CBOR unsigned integer item. 1173 Fragment offset: If and only if the Bundle Processing Control Flags 1174 of this Primary block indicate that the bundle is a fragment, 1175 fragment offset SHALL be present in the primary block. Fragment 1176 offset SHALL be represented as a CBOR unsigned integer indicating 1177 the offset from the start of the original application data unit at 1178 which the bytes comprising the payload of this bundle were located. 1180 Total Application Data Unit Length: If and only if the Bundle 1181 Processing Control Flags of this Primary block indicate that the 1182 bundle is a fragment, total application data unit length SHALL be 1183 present in the primary block. Total application data unit length 1184 SHALL be represented as a CBOR unsigned integer indicating the total 1185 length of the original application data unit of which this bundle's 1186 payload is a part. 1188 CRC: A CRC SHALL be present in the primary block unless the bundle 1189 includes a BPsec [BPSEC] Block Integrity Block whose target is the 1190 primary block, in which case a CRC MAY be present in the primary 1191 block. The length and nature of the CRC SHALL be as indicated by 1192 the CRC type. The CRC SHALL be computed over the concatenation of 1193 all bytes (including CBOR "break" characters) of the primary block 1194 including the CRC field itself, which for this purpose SHALL be 1195 temporarily populated with all bytes set to zero. 1197 4.2.3. Canonical Bundle Block Format 1199 Every block other than the primary block (all such blocks are termed 1200 "canonical" blocks) SHALL be represented as a CBOR array; the number 1201 of elements in the array SHALL be 5 (if CRC type is zero) or 6 1202 (otherwise). 1204 The fields of every canonical block SHALL be as follows, listed in 1205 the order in which they MUST appear: 1207 . Block type code, an unsigned integer. Bundle block type code 1 1208 indicates that the block is a bundle payload block. Block type 1209 codes 2 through 9 are explicitly reserved as noted later in 1210 this specification. Block type codes 192 through 255 are not 1211 reserved and are available for private and/or experimental use. 1212 All other block type code values are reserved for future use. 1213 . Block number, an unsigned integer as discussed in 4.2.1 above. 1214 Block number SHALL be represented as a CBOR unsigned integer. 1215 . Block processing control flags as discussed in Section 4.1.4 1216 above. 1218 . CRC type as discussed in Section 4.1.1 above. 1219 . Block-type-specific data represented as a single definite- 1220 length CBOR byte string, i.e., a CBOR byte string that is not 1221 of indefinite length. For each type of block, the block-type- 1222 specific data byte string is the serialization, in a block- 1223 type-specific manner, of the data conveyed by that type of 1224 block; definitions of blocks are required to define the manner 1225 in which block-type-specific data are serialized within the 1226 block-type-specific data field. For the Payload Block in 1227 particular (block type 1), the block-type-specific data field, 1228 termed the "payload", SHALL be an application data unit, or 1229 some contiguous extent thereof, represented as a definite- 1230 length CBOR byte string. 1231 . If and only if the value of the CRC type field of this block is 1232 non-zero, a CRC. If present, the length and nature of the CRC 1233 SHALL be as indicated by the CRC type and the CRC SHALL be 1234 computed over the concatenation of all bytes of the block 1235 (including CBOR "break" characters) including the CRC field 1236 itself, which for this purpose SHALL be temporarily populated 1237 with all bytes set to zero. 1239 4.3. Extension Blocks 1241 "Extension blocks" are all blocks other than the primary and payload 1242 blocks. Because not all extension blocks are defined in the Bundle 1243 Protocol specification (the present document), not all nodes 1244 conforming to this specification will necessarily instantiate Bundle 1245 Protocol implementations that include procedures for processing 1246 (that is, recognizing, parsing, acting on, and/or producing) all 1247 extension blocks. It is therefore possible for a node to receive a 1248 bundle that includes extension blocks that the node cannot process. 1249 The values of the block processing control flags indicate the action 1250 to be taken by the bundle protocol agent when this is the case. 1252 The following extension blocks are defined in the current document. 1254 4.3.1. Previous Node 1256 The Previous Node block, block type 6, identifies the node that 1257 forwarded this bundle to the local node (i.e., to the node at which 1258 the bundle currently resides); its block-type-specific data is the 1259 node ID of that forwarder node which SHALL take the form of a node 1260 ID represented as described in Section 4.1.5.2. above. If the local 1261 node is the source of the bundle, then the bundle MUST NOT contain 1262 any Previous Node block. Otherwise the bundle SHOULD contain one 1263 (1) occurrence of this type of block and MUST NOT contain more than 1264 one. 1266 4.3.2. Bundle Age 1268 The Bundle Age block, block type 7, contains the number of 1269 milliseconds that have elapsed between the time the bundle was 1270 created and time at which it was most recently forwarded. It is 1271 intended for use by nodes lacking access to an accurate clock, to 1272 aid in determining the time at which a bundle's lifetime expires. 1273 The block-type-specific data of this block is an unsigned integer 1274 containing the age of the bundle in milliseconds, which SHALL be 1275 represented as a CBOR unsigned integer item. (The age of the bundle 1276 is the sum of all known intervals of the bundle's residence at 1277 forwarding nodes, up to the time at which the bundle was most 1278 recently forwarded, plus the summation of signal propagation time 1279 over all episodes of transmission between forwarding nodes. 1280 Determination of these values is an implementation matter.) If the 1281 bundle's creation time is zero, then the bundle MUST contain exactly 1282 one (1) occurrence of this type of block; otherwise, the bundle MAY 1283 contain at most one (1) occurrence of this type of block. A bundle 1284 MUST NOT contain multiple occurrences of the bundle age block, as 1285 this could result in processing anomalies. 1287 4.3.3. Hop Count 1289 The Hop Count block, block type 10, contains two unsigned integers, 1290 hop limit and hop count. A "hop" is here defined as an occasion on 1291 which a bundle was forwarded from one node to another node. Hop 1292 limit MUST be in the range 1 through 255. The hop limit value SHOULD 1293 NOT be changed at any time after creation of the Hop Count block; 1294 the hop count value SHOULD initially be zero and SHOULD be increased 1295 by 1 on each hop. 1297 The hop count block is mainly intended as a safety mechanism, a 1298 means of identifying bundles for removal from the network that can 1299 never be delivered due to a persistent forwarding error. Hop count 1300 is particularly valuable as a defense against routing anomalies that 1301 might cause a bundle to be forwarded in a cyclical "ping-pong" 1302 fashion between two nodes. When a bundle's hop count exceeds its 1303 hop limit, the bundle SHOULD be deleted for the reason "hop limit 1304 exceeded", following the bundle deletion procedure defined in 1305 Section 5.10. 1307 Procedures for determining the appropriate hop limit for a bundle 1308 are beyond the scope of this specification. 1310 The block-type-specific data in a hop count block SHALL be 1311 represented as a CBOR array comprising two items. The first item of 1312 this array SHALL be the bundle's hop limit, represented as a CBOR 1313 unsigned integer. The second item of this array SHALL be the 1314 bundle's hop count, represented as a CBOR unsigned integer. A bundle 1315 MAY contain one occurrence of this type of block but MUST NOT 1316 contain more than one. 1318 5. Bundle Processing 1320 The bundle processing procedures mandated in this section and in 1321 Section 6 govern the operation of the Bundle Protocol Agent and the 1322 Application Agent administrative element of each bundle node. They 1323 are neither exhaustive nor exclusive. Supplementary DTN protocol 1324 specifications (including, but not restricted to, the Bundle 1325 Security Protocol [BPSEC]) may augment, override, or supersede the 1326 mandates of this document. 1328 5.1. Generation of Administrative Records 1330 All transmission of bundles is in response to bundle transmission 1331 requests presented by nodes' application agents. When required to 1332 "generate" an administrative record (such as a bundle status 1333 report), the bundle protocol agent itself is responsible for causing 1334 a new bundle to be transmitted, conveying that record. In concept, 1335 the bundle protocol agent discharges this responsibility by 1336 directing the administrative element of the node's application agent 1337 to construct the record and request its transmission as detailed in 1338 Section 6 below. In practice, the manner in which administrative 1339 record generation is accomplished is an implementation matter, 1340 provided the constraints noted in Section 6 are observed. 1342 Status reports are relatively small bundles. Moreover, even when 1343 the generation of status reports is enabled the decision on whether 1344 or not to generate a requested status report is left to the 1345 discretion of the bundle protocol agent. Nonetheless, note that 1346 requesting status reports for any single bundle might easily result 1347 in the generation of (1 + (2 *(N-1))) status report bundles, where N 1348 is the number of nodes on the path from the bundle's source to its 1349 destination, inclusive. That is, the requesting of status reports 1350 for large numbers of bundles could result in an unacceptable 1351 increase in the bundle traffic in the network. For this reason, the 1352 generation of status reports MUST be disabled by default and enabled 1353 only when the risk of excessive network traffic is deemed 1354 acceptable. Mechanisms that could assist in assessing and 1355 mitigating this risk, such as pre-placed agreements authorizing the 1356 generation of status reports under specified circumstances, are 1357 beyond the scope of this specification. 1359 Notes on administrative record terminology: 1361 . A "bundle reception status report" is a bundle status report 1362 with the "reporting node received bundle" flag set to 1. 1363 . A "bundle forwarding status report" is a bundle status report 1364 with the "reporting node forwarded the bundle" flag set to 1. 1365 . A "bundle delivery status report" is a bundle status report 1366 with the "reporting node delivered the bundle" flag set to 1. 1367 . A "bundle deletion status report" is a bundle status report 1368 with the "reporting node deleted the bundle" flag set to 1. 1370 5.2. Bundle Transmission 1372 The steps in processing a bundle transmission request are: 1374 Step 1: Transmission of the bundle is initiated. An outbound bundle 1375 MUST be created per the parameters of the bundle transmission 1376 request, with the retention constraint "Dispatch pending". The 1377 source node ID of the bundle MUST be either the null endpoint ID, 1378 indicating that the source of the bundle is anonymous, or else the 1379 EID of a singleton endpoint whose only member is the node of which 1380 the BPA is a component. 1382 Step 2: Processing proceeds from Step 1 of Section 5.4. 1384 5.3. Bundle Dispatching 1386 The steps in dispatching a bundle are: 1388 Step 1: If the bundle's destination endpoint is an endpoint of which 1389 the node is a member, the bundle delivery procedure defined in 1390 Section 5.7 MUST be followed and for the purposes of all subsequent 1391 processing of this bundle at this node the node's membership in the 1392 bundle's destination endpoint SHALL be disavowed; specifically, even 1393 though the node is a member of the bundle's destination endpoint, 1394 the node SHALL NOT undertake to forward the bundle to itself in the 1395 course of performing the procedure described in Section 5.4. 1397 Step 2: Processing proceeds from Step 1 of Section 5.4. 1399 5.4. Bundle Forwarding 1401 The steps in forwarding a bundle are: 1403 Step 1: The retention constraint "Forward pending" MUST be added to 1404 the bundle, and the bundle's "Dispatch pending" retention constraint 1405 MUST be removed. 1407 Step 2: The bundle protocol agent MUST determine whether or not 1408 forwarding is contraindicated (that is, rendered inadvisable) for 1409 any of the reasons listed in the IANA registry of Bundle Status 1410 Report Reason Codes (see section 10.5 below), whose initial contents 1411 are listed in Figure 4. In particular: 1413 . The bundle protocol agent MAY choose either to forward the 1414 bundle directly to its destination node(s) (if possible) or to 1415 forward the bundle to some other node(s) for further 1416 forwarding. The manner in which this decision is made may 1417 depend on the scheme name in the destination endpoint ID and/or 1418 on other state but in any case is beyond the scope of this 1419 document; one possible mechanism is described in [SABR]. If the 1420 BPA elects to forward the bundle to some other node(s) for 1421 further forwarding but finds it impossible to select any 1422 node(s) to forward the bundle to, then forwarding is 1423 contraindicated. 1424 . Provided the bundle protocol agent succeeded in selecting the 1425 node(s) to forward the bundle to, the bundle protocol agent 1426 MUST subsequently select the convergence layer adapter(s) whose 1427 services will enable the node to send the bundle to those 1428 nodes. The manner in which specific appropriate convergence 1429 layer adapters are selected is beyond the scope of this 1430 document; the TCP convergence-layer adapter [TCPCL] MUST be 1431 implemented when some or all of the bundles forwarded by the 1432 bundle protocol agent must be forwarded via the Internet but 1433 may not be appropriate for the forwarding of any particular 1434 bundle. If the agent finds it impossible to select any 1435 appropriate convergence layer adapter(s) to use in forwarding 1436 this bundle, then forwarding is contraindicated. 1438 Step 3: If forwarding of the bundle is determined to be 1439 contraindicated for any of the reasons listed in the IANA registry 1440 of Bundle Status Report Reason Codes (see section 10.5 below), then 1441 the Forwarding Contraindicated procedure defined in Section 5.4.1 1442 MUST be followed; the remaining steps of Section 5.4 are skipped at 1443 this time. 1445 Step 4: For each node selected for forwarding, the bundle protocol 1446 agent MUST invoke the services of the selected convergence layer 1447 adapter(s) in order to effect the sending of the bundle to that 1448 node. Determining the time at which the bundle protocol agent 1449 invokes convergence layer adapter services is a BPA implementation 1450 matter. Determining the time at which each convergence layer 1451 adapter subsequently responds to this service invocation by sending 1452 the bundle is a convergence-layer adapter implementation matter. 1453 Note that: 1455 . If the bundle has a Previous Node block, as defined in 4.3.1 1456 above, then that block MUST be removed from the bundle before 1457 the bundle is forwarded. 1458 . If the bundle protocol agent is configured to attach Previous 1459 Node blocks to forwarded bundles, then a Previous Node block 1460 containing the node ID of the forwarding node MUST be inserted 1461 into the bundle before the bundle is forwarded. 1462 . If the bundle has a bundle age block, as defined in 4.3.2. 1463 above, then at the last possible moment before the CLA 1464 initiates conveyance of the bundle via the CL protocol the 1465 bundle age value MUST be increased by the difference between 1466 the current time and the time at which the bundle was received 1467 (or, if the local node is the source of the bundle, created). 1469 Step 5: When all selected convergence layer adapters have informed 1470 the bundle protocol agent that they have concluded their data 1471 sending procedures with regard to this bundle, processing may depend 1472 on the results of those procedures. 1474 If completion of the data sending procedures by all selected 1475 convergence layer adapters has not resulted in successful forwarding 1476 of the bundle (an implementation-specific determination that is 1477 beyond the scope of this specification), then the bundle protocol 1478 agent MAY choose (in an implementation-specific manner, again beyond 1479 the scope of this specification) to initiate another attempt to 1480 forward the bundle. In that event, processing proceeds from Step 4. 1481 The minimum number of times a given node will initiate another 1482 forwarding attempt for any single bundle in this event (a number 1483 which may be zero) is a node configuration parameter that must be 1484 exposed to other nodes in the network to the extent that this is 1485 required by the operating environment. 1487 If completion of the data sending procedures by all selected 1488 convergence layer adapters HAS resulted in successful forwarding of 1489 the bundle, or if it has not but the bundle protocol agent does not 1490 choose to initiate another attempt to forward the bundle, then: 1492 . If the "request reporting of bundle forwarding" flag in the 1493 bundle's status report request field is set to 1, and status 1494 reporting is enabled, then a bundle forwarding status report 1495 SHOULD be generated, destined for the bundle's report-to 1496 endpoint ID. The reason code on this bundle forwarding status 1497 report MUST be "no additional information". 1498 . If any applicable bundle protocol extensions mandate generation 1499 of status reports upon conclusion of convergence-layer data 1500 sending procedures, all such status reports SHOULD be generated 1501 with extension-mandated reason codes. 1503 . The bundle's "Forward pending" retention constraint MUST be 1504 removed. 1506 5.4.1. Forwarding Contraindicated 1508 The steps in responding to contraindication of forwarding are: 1510 Step 1: The bundle protocol agent MUST determine whether or not to 1511 declare failure in forwarding the bundle. Note: this decision is 1512 likely to be influenced by the reason for which forwarding is 1513 contraindicated. 1515 Step 2: If forwarding failure is declared, then the Forwarding 1516 Failed procedure defined in Section 5.4.2 MUST be followed. 1518 Otherwise, when - at some future time - the forwarding of this 1519 bundle ceases to be contraindicated, processing proceeds from Step 4 1520 of Section 5.4. 1522 5.4.2. Forwarding Failed 1524 The steps in responding to a declaration of forwarding failure are: 1526 Step 1: The bundle protocol agent MAY forward the bundle back to the 1527 node that sent it, as identified by the Previous Node block, if 1528 present. This forwarding, if performed, SHALL be accomplished by 1529 performing Step 4 and Step 5 of section 5.4 where the sole node 1530 selected for forwarding SHALL be the node that sent the bundle. 1532 Step 2: If the bundle's destination endpoint is an endpoint of which 1533 the node is a member, then the bundle's "Forward pending" retention 1534 constraint MUST be removed. Otherwise, the bundle MUST be deleted: 1535 the bundle deletion procedure defined in Section 5.10 MUST be 1536 followed, citing the reason for which forwarding was determined to 1537 be contraindicated. 1539 5.5. Bundle Expiration 1541 A bundle expires when the bundle's age exceeds its lifetime as 1542 specified in the primary bundle block or as overridden by the bundle 1543 protocol agent. Bundle age MAY be determined by subtracting the 1544 bundle's creation timestamp time from the current time if (a) that 1545 timestamp time is not zero and (b) the local node's clock is known 1546 to be accurate; otherwise bundle age MUST be obtained from the 1547 Bundle Age extension block. Bundle expiration MAY occur at any 1548 point in the processing of a bundle. When a bundle expires, the 1549 bundle protocol agent MUST delete the bundle for the reason 1550 "lifetime expired" (when the expired lifetime is the lifetime as 1551 specified in the primary block) or "traffic pared" (when the expired 1552 lifetime is a lifetime override as imposed by the bundle protocol 1553 agent): the bundle deletion procedure defined in Section 5.10 MUST 1554 be followed. 1556 5.6. Bundle Reception 1558 The steps in processing a bundle that has been received from another 1559 node are: 1561 Step 1: The retention constraint "Dispatch pending" MUST be added to 1562 the bundle. 1564 Step 2: If the "request reporting of bundle reception" flag in the 1565 bundle's status report request field is set to 1, and status 1566 reporting is enabled, then a bundle reception status report with 1567 reason code "No additional information" SHOULD be generated, 1568 destined for the bundle's report-to endpoint ID. 1570 Step 3: CRCs SHOULD be computed for every block of the bundle that 1571 has an attached CRC. If any block of the bundle is malformed 1572 according to this specification (including syntactically invalid 1573 CBOR), or if any block has an attached CRC and the CRC computed for 1574 this block upon reception differs from that attached CRC, then the 1575 bundle protocol agent MUST delete the bundle for the reason "Block 1576 unintelligible". The bundle deletion procedure defined in Section 1577 5.10 MUST be followed and all remaining steps of the bundle 1578 reception procedure MUST be skipped. 1580 Step 4: For each block in the bundle that is an extension block that 1581 the bundle protocol agent cannot process: 1583 . If the block processing flags in that block indicate that a 1584 status report is requested in this event, and status reporting 1585 is enabled, then a bundle reception status report with reason 1586 code "Block unintelligible" SHOULD be generated, destined for 1587 the bundle's report-to endpoint ID. 1588 . If the block processing flags in that block indicate that the 1589 bundle must be deleted in this event, then the bundle protocol 1590 agent MUST delete the bundle for the reason "Block 1591 unintelligible"; the bundle deletion procedure defined in 1592 Section 5.10 MUST be followed and all remaining steps of the 1593 bundle reception procedure MUST be skipped. 1594 . If the block processing flags in that block do NOT indicate 1595 that the bundle must be deleted in this event but do indicate 1596 that the block must be discarded, then the bundle protocol 1597 agent MUST remove this block from the bundle. 1598 . If the block processing flags in that block indicate neither 1599 that the bundle must be deleted nor that that the block must be 1600 discarded, then processing continues with the next extension 1601 block that the bundle protocol agent cannot process, if any; 1602 otherwise, processing proceeds from step 5. 1604 Step 5: Processing proceeds from Step 1 of Section 5.3. 1606 5.7. Local Bundle Delivery 1608 The steps in processing a bundle that is destined for an endpoint of 1609 which this node is a member are: 1611 Step 1: If the received bundle is a fragment, the application data 1612 unit reassembly procedure described in Section 5.9 MUST be followed. 1613 If this procedure results in reassembly of the entire original 1614 application data unit, processing of the fragmentary bundle whose 1615 payload has been replaced by the reassembled application data unit 1616 (whether this bundle or a previously received fragment) proceeds 1617 from Step 2; otherwise, the retention constraint "Reassembly 1618 pending" MUST be added to the bundle and all remaining steps of this 1619 procedure MUST be skipped. 1621 Step 2: Delivery depends on the state of the registration whose 1622 endpoint ID matches that of the destination of the bundle: 1624 . An additional implementation-specific delivery deferral 1625 procedure MAY optionally be associated with the registration. 1626 . If the registration is in the Active state, then the bundle 1627 MUST be delivered automatically as soon as it is the next 1628 bundle that is due for delivery according to the BPA's bundle 1629 delivery scheduling policy, an implementation matter. 1630 . If the registration is in the Passive state, or if delivery of 1631 the bundle fails for some implementation-specific reason, then 1632 the registration's delivery failure action MUST be taken. 1633 Delivery failure action MUST be one of the following: 1635 o defer delivery of the bundle subject to this registration 1636 until (a) this bundle is the least recently received of 1637 all bundles currently deliverable subject to this 1638 registration and (b) either the registration is polled or 1639 else the registration is in the Active state, and also 1640 perform any additional delivery deferral procedure 1641 associated with the registration; or 1643 o abandon delivery of the bundle subject to this registration 1644 (as defined in 3.1. ). 1646 Step 3: As soon as the bundle has been delivered, if the "request 1647 reporting of bundle delivery" flag in the bundle's status report 1648 request field is set to 1 and bundle status reporting is enabled, 1649 then a bundle delivery status report SHOULD be generated, destined 1650 for the bundle's report-to endpoint ID. Note that this status report 1651 only states that the payload has been delivered to the application 1652 agent, not that the application agent has processed that payload. 1654 5.8. Bundle Fragmentation 1656 It may at times be advantageous for bundle protocol agents to reduce 1657 the sizes of bundles in order to forward them. This might be the 1658 case, for example, if a node to which a bundle is to be forwarded is 1659 accessible only via intermittent contacts and no upcoming contact is 1660 long enough to enable the forwarding of the entire bundle. 1662 The size of a bundle can be reduced by "fragmenting" the bundle. To 1663 fragment a bundle whose payload is of size M is to replace it with 1664 two "fragments" - new bundles with the same source node ID and 1665 creation timestamp as the original bundle - whose payloads are the 1666 first N and the last (M - N) bytes of the original bundle's payload, 1667 where 0 < N < M. 1669 Note that fragments are bundles and therefore may themselves be 1670 fragmented, so multiple episodes of fragmentation may in effect 1671 replace the original bundle with more than two fragments. (However, 1672 there is only one 'level' of fragmentation, as in IP fragmentation.) 1674 Any bundle whose primary block's bundle processing flags do NOT 1675 indicate that it must not be fragmented MAY be fragmented at any 1676 time, for any purpose, at the discretion of the bundle protocol 1677 agent. NOTE, however, that some combinations of bundle 1678 fragmentation, replication, and routing might result in unexpected 1679 traffic patterns. 1681 Fragmentation SHALL be constrained as follows: 1683 . The concatenation of the payloads of all fragments produced by 1684 fragmentation MUST always be identical to the payload of the 1685 fragmented bundle (that is, the bundle that is being 1686 fragmented). Note that the payloads of fragments resulting from 1687 different fragmentation episodes, in different parts of the 1688 network, may be overlapping subsets of the fragmented bundle's 1689 payload. 1691 . The primary block of each fragment MUST differ from that of the 1692 fragmented bundle, in that the bundle processing flags of the 1693 fragment MUST indicate that the bundle is a fragment and both 1694 fragment offset and total application data unit length must be 1695 provided. Additionally, the CRC of the primary block of the 1696 fragmented bundle, if any, MUST be replaced in each fragment by 1697 a new CRC computed for the primary block of that fragment. 1698 . The payload blocks of fragments will differ from that of the 1699 fragmented bundle as noted above. 1700 . If the fragmented bundle is not a fragment or is the fragment 1701 with offset zero, then all extension blocks of the fragmented 1702 bundle MUST be replicated in the fragment whose offset is zero. 1703 . Each of the fragmented bundle's extension blocks whose "Block 1704 must be replicated in every fragment" flag is set to 1 MUST be 1705 replicated in every fragment. 1706 . Beyond these rules, rules for the replication of extension 1707 blocks in the fragments must be defined in the specifications 1708 for those extension block types. 1710 5.9. Application Data Unit Reassembly 1712 Note that the bundle fragmentation procedure described in 5.8 above 1713 may result in the replacement of a single original bundle with an 1714 arbitrarily large number of fragmentary bundles. In order to be 1715 delivered at a destination node, the original bundle's payload must 1716 be reassembled from the payloads of those fragments. 1718 If the concatenation - as informed by fragment offsets and payload 1719 lengths - of the non-overlapping portions of the payloads of all 1720 previously received fragments with the same source node ID and 1721 creation timestamp as this fragment, together with the non- 1722 overlapping portion of the payload of this fragment, forms a 1723 continuous byte array whose length is equal to the total application 1724 data unit length in the fragment's primary block, then: 1726 . This byte array -- the reassembled application data unit -- 1727 MUST replace the payload of that fragment whose payload is a 1728 subset, starting at offset zero, of the reassembled application 1729 data unit. Note that this will enable delivery of the 1730 reconstituted original bundle as described in Step 1 of 5.7. 1731 . The "Reassembly pending" retention constraint MUST be removed 1732 from every previously received fragment whose payload is a 1733 subset of the reassembled application data unit. 1735 Note: reassembly of application data units from fragments occurs at 1736 the nodes that are members of destination endpoints as necessary; an 1737 application data unit MAY also be reassembled at some other node on 1738 the path to the destination. 1740 5.10. Bundle Deletion 1742 The steps in deleting a bundle are: 1744 Step 1: If the "request reporting of bundle deletion" flag in the 1745 bundle's status report request field is set to 1, and if status 1746 reporting is enabled, then a bundle deletion status report citing 1747 the reason for deletion SHOULD be generated, destined for the 1748 bundle's report-to endpoint ID. 1750 Step 2: All of the bundle's retention constraints MUST be removed. 1752 5.11. Discarding a Bundle 1754 As soon as a bundle has no remaining retention constraints it MAY be 1755 discarded, thereby releasing any persistent storage that may have 1756 been allocated to it. 1758 5.12. Canceling a Transmission 1760 When requested to cancel a specified transmission, where the bundle 1761 created upon initiation of the indicated transmission has not yet 1762 been discarded, the bundle protocol agent MUST delete that bundle 1763 for the reason "transmission cancelled". For this purpose, the 1764 procedure defined in Section 5.10 MUST be followed. 1766 6. Administrative Record Processing 1768 6.1. Administrative Records 1770 Administrative records are standard application data units that are 1771 used in providing some of the features of the Bundle Protocol. One 1772 type of administrative record has been defined to date: bundle 1773 status reports. Note that additional types of administrative 1774 records may be defined by supplementary DTN protocol specification 1775 documents. 1777 Every administrative record consists of: 1779 . Record type code (an unsigned integer for which valid values 1780 are as defined below). 1781 . Record content in type-specific format. 1783 Valid administrative record type codes are defined as follows: 1785 +---------+--------------------------------------------+ 1787 | Value | Meaning | 1789 +=========+============================================+ 1791 | 1 | Bundle status report. | 1793 +---------+--------------------------------------------+ 1795 | (other) | Reserved for future use. | 1797 +---------+--------------------------------------------+ 1799 Figure 3: Administrative Record Type Codes 1801 Each BP administrative record SHALL be represented as a CBOR array 1802 comprising two items. 1804 The first item of the array SHALL be a record type code, which SHALL 1805 be represented as a CBOR unsigned integer. 1807 The second element of this array SHALL be the applicable CBOR 1808 representation of the content of the record. Details of the CBOR 1809 representation of administrative record type 1 are provided below. 1810 Details of the CBOR representation of other types of administrative 1811 record type are included in the specifications defining those 1812 records. 1814 6.1.1. Bundle Status Reports 1816 The transmission of "bundle status reports" under specified 1817 conditions is an option that can be invoked when transmission of a 1818 bundle is requested. These reports are intended to provide 1819 information about how bundles are progressing through the system, 1820 including notices of receipt, forwarding, final delivery, and 1821 deletion. They are transmitted to the Report-to endpoints of 1822 bundles. 1824 Each bundle status report SHALL be represented as a CBOR array. The 1825 number of elements in the array SHALL be either 6 (if the subject 1826 bundle is a fragment) or 4 (otherwise). 1828 The first item of the bundle status report array SHALL be bundle 1829 status information represented as a CBOR array of at least 4 1830 elements. The first four items of the bundle status information 1831 array shall provide information on the following four status 1832 assertions, in this order: 1834 . Reporting node received bundle. 1835 . Reporting node forwarded the bundle. 1836 . Reporting node delivered the bundle. 1837 . Reporting node deleted the bundle. 1839 Each item of the bundle status information array SHALL be a bundle 1840 status item represented as a CBOR array; the number of elements in 1841 each such array SHALL be either 2 (if the value of the first item of 1842 this bundle status item is 1 AND the "Report status time" flag was 1843 set to 1 in the bundle processing flags of the bundle whose status 1844 is being reported) or 1 (otherwise). The first item of the bundle 1845 status item array SHALL be a status indicator, a Boolean value 1846 indicating whether or not the corresponding bundle status is 1847 asserted, represented as a CBOR Boolean value. The second item of 1848 the bundle status item array, if present, SHALL indicate the time 1849 (as reported by the local system clock, an implementation matter) at 1850 which the indicated status was asserted for this bundle, represented 1851 as a DTN time as described in Section 4.1.6. above. 1853 The second item of the bundle status report array SHALL be the 1854 bundle status report reason code explaining the value of the status 1855 indicator, represented as a CBOR unsigned integer. Valid status 1856 report reason codes are registered in the IANA Bundle Status Report 1857 Reason Codes registry in the Bundle Protocol Namespace (see 10.5 1858 below). The initial contents of that registry are listed in Figure 1859 4 below but the list of status report reason codes provided here is 1860 neither exhaustive nor exclusive; supplementary DTN protocol 1861 specifications (including, but not restricted to, the Bundle 1862 Security Protocol [BPSEC]) may define additional reason codes. 1864 +---------+--------------------------------------------+ 1866 | Value | Meaning | 1868 +=========+============================================+ 1870 | 0 | No additional information. | 1872 +---------+--------------------------------------------+ 1874 | 1 | Lifetime expired. | 1876 +---------+--------------------------------------------+ 1877 | 2 | Forwarded over unidirectional link. | 1879 +---------+--------------------------------------------+ 1881 | 3 | Transmission canceled. | 1883 +---------+--------------------------------------------+ 1885 | 4 | Depleted storage. | 1887 +---------+--------------------------------------------+ 1889 | 5 | Destination endpoint ID unavailable. | 1891 +---------+--------------------------------------------+ 1893 | 6 | No known route to destination from here. | 1895 +---------+--------------------------------------------+ 1897 | 7 | No timely contact with next node on route. | 1899 +---------+--------------------------------------------+ 1901 | 8 | Block unintelligible. | 1903 +---------+--------------------------------------------+ 1905 | 9 | Hop limit exceeded. | 1907 +---------+--------------------------------------------+ 1909 | 10 | Traffic pared (e.g., status reports). | 1911 +---------+--------------------------------------------+ 1913 | (other) | Reserved for future use. | 1915 +---------+--------------------------------------------+ 1917 Figure 4: Status Report Reason Codes 1919 The third item of the bundle status report array SHALL be the source 1920 node ID identifying the source of the bundle whose status is being 1921 reported, represented as described in Section 4.1.5.1.1. above. 1923 The fourth item of the bundle status report array SHALL be the 1924 creation timestamp of the bundle whose status is being reported, 1925 represented as described in Section 4.1.7. above. 1927 The fifth item of the bundle status report array SHALL be present if 1928 and only if the bundle whose status is being reported contained a 1929 fragment offset. If present, it SHALL be the subject bundle's 1930 fragment offset represented as a CBOR unsigned integer item. 1932 The sixth item of the bundle status report array SHALL be present if 1933 and only if the bundle whose status is being reported contained a 1934 fragment offset. If present, it SHALL be the length of the subject 1935 bundle's payload represented as a CBOR unsigned integer item. 1937 Note that the forwarding parameters (such as lifetime, applicable 1938 security measures, etc.) of the bundle whose status is being 1939 reported MAY be reflected in the parameters governing the forwarding 1940 of the bundle that conveys a status report, but this is an 1941 implementation matter. Bundle protocol deployment experience to 1942 date has not been sufficient to suggest any clear guidance on this 1943 topic. 1945 6.2. Generation of Administrative Records 1947 Whenever the application agent's administrative element is directed 1948 by the bundle protocol agent to generate an administrative record, 1949 the following procedure must be followed: 1951 Step 1: The administrative record must be constructed. If the 1952 administrative record references a bundle and the referenced bundle 1953 is a fragment, the administrative record MUST contain the fragment 1954 offset and fragment length. 1956 Step 2: A request for transmission of a bundle whose payload is this 1957 administrative record MUST be presented to the bundle protocol 1958 agent. 1960 7. Services Required of the Convergence Layer 1962 7.1. The Convergence Layer 1964 The successful operation of the end-to-end bundle protocol depends 1965 on the operation of underlying protocols at what is termed the 1966 "convergence layer"; these protocols accomplish communication 1967 between nodes. A wide variety of protocols may serve this purpose, 1968 so long as each convergence layer protocol adapter provides a 1969 defined minimal set of services to the bundle protocol agent. This 1970 convergence layer service specification enumerates those services. 1972 7.2. Summary of Convergence Layer Services 1974 Each convergence layer protocol adapter is expected to provide the 1975 following services to the bundle protocol agent: 1977 . sending a bundle to a bundle node that is reachable via the 1978 convergence layer protocol; 1979 . notifying the bundle protocol agent of the disposition of its 1980 data sending procedures with regard to a bundle, upon 1981 concluding those procedures; 1982 . delivering to the bundle protocol agent a bundle that was sent 1983 by a bundle node via the convergence layer protocol. 1985 The convergence layer service interface specified here is neither 1986 exhaustive nor exclusive. That is, supplementary DTN protocol 1987 specifications (including, but not restricted to, the Bundle 1988 Security Protocol [BPSEC]) may expect convergence layer adapters 1989 that serve BP implementations conforming to those protocols to 1990 provide additional services such as reporting on the transmission 1991 and/or reception progress of individual bundles (at completion 1992 and/or incrementally), retransmitting data that were lost in 1993 transit, discarding bundle-conveying data units that the convergence 1994 layer protocol determines are corrupt or inauthentic, or reporting 1995 on the integrity and/or authenticity of delivered bundles. 1997 In addition, bundle protocol relies on the capabilities of protocols 1998 at the convergence layer to minimize congestion in the store-carry- 1999 forward overlay network. The potentially long round-trip times 2000 characterizing delay-tolerant networks are incompatible with end-to- 2001 end reactive congestion control mechanisms, so convergence-layer 2002 protocols MUST provide rate limiting or congestion control. 2004 8. Implementation Status 2006 [NOTE to the RFC Editor: please remove this section before 2007 publication, as well as the reference to RFC 7942.] 2009 This section records the status of known implementations of the 2010 protocol defined by this specification at the time of posting of 2011 this Internet-Draft, and is based on a proposal described in RFC 2012 7942. The description of implementations in this section is 2013 intended to assist the IETF in its decision processes in progressing 2014 drafts to RFCs. Please note that the listing of any individual 2015 implementation here does not imply endorsement by the IETF. 2017 Furthermore, no effort has been spent to verify the information 2018 presented here that was supplied by IETF contributors. This is not 2019 intended as, and must not be construed to be, a catalog of available 2020 implementations or their features. Readers are advised to note that 2021 other implementations may exist. 2023 According to RFC 7942, "this will allow reviewers and working groups 2024 to assign due consideration to documents that have the benefit of 2025 running code, which may serve as evidence of valuable 2026 experimentation and feedback that have made the implemented 2027 protocols more mature. It is up to the individual working groups to 2028 use this information as they see fit". 2030 At the time of this writing, there are six known implementations of 2031 the current document. 2033 The first known implementation is microPCN (https://upcn.eu/). 2034 According to the developers: 2036 The Micro Planetary Communication Network (uPCN) is a free 2037 software project intended to offer an implementation of Delay- 2038 tolerant Networking protocols for POSIX operating systems (well, 2039 and for Linux) plus for the ARM Cortex STM32F4 microcontroller 2040 series. More precisely it currently provides an implementation of 2042 . the Bundle Protocol (BP, RFC 5050), 2043 . version 6 of the Bundle Protocol version 7 specification 2044 draft, 2045 . the DTN IP Neighbor Discovery (IPND) protocol, and 2046 . a routing approach optimized for message-ferry micro LEO 2047 satellites. 2049 uPCN is written in C and is built upon the real-time operating 2050 system FreeRTOS. The source code of uPCN is released under the 2051 "BSD 3-Clause License". 2053 The project depends on an execution environment offering link 2054 layer protocols such as AX.25. The source code uses the USB 2055 subsystem to interact with the environment. 2057 The second known implementation is PyDTN, developed by X-works, 2058 s.r.o (https://x-works.sk/). The final third of the implementation 2059 was developed during the IETF 101 Hackathon. According to the 2060 developers, PyDTN implements bundle coding/decoding and neighbor 2061 discovery. PyDTN is written in Python and has been shown to be 2062 interoperable with uPCN. 2064 The third known implementation is "Terra" 2065 (https://github.com/RightMesh/Terra/), a Java implementation 2066 developed in the context of terrestrial DTN. It includes an 2067 implementation of a "minimal TCP" convergence layer adapter. 2069 The fourth and fifth known implementations are products of 2070 cooperating groups at two German universities: 2072 . An implementation written in Go, licensed under GPLv3, is 2073 focused on being easily extensible suitable for research. It 2074 is maintained at the University of Marburg and can be accessed 2075 from https://github.com/dtn7/dtn7-go. 2076 . An implementation written in Rust, licensed under the 2077 MIT/Apache license, is intended for environments with limited 2078 resources or demanding safety and/or performance requirements. 2079 It is maintained at the Technical University of Darmstadt and 2080 can be accessed at https://github.com/dtn7/dtn7-rs/. 2082 The sixth known implementation is the "bpv7" module in version 4.0.0 2083 of the Interplanetary Overlay Network (ION) software maintained at 2084 the Jet Propulsion Laboratory, California Institute of Technology, 2085 for the U.S. National Aeronautics and Space Administration (NASA). 2087 9. Security Considerations 2089 The bundle protocol security architecture and the available security 2090 services are specified in an accompanying document, the Bundle 2091 Security Protocol (BPsec) specification [BPSEC]. Whenever Bundle 2092 Protocol security services (as opposed to the security services 2093 provided by overlying application protocols or underlying 2094 convergence-layer protocols) are required, those services SHALL be 2095 provided by BPsec rather than by some other mechanism with the same 2096 or similar scope. 2098 A Bundle Protocol Agent (BPA) which sources, cryptographically 2099 verifies, and/or accepts a bundle MUST implement support for BPsec. 2100 Use of BPsec for a particular Bundle Protocol session is optional. 2102 The BPsec extensions to Bundle Protocol enable each block of a 2103 bundle (other than a BPsec extension block) to be individually 2104 authenticated by a signature block (Block Integrity Block, or BIB) 2105 and also enable each block of a bundle other than the primary block 2106 (and the BPsec extension blocks themselves) to be individually 2107 encrypted by a Block Confidentiality Block (BCB). 2109 Because the security mechanisms are extension blocks that are 2110 themselves inserted into the bundle, the protections they afford 2111 apply while the bundle is at rest, awaiting transmission at the next 2112 forwarding opportunity, as well as in transit. 2114 Additionally, convergence-layer protocols that ensure authenticity 2115 of communication between adjacent nodes in BP network topology 2116 SHOULD be used where available, to minimize the ability of 2117 unauthenticated nodes to introduce inauthentic traffic into the 2118 network. Convergence-layer protocols that ensure confidentiality of 2119 communication between adjacent nodes in BP network topology SHOULD 2120 also be used where available, to minimize exposure of the bundle's 2121 primary block and other clear-text blocks, thereby offering some 2122 defense against traffic analysis. 2124 In order to provide authenticity and/or confidentiality of 2125 communication between BP nodes, the convergence-layer protocol 2126 requires as input the name(s) of the expected communication peer(s). 2127 These must be supplied by the convergence-layer adapter. Details of 2128 the means by which the CLA determines which CL endpoint name(s) must 2129 be provided to the CL protocol are out of scope for this 2130 specification. Note, though, that when the CL endpoint names are a 2131 function of BP endpoint IDs, the correctness and authenticity of 2132 that mapping will be vital to the overall security properties that 2133 the CL provides to the system. 2135 Note that, while the primary block must remain in the clear for 2136 routing purposes, the Bundle Protocol could be protected against 2137 traffic analysis to some extent by using bundle-in-bundle 2138 encapsulation [BIBE] to tunnel bundles to a safe forward 2139 distribution point: the encapsulated bundle could form the payload 2140 of an encapsulating bundle, and that payload block could be 2141 encrypted by a BCB. 2143 Note that the generation of bundle status reports is disabled by 2144 default because malicious initiation of bundle status reporting 2145 could result in the transmission of extremely large numbers of 2146 bundles, effecting a denial of service attack. Imposing bundle 2147 lifetime overrides would constitute one defense against such an 2148 attack. 2150 Note also that the reception of large numbers of fragmentary bundles 2151 with very long lifetimes could constitute a denial of service 2152 attack, occupying storage while pending reassembly that will never 2153 occur. Imposing bundle lifetime overrides would, again, constitute 2154 one defense against such an attack. 2156 This protocol makes use of absolute timestamps for several purposes. 2157 Provisions are included for nodes without accurate clocks to retain 2158 most of the protocol functionality, but nodes that are unaware that 2159 their clock is inaccurate may exhibit unexpected behavior. 2161 10. IANA Considerations 2163 The Bundle Protocol includes fields requiring registries managed by 2164 IANA. 2166 10.1. Bundle Block Types 2168 The current Bundle Block Types registry in the Bundle Protocol 2169 Namespace is augmented by adding a column identifying the version of 2170 the Bundle protocol (Bundle Protocol Version) that applies to the 2171 new values. IANA is requested to add the following values, as 2172 described in section 4.3.1, to the Bundle Block Types registry. The 2173 current values in the Bundle Block Types registry should have the 2174 Bundle Protocol Version set to the value "6", as shown below. 2176 +----------+-------+-----------------------------+---------------+ 2178 | Bundle | Value | Description | Reference | 2180 | Protocol | | | | 2182 | Version | | | | 2184 +----------+-------+-----------------------------+---------------+ 2186 | none | 0 | Reserved | [RFC6255] | 2188 | 6,7 | 1 | Bundle Payload Block | [RFC5050] | 2190 | | | | RFC-to-be | 2192 | 6 | 2 | Bundle Authentication Block | [RFC6257] | 2194 | 6 | 3 | Payload Integrity Block | [RFC6257] | 2196 | 6 | 4 | Payload Confidentiality | [RFC6257] | 2198 | | | Block | RFC-to-be | 2200 | 6 | 5 | Previous-Hop Insertion Block| [RFC6259] | 2202 | 7 | 6 | Previous node (proximate | RFC-to-be | 2204 | | | sender) | | 2205 | 7 | 7 | Bundle age (in milliseconds)| RFC-to-be | 2207 | 6 | 8 | Metadata Extension Block | [RFC6258] | 2209 | 6 | 9 | Extension Security Block | [RFC6257] | 2211 | 7 | 10 | Hop count (#prior xmit | RFC-to-be | 2213 | | | attempts) | | 2215 | 7 | 11-191| Unassigned | | 2217 | 6 |192-255| Reserved for Private and/or | [RFC5050], | 2219 | | | Experimental Use | RFC-to-be | 2221 +----------+-------+-----------------------------+---------------+ 2223 10.2. Primary Bundle Protocol Version 2225 IANA is requested to add the following value to the Primary Bundle 2226 Protocol Version registry in the Bundle Protocol Namespace. 2228 +-------+-------------+---------------+ 2230 | Value | Description | Reference | 2232 +-------+-------------+---------------+ 2234 | 7 | Assigned | RFC-to-be | 2236 +-------+-------------+---------------+ 2238 Values 8-255 (rather than 7-255) are now Unassigned. 2240 10.3. Bundle Processing Control Flags 2242 The current Bundle Processing Control Flags registry in the Bundle 2243 Protocol Namespace is augmented by adding a column identifying the 2244 version of the Bundle protocol (Bundle Protocol Version) that 2245 applies to the new values. IANA is requested to add the following 2246 values, as described in section 4.1.3, to the Bundle Processing 2247 Control Flags registry. The current values in the Bundle Processing 2248 Control Flags registry should have the Bundle Protocol Version set 2249 to the value 6 or "6, 7", as shown below. 2251 Bundle Processing Control Flags Registry 2253 +--------------------+----------------------------------+----------+ 2255 | Bundle | Bit | Description | Reference| 2257 | Protocol| Position | | | 2259 | Version | (right | | | 2261 | | to left) | | | 2263 +--------------------+----------------------------------+----------+ 2265 | 6,7 | 0 | Bundle is a fragment |[RFC5050],| 2267 | | | |RFC-to-be | 2269 | 6,7 | 1 | Application data unit is an |[RFC5050],| 2271 | | | administrative record |RFC-to-be | 2273 | 6,7 | 2 | Bundle must not be fragmented |[RFC5050],| 2275 | | | |RFC-to-be | 2277 | 6 | 3 | Custody transfer is requested |[RFC5050] | 2279 | 6 | 4 | Destination endpoint is singleton|[RFC5050] | 2281 | 6,7 | 5 | Acknowledgement by application |[RFC5050],| 2283 | | | is requested |RFC-to-be | 2285 | 7 | 6 | Status time requested in reports |RFC-to-be | 2287 | 6 | 7 | Class of service, priority |[RFC5050],| 2289 | | | |RFC-to-be | 2291 | 6 | 8 | Class of service, priority |[RFC5050],| 2293 | | | |RFC-to-be | 2295 | 6 | 9 | Class of service, reserved |[RFC5050],| 2297 | | | |RFC-to-be | 2299 | 6 | 10 | Class of service, reserved |[RFC5050],| 2300 | | | |RFC-to-be | 2302 | 6 | 11 | Class of service, reserved |[RFC5050],| 2304 | | | |RFC-to-be | 2306 | 6 | 12 | Class of service, reserved |[RFC5050],| 2308 | | | |RFC-to-be | 2310 | 6 | 13 | Class of service, reserved |[RFC5050],| 2312 | | | |RFC-to-be | 2314 | 6,7 | 14 | Request reporting of bundle |[RFC5050],| 2316 | | | reception |RFC-to-be | 2318 | 6,7 | 16 | Request reporting of bundle |[RFC5050],| 2320 | | | forwarding |RFC-to-be | 2322 | 6,7 | 17 | Request reporting of bundle |[RFC5050],| 2324 | | | delivery |RFC-to-be | 2326 | 6,7 | 18 | Request reporting of bundle |[RFC5050],| 2328 | | | deletion |RFC-to-be | 2330 | 6 | 19 | Reserved |[RFC5050],| 2332 | | | |RFC-to-be | 2334 | 6 | 20 | Reserved |[RFC5050],| 2336 | | | |RFC-to-be | 2338 | | 21-63 | Unassigned | | 2340 +--------------------+----------------------------------+----------+ 2342 10.4. Block Processing Control Flags 2344 The current Block Processing Control Flags registry in the Bundle 2345 Protocol Namespace is augmented by adding a column identifying the 2346 version of the Bundle protocol (Bundle Protocol Version) that 2347 applies to the related BP version. The current values in the Block 2348 Processing Control Flags registry should have the Bundle Protocol 2349 Version set to the value 6 or "6, 7", as shown below. 2351 Block Processing Control Flags Registry 2353 +--------------------+----------------------------------+----------+ 2355 | Bundle | Bit | Description | Reference| 2357 | Protocol| Position | | | 2359 | Version | (right | | | 2361 | | to left) | | | 2363 +--------------------+----------------------------------+----------+ 2365 | 6,7 | 0 | Block must be replicated in |[RFC5050],| 2367 | | | every fragment |RFC-to-be | 2369 | 6,7 | 1 | Transmit status report if block |[RFC5050],| 2371 | | | can't be processed |RFC-to-be | 2373 | 6,7 | 2 | Delete bundle if block can't be |[RFC5050],| 2375 | | | processed |RFC-to-be | 2377 | 6 | 3 | Last block |[RFC5050] | 2379 | 6,7 | 4 | Discard block if it can't be |[RFC5050],| 2381 | | | processed |RFC-to-be | 2383 | 6 | 5 | Block was forwarded without |[RFC5050] | 2385 | | | being processed | | 2387 | 6 | 6 | Block contains an EID reference |[RFC5050] | 2389 | | | field | | 2391 | | 7-63 | Unassigned | | 2393 +--------------------+----------------------------------+----------+ 2395 10.5. Bundle Status Report Reason Codes 2397 The current Bundle Status Report Reason Codes registry in the Bundle 2398 Protocol Namespace is augmented by adding a column identifying the 2399 version of the Bundle protocol (Bundle Protocol Version) that 2400 applies to the new values. IANA is requested to add the following 2401 values, as described in section 6.1.1, to the Bundle Status Report 2402 Reason Codes registry. The current values in the Bundle Status 2403 Report Reason Codes registry should have the Bundle Protocol Version 2404 set to the value 6 or 7 or "6, 7", as shown below. 2406 Bundle Status Report Reason Codes Registry 2408 +--------------------+----------------------------------+----------+ 2410 | Bundle | Value | Description | Reference| 2412 | Protocol| | | | 2414 | Version | | | | 2416 | | | | | 2418 +--------------------+----------------------------------+----------+ 2420 | 6,7 | 0 | No additional information |[RFC5050],| 2422 | | | |RFC-to-be | 2424 | 6,7 | 1 | Lifetime expired |[RFC5050],| 2426 | | | |RFC-to-be | 2428 | 6,7 | 2 | Forwarded over unidirectional |[RFC5050],| 2430 | | | link |RFC-to-be | 2432 | 6,7 | 3 | Transmission canceled |[RFC5050],| 2434 | | | |RFC-to-be | 2436 | 6,7 | 4 | Depleted storage |[RFC5050],| 2438 | | | |RFC-to-be | 2440 | 6,7 | 5 | Destination endpoint ID |[RFC5050],| 2441 | | | unavailable |RFC-to-be | 2443 | 6,7 | 6 | No known route to destination |[RFC5050],| 2445 | | | from here |RFC-to-be | 2447 | 6,7 | 7 | No timely contact with next node |[RFC5050],| 2449 | | | on route |RFC-to-be | 2451 | 6,7 | 8 | Block unintelligible |[RFC5050],| 2453 | | | |RFC-to-be | 2455 | 7 | 9 | Hop limit exceeded |RFC-to-be | 2457 | 7 | 10 | Traffic pared |RFC-to-be | 2459 | | 11-254 | Unassigned | | 2461 | 6 | 255 | Reserved |[RFC6255],| 2463 | | | |RFC-to-be | 2465 +-------+-----------------------------------------------+----------+ 2467 10.6. Bundle Protocol URI scheme types 2469 The Bundle Protocol has a URI scheme type field - an unsigned 2470 integer of indefinite length - for which IANA is requested to create 2471 and maintain a new "Bundle Protocol URI Scheme Type" registry in the 2472 Bundle Protocol Namespace. The "Bundle Protocol URI Scheme Type" 2473 registry governs an unsigned integer namespace. Initial values for 2474 the Bundle Protocol URI Scheme Type registry are given below. 2476 The registration policy for this registry is: Standards Action. The 2477 allocation should only be granted for a standards-track RFC approved 2478 by the IESG. 2480 The value range is: unsigned integer. 2482 Each assignment consists of a URI scheme type name and its 2483 associated description, a reference to the document that defines the 2484 URI scheme, and a reference to the document that defines the use of 2485 this URI scheme in BP endpoint IDs (including the CBOR 2486 representation of those endpoint IDs in transmitted bundles). 2488 Bundle Protocol URI Scheme Type Registry 2490 +---------+-------------+----------------+------------------+ 2492 | | | BP Utilization | URI Definition | 2494 | Value | Description | Reference | Reference | 2496 +---------+-------------+----------------+------------------+ 2498 | 0 | Reserved | n/a | | 2500 | 1 | dtn | RFC-to-be | RFC-to-be | 2502 | 2 | ipn | RFC-to-be | [RFC6260], | 2504 | | | | RFC-to-be | 2506 | 3-254 | Unassigned | n/a | | 2508 |255-65535| reserved | n/a | | 2510 | >65535 | open for | n/a | | 2512 | | private use | n/a | | 2514 +---------+-------------+----------------+------------------+ 2516 10.7. URI scheme "dtn" 2518 In the Uniform Resource Identifier (URI) Schemes (uri-schemes) 2519 registry, IANA is requested to update the registration of the URI 2520 scheme with the string "dtn" as the scheme name, as follows: 2522 URI scheme name: "dtn" 2524 Status: permanent 2526 Applications and/or protocols that use this URI scheme name: the 2527 Delay-Tolerant Networking (DTN) Bundle Protocol (BP). 2529 Contact: 2531 Scott Burleigh 2533 Jet Propulsion Laboratory, 2535 California Institute of Technology 2537 scott.c.burleigh@jpl.nasa.gov 2539 +1 (800) 393-3353 2541 Change controller: 2543 IETF, iesg@ietf.org 2545 10.8. URI scheme "ipn" 2547 In the Uniform Resource Identifier (URI) Schemes (uri-schemes) 2548 registry, IANA is requested to update the registration of the URI 2549 scheme with the string "ipn" as the scheme name, originally 2550 documented in RFC 6260 [RFC6260], as follows. 2552 URI scheme name: "ipn" 2554 Status: permanent 2556 Applications and/or protocols that use this URI scheme name: the 2557 Delay-Tolerant Networking (DTN) Bundle Protocol (BP). 2559 Contact: 2561 Scott Burleigh 2563 Jet Propulsion Laboratory, 2565 California Institute of Technology 2567 scott.c.burleigh@jpl.nasa.gov 2569 +1 (800) 393-3353 2571 Change controller: 2573 IETF, iesg@ietf.org 2575 11. References 2577 11.1. Normative References 2579 [BPSEC] Birrane, E., "Bundle Security Protocol Specification", 2580 draft-ietf-dtn-bpsec, January 2020. 2582 [CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4, 2583 International Telecommunications Union, October 1996. 2585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2586 Requirement Levels", BCP 14, RFC 2119, March 1997. 2588 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 2589 4960, September 2007. 2591 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2592 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2594 [RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object 2595 Representation (CBOR)", RFC 7049, October 2013. 2597 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2598 2119 Key Words", BCP 14, RFC 8174, May 2017. 2600 [SABR] "Schedule-Aware Bundle Routing", CCSDS Recommended Standard 2601 734.3-B-1, Consultative Committee for Space Data Systems, July 2019. 2603 [TCPCL] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 2604 Tolerant Networking TCP Convergence Layer Protocol Version 4", 2605 draft-ietf-dtn-tcpclv4, January 2020. 2607 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2608 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 2609 January 2005. 2611 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2612 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 2613 2015. 2615 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 2616 historical background and perspectives" in "Journees systemes de 2617 reference spatio-temporels", 2004. 2619 11.2. Informative References 2621 [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 2622 4838, April 2007. 2624 [BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", draft-ietf- 2625 dtn-bibect, August 2019. 2627 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 2628 Identifiers (IRIs)", RFC 3987, January 2005. 2630 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 2631 Specification", RFC 5050, November 2007. 2633 [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol 2634 IANA Registries", RFC 6255, May 2011. 2636 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 2637 "Bundle Security Protocol Specification", RFC 6257, May 2011. 2639 [RFC6258] Symington, S., "Delay-Tolerant Networking Metadata 2640 Extension Block", RFC 6258, May 2011. 2642 [RFC6259] Symington, S., "Delay-Tolerant Networking Previous-Hop 2643 Insertion Block", RFC 6259, May 2011. 2645 [RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", 2646 RFC 6260, May 2011. 2648 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, 2649 "Internet Small Computer System Interface (iSCSI) Protocol 2650 (Consolidated)", RFC 7143, April 2014. 2652 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 2653 Challenged Internets", SIGCOMM 2003. 2655 12. Acknowledgments 2657 This work is freely adapted from RFC 5050, which was an effort of 2658 the Delay Tolerant Networking Research Group. The following DTNRG 2659 participants contributed significant technical material and/or 2660 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 2661 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 2662 Michael Demmer of the University of California at Berkeley, Robert 2663 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 2664 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 2665 College Dublin, Howard Weiss and Peter Lovell of SPARTA, Inc., and 2666 Manikantan Ramadas of Ohio University. 2668 This document was prepared using 2-Word-v2.0.template.dot. 2670 13. Significant Changes from RFC 5050 2672 Points on which this draft significantly differs from RFC 5050 2673 include the following: 2675 . Clarify the difference between transmission and forwarding. 2676 . Migrate custody transfer to the bundle-in-bundle encapsulation 2677 specification [BIBE]. 2678 . Introduce the concept of "node ID" as functionally distinct 2679 from endpoint ID, while having the same syntax. 2680 . Restructure primary block, making it immutable. Add optional 2681 CRC. 2682 . Add optional CRCs to non-primary blocks. 2683 . Add block ID number to canonical block format (to support 2684 BPsec). 2685 . Add definition of bundle age extension block. 2686 . Add definition of previous node extension block. 2687 . Add definition of hop count extension block. 2688 . Remove Quality of Service markings. 2689 . Change from SDNVs to CBOR representation. 2690 . Add lifetime overrides. 2692 Appendix A. For More Information 2694 Copyright (c) 2020 IETF Trust and the persons identified as authors 2695 of the code. All rights reserved. 2697 Redistribution and use in source and binary forms, with or without 2698 modification, is permitted pursuant to, and subject to the license 2699 terms contained in, the Simplified BSD License set forth in Section 2700 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2701 (http://trustee.ietf.org/license-info). 2703 Appendix B. CDDL expression 2705 For informational purposes, Carsten Bormann and Brian Sipos have 2706 kindly provided an expression of the Bundle Protocol specification 2707 in the Concise Data Definition Language (CDDL). That CDDL 2708 expression is presented below. Note that wherever the CDDL 2709 expression is in disagreement with the textual representation of the 2710 BP specification presented in the earlier sections of this document, 2711 the textual representation rules. 2713 start = bundle / #6.55799(bundle) 2715 ; Times before 2000 are invalid 2717 dtn-time = uint 2719 ; CRC enumerated type 2721 crc-type = &( 2723 crc-none: 0, 2725 crc-16bit: 1, 2727 crc-32bit: 2 2729 ) 2731 ; Either 16-bit or 32-bit 2733 crc-value = (bstr .size 2) / (bstr .size 4) 2735 creation-timestamp = [ 2737 dtn-time, ; absolute time of creation 2739 sequence: uint ; sequence within the time 2741 ] 2743 eid = $eid .within eid-structure 2745 eid-structure = [ 2747 uri-code: uint, 2748 SSP: any 2750 ] 2752 $eid /= [ 2754 uri-code: 1, 2756 SSP: (tstr / 0) 2758 ] 2760 $eid /= [ 2762 uri-code: 2, 2764 SSP: [ 2766 nodenum: uint, 2768 servicenum: uint 2770 ] 2772 ] 2774 ; The root bundle array 2776 bundle = [primary-block, *extension-block, payload-block] 2778 primary-block = [ 2780 version: 7, 2782 bundle-control-flags, 2784 crc-type, 2786 destination: eid, 2788 source-node: eid, 2790 report-to: eid, 2792 creation-timestamp, 2794 lifetime: uint, 2795 ? ( 2797 fragment-offset: uint, 2799 total-application-data-length: uint 2801 ), 2803 ? crc-value, 2805 ] 2807 bundle-control-flags = uint .bits bundleflagbits 2809 bundleflagbits = &( 2811 reserved: 21, 2813 reserved: 20, 2815 reserved: 19, 2817 bundle-deletion-status-reports-are-requested: 18, 2819 bundle-delivery-status-reports-are-requested: 17, 2821 bundle-forwarding-status-reports-are-requested: 16, 2823 reserved: 15, 2825 bundle-reception-status-reports-are-requested: 14, 2827 reserved: 13, 2829 reserved: 12, 2831 reserved: 11, 2833 reserved: 10, 2835 reserved: 9, 2837 reserved: 8, 2839 reserved: 7, 2840 status-time-is-requested-in-all-status-reports: 6, 2842 user-application-acknowledgement-is-requested: 5, 2844 reserved: 4, 2846 reserved: 3, 2848 bundle-must-not-be-fragmented: 2, 2850 payload-is-an-administrative-record: 1, 2852 bundle-is-a-fragment: 0 2854 ) 2856 ; Abstract shared structure of all non-primary blocks 2858 canonical-block-structure = [ 2860 block-type-code: uint, 2862 block-number: uint, 2864 block-control-flags, 2866 crc-type, 2868 ; Each block type defines the content within the bytestring 2870 block-type-specific-data, 2872 ? crc-value 2874 ] 2876 block-control-flags = uint .bits blockflagbits 2878 blockflagbits = &( 2880 reserved: 7, 2882 reserved: 6, 2884 reserved: 5, 2886 block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4, 2887 reserved: 3, 2889 bundle-must-be-deleted-if-block-cannot-be-processed: 2, 2891 status-report-must-be-transmitted-if-block-cannot-be-processed: 1, 2893 block-must-be-replicated-in-every-fragment: 0 2895 ) 2897 block-type-specific-data = bstr / #6.24(bstr) 2899 ; Actual CBOR data embedded in a bytestring, with optional tag to 2900 indicate so 2902 embedded-cbor = (bstr .cbor Item) / #6.24(bstr .cbor Item) 2904 ; Extension block type, which does not specialize other than the 2905 code/number 2907 extension-block = $extension-block-structure .within canonical- 2908 block-structure 2910 ; Generic shared structure of all non-primary blocks 2912 extension-block-use = [ 2914 block-type-code: CodeValue, 2916 block-number: (uint .gt 1), 2918 block-control-flags, 2920 crc-type, 2922 BlockData, 2924 ? crc-value 2926 ] 2928 ; Payload block type 2930 payload-block = payload-block-structure .within canonical-block- 2931 structure 2932 payload-block-structure = [ 2934 block-type-code: 1, 2936 block-number: 1, 2938 block-control-flags, 2940 crc-type, 2942 $payload-block-data, 2944 ? crc-value 2946 ] 2948 ; Arbitrary payload data, including non-CBOR bytestring 2950 $payload-block-data /= block-type-specific-data 2952 ; Administrative record as a payload data specialization 2954 $payload-block-data /= embedded-cbor 2956 admin-record = $admin-record .within admin-record-structure 2958 admin-record-structure = [ 2960 record-type-code: uint, 2962 record-content: any 2964 ] 2966 ; Only one defined record type 2968 $admin-record /= [1, status-record-content] 2970 status-record-content = [ 2972 bundle-status-information, 2974 status-report-reason-code: uint, 2976 source-node-eid: eid, 2978 subject-creation-timestamp: creation-timestamp, 2979 ? ( 2981 subject-payload-offset: uint, 2983 subject-payload-length: uint 2985 ) 2987 ] 2989 bundle-status-information = [ 2991 reporting-node-received-bundle: status-info-content, 2993 reporting-node-forwarded-bundle: status-info-content, 2995 reporting-node-delivered-bundle: status-info-content, 2997 reporting-node-deleted-bundle: status-info-content 2999 ] 3001 status-info-content = [ 3003 status-indicator: bool, 3005 ? timestamp: dtn-time 3007 ] 3009 ; Previous Node extension block 3011 $extension-block-structure /= 3013 extension-block-use<6, embedded-cbor> 3015 ext-data-previous-node = eid 3017 ; Bundle Age extension block 3019 $extension-block-structure /= 3021 extension-block-use<7, embedded-cbor> 3023 ext-data-bundle-age = uint 3025 ; Hop Count extension block 3026 $extension-block-structure /= 3028 extension-block-use<10, embedded-cbor> 3030 ext-data-hop-count = [ 3032 hop-limit: uint, 3034 hop-count: uint 3036 ] 3038 Authors' Addresses 3040 Scott Burleigh 3041 Jet Propulsion Laboratory, California Institute of Technology 3042 4800 Oak Grove Dr. 3043 Pasadena, CA 91109-8099 3044 US 3045 Phone: +1 818 393 3353 3046 Email: Scott.C.Burleigh@jpl.nasa.gov 3048 Kevin Fall 3049 Roland Computing Services 3050 3871 Piedmont Ave. Suite 8 3051 Oakland, CA 94611 3052 US 3053 Email: kfall+rcs@kfall.com 3055 Edward J. Birrane 3056 Johns Hopkins University Applied Physics Laboratory 3057 11100 Johns Hopkins Rd 3058 Laurel, MD 20723 3059 US 3060 Phone: +1 443 778 7423 3061 Email: Edward.Birrane@jhuapl.edu