idnits 2.17.1 draft-ietf-dtn-bpbis-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2019) is 1615 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'BPSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRC16' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRC32C' -- Possible downref: Non-RFC (?) normative reference: ref. 'EPOCH' ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay-Tolerant Networking Working Group S. Burleigh 2 Internet Draft JPL, Calif. Inst. Of Technology 3 Intended status: Standards Track K. Fall 4 Expires: April 28, 2020 Roland Computing Services 5 E. Birrane 6 APL, Johns Hopkins University 7 October 26, 2019 9 Bundle Protocol Version 7 10 draft-ietf-dtn-bpbis-16.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 28, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 This Internet Draft presents a specification for Bundle Protocol, 53 adapted from the experimental Bundle Protocol specification 54 developed by the Delay-Tolerant Networking Research group of the 55 Internet Research Task Force and documented in RFC 5050. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Conventions used in this document..............................5 61 3. Service Description............................................6 62 3.1. Definitions...............................................6 63 3.2. Discussion of BP concepts.................................9 64 3.3. Services Offered by Bundle Protocol Agents...............12 65 4. Bundle Format.................................................13 66 4.1. BP Fundamental Data Structures...........................13 67 4.1.1. CRC Type............................................13 68 4.1.2. CRC.................................................14 69 4.1.3. Bundle Processing Control Flags.....................14 70 4.1.4. Block Processing Control Flags......................16 71 4.1.5. Identifiers.........................................17 72 4.1.5.1. Endpoint ID....................................17 73 4.1.5.2. Node ID........................................18 74 4.1.6. DTN Time............................................18 75 4.1.7. Creation Timestamp..................................20 76 4.1.8. Block-type-specific Data............................20 77 4.2. Bundle Representation....................................20 78 4.2.1. Bundle..............................................21 79 4.2.2. Primary Bundle Block................................21 80 4.2.3. Canonical Bundle Block Format.......................23 81 4.3. Extension Blocks.........................................24 82 4.3.1. Previous Node.......................................25 83 4.3.2. Bundle Age..........................................25 84 4.3.3. Hop Count...........................................26 85 5. Bundle Processing.............................................26 86 5.1. Generation of Administrative Records.....................26 87 5.2. Bundle Transmission......................................27 88 5.3. Bundle Dispatching.......................................28 89 5.4. Bundle Forwarding........................................28 90 5.4.1. Forwarding Contraindicated..........................30 91 5.4.2. Forwarding Failed...................................30 92 5.5. Bundle Expiration........................................31 93 5.6. Bundle Reception.........................................31 94 5.7. Local Bundle Delivery....................................32 95 5.8. Bundle Fragmentation.....................................33 96 5.9. Application Data Unit Reassembly.........................34 97 5.10. Bundle Deletion.........................................34 98 5.11. Discarding a Bundle.....................................35 99 5.12. Canceling a Transmission................................35 100 6. Administrative Record Processing..............................35 101 6.1. Administrative Records...................................35 102 6.1.1. Bundle Status Reports...............................36 103 6.2. Generation of Administrative Records.....................39 104 7. Services Required of the Convergence Layer....................39 105 7.1. The Convergence Layer....................................39 106 7.2. Summary of Convergence Layer Services....................39 107 8. Implementation Status.........................................40 108 9. Security Considerations.......................................41 109 10. IANA Considerations..........................................43 110 10.1. Bundle Block Types......................................43 111 10.2. Primary Bundle Protocol Version.........................44 112 10.3. Bundle Processing Control Flags.......................4544 113 10.4. Block Processing Control Flags........................4746 114 10.5. Bundle Status Report Reason Codes.....................4847 115 10.6. Bundle Protocol URI scheme types......................5049 116 10.7. URI scheme "dtn"......................................5150 117 10.8. Change status of URI scheme "ipn".....................5352 118 11. References.................................................5352 119 11.1. Normative References..................................5352 120 11.2. Informative References................................5453 121 12. Acknowledgments............................................5453 122 13. Significant Changes from RFC 5050..........................5553 123 Appendix A. For More Information...............................5655 124 Appendix B. CDDL expression....................................5756 126 1. Introduction 128 Since the publication of the Bundle Protocol Specification 129 (Experimental RFC 5050) in 2007, the Delay-Tolerant Networking (DTN) 130 Bundle Protocol has been implemented in multiple programming 131 languages and deployed to a wide variety of computing platforms. 132 This implementation and deployment experience has identified 133 opportunities for making the protocol simpler, more capable, and 134 easier to use. The present document, standardizing the Bundle 135 Protocol (BP), is adapted from RFC 5050 in that context. 136 Significant changes from the Bundle Protocol specification defined 137 in RFC 5050 are listed in section 13. 139 This document describes version 7 of BP. 141 Delay Tolerant Networking is a network architecture providing 142 communications in and/or through highly stressed environments. 143 Stressed networking environments include those with intermittent 144 connectivity, large and/or variable delays, and high bit error 145 rates. To provide its services, BP may be viewed as sitting at the 146 application layer of some number of constituent networks, forming a 147 store-carry-forward overlay network. Key capabilities of BP 148 include: 150 . Ability to use physical motility for the movement of data 151 . Ability to move the responsibility for error control from one 152 node to another 153 . Ability to cope with intermittent connectivity, including cases 154 where the sender and receiver are not concurrently present in 155 the network 156 . Ability to take advantage of scheduled, predicted, and 157 opportunistic connectivity, whether bidirectional or 158 unidirectional, in addition to continuous connectivity 159 . Late binding of overlay network endpoint identifiers to 160 underlying constituent network addresses 162 For descriptions of these capabilities and the rationale for the DTN 163 architecture, see [ARCH] and [SIGC]. 165 BP's location within the standard protocol stack is as shown in 166 Figure 1. BP uses underlying "native" transport and/or network 167 protocols for communications within a given constituent network. 169 The interface between the bundle protocol and a specific underlying 170 protocol is termed a "convergence layer adapter". 172 Figure 1 shows three distinct transport and network protocols 173 (denoted T1/N1, T2/N2, and T3/N3). 175 +-----------+ +-----------+ 176 | BP app | | BP app | 177 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 178 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 179 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 180 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 181 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 182 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 183 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 184 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 185 +-----------+ +-------------+ +-------------+ +-----------+ 186 | | | | 187 |<---- A network ---->| |<---- A network ---->| 188 | | | | 190 Figure 1: The Bundle Protocol in the Protocol Stack Model 192 This document describes the format of the protocol data units 193 (called "bundles") passed between entities participating in BP 194 communications. 196 The entities are referred to as "bundle nodes". This document does 197 not address: 199 . Operations in the convergence layer adapters that bundle nodes 200 use to transport data through specific types of internets. 201 (However, the document does discuss the services that must be 202 provided by each adapter at the convergence layer.) 203 . The bundle route computation algorithm. 204 . Mechanisms for populating the routing or forwarding information 205 bases of bundle nodes. 206 . The mechanisms for securing bundles en route. 207 . The mechanisms for managing bundle nodes. 209 Note that implementations of the specification presented in this 210 document will not be interoperable with implementations of RFC 5050. 212 2. Conventions used in this document 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 216 "OPTIONAL" in this document are to be interpreted as described in 217 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 218 capitals, as shown here. 220 3. Service Description 222 3.1. Definitions 224 Bundle - A bundle is a protocol data unit of BP, so named because 225 negotiation of the parameters of a data exchange may be impractical 226 in a delay-tolerant network: it is often better practice to "bundle" 227 with a unit of application data all metadata that might be needed in 228 order to make the data immediately usable when delivered to the 229 application. Each bundle comprises a sequence of two or more 230 "blocks" of protocol data, which serve various purposes. 232 Block - A bundle protocol block is one of the protocol data 233 structures that together constitute a well-formed bundle. 235 Application Data Unit (ADU) - An application data unit is the unit 236 of data whose conveyance to the bundle's destination is the purpose 237 for the transmission of some bundle that is not a fragment (as 238 defined below). 240 Bundle payload - A bundle payload (or simply "payload") is the 241 content of the bundle's payload block. The terms "bundle content", 242 "bundle payload", and "payload" are used interchangeably in this 243 document. For a bundle that is not a fragment (as defined below), 244 the payload is an application data unit. 246 Partial payload - A partial payload is a payload that comprises 247 either the first N bytes or the last N bytes of some other payload 248 of length M, such that 0 < N < M. Note that every partial payload 249 is a payload and therefore can be further subdivided into partial 250 payloads. 252 Fragment - A fragment is a bundle whose payload block contains a 253 partial payload. 255 Bundle node - A bundle node (or, in the context of this document, 256 simply a "node") is any entity that can send and/or receive bundles. 257 Each bundle node has three conceptual components, defined below, as 258 shown in Figure 2: a "bundle protocol agent", a set of zero or more 259 "convergence layer adapters", and an "application agent". 261 +-----------------------------------------------------------+ 262 |Node | 263 | | 264 | +-------------------------------------------------------+ | 265 | |Application Agent | | 266 | | | | 267 | | +--------------------------+ +----------------------+ | | 268 | | |Administrative element | |Application-specific | | | 269 | | | | |element | | | 270 | | | | | | | | 271 | | +--------------------------+ +----------------------+ | | 272 | | ^ ^ | | 273 | | Admin|records Application|data | | 274 | | | | | | 275 | +----------------v--------------------------v-----------+ | 276 | ^ | 277 | | ADUs | 278 | | | 279 | +-----------------------------v-------------------------+ | 280 | |Bundle Protocol Agent | | 281 | | | | 282 | | | | 283 | +-------------------------------------------------------+ | 284 | ^ ^ ^ | 285 | | Bundles | Bundles Bundles | | 286 | | | | | 287 | +------v-----+ +-----v------+ +-----v-----+ | 288 | |CLA 1 | |CLA 2 | |CLA n | | 289 | | | | | . . . | | | 290 | | | | | | | | 291 +-+------------+-----+------------+-----------+-----------+-+ 292 ^ ^ ^ 293 CL1|PDUs CL2|PDUs CLn|PDUs 294 | | | 295 +------v-----+ +-----v------+ +-----v-----+ 296 Network 1 Network 2 Network n 298 Figure 2: Components of a Bundle Node 300 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 301 the node component that offers the BP services and executes the 302 procedures of the bundle protocol. 304 Convergence layer adapter - A convergence layer adapter (CLA) is a 305 node component that sends and receives bundles on behalf of the BPA, 306 utilizing the services of some 'native' protocol stack that is 307 supported in one of the networks within which the node is 308 functionally located. 310 Application agent - The application agent (AA) of a node is the node 311 component that utilizes the BP services to effect communication for 312 some user purpose. The application agent in turn has two elements, 313 an administrative element and an application-specific element. 315 Application-specific element - The application-specific element of 316 an AA is the node component that constructs, requests transmission 317 of, accepts delivery of, and processes units of user application 318 data. 320 Administrative element - The administrative element of an AA is the 321 node component that constructs and requests transmission of 322 administrative records (defined below), including status reports, 323 and accepts delivery of and processes any administrative records 324 that the node receives. 326 Administrative record - A BP administrative record is an application 327 data unit that is exchanged between the administrative elements of 328 nodes' application agents for some BP administrative purpose. The 329 only administrative record defined in this specification is the 330 status report, discussed later. 332 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 333 of zero or more bundle nodes that all identify themselves for BP 334 purposes by some common identifier, called a "bundle endpoint ID" 335 (or, in this document, simply "endpoint ID"; endpoint IDs are 336 described in detail in Section 4.4.1 below). 338 Singleton endpoint - A singleton endpoint is an endpoint that always 339 contains exactly one member. 341 Registration - A registration is the state machine characterizing a 342 given node's membership in a given endpoint. Any single 343 registration has an associated delivery failure action as defined 344 below and must at any time be in one of two states: Active or 345 Passive. 347 Delivery - A bundle is considered to have been delivered at a node 348 subject to a registration as soon as the application data unit that 349 is the payload of the bundle, together with any relevant metadata 350 (an implementation matter), has been presented to the node's 351 application agent in a manner consistent with the state of that 352 registration. 354 Deliverability - A bundle is considered "deliverable" subject to a 355 registration if and only if (a) the bundle's destination endpoint is 356 the endpoint with which the registration is associated, (b) the 357 bundle has not yet been delivered subject to this registration, and 358 (c) the bundle has not yet been "abandoned" (as defined below) 359 subject to this registration. 361 Abandonment - To abandon a bundle subject to some registration is to 362 assert that the bundle is not deliverable subject to that 363 registration. 365 Delivery failure action - The delivery failure action of a 366 registration is the action that is to be taken when a bundle that is 367 "deliverable" subject to that registration is received at a time 368 when the registration is in the Passive state. 370 Destination - The destination of a bundle is the endpoint comprising 371 the node(s) at which the bundle is to be delivered (as defined 372 belowabove). 374 Transmission - A transmission is an attempt by a node's BPA to cause 375 copies of a bundle to be delivered to one or more of the nodes that 376 are members of some endpoint (the bundle's destination) in response 377 to a transmission request issued by the node's application agent. 379 Forwarding - To forward a bundle to a node is to invoke the services 380 of one or more CLAs in a sustained effort to cause a copy of the 381 bundle to be received by that node. 383 Discarding - To discard a bundle is to cease all operations on the 384 bundle and functionally erase all references to it. The specific 385 procedures by which this is accomplished are an implementation 386 matter. 388 Retention constraint - A retention constraint is an element of the 389 state of a bundle that prevents the bundle from being discarded. 390 That is, a bundle cannot be discarded while it has any retention 391 constraints. 393 Deletion - To delete a bundle is to remove unconditionally all of 394 the bundle's retention constraints, enabling the bundle to be 395 discarded. 397 3.2. Discussion of BP concepts 399 Multiple instances of the same bundle (the same unit of DTN protocol 400 data) might exist concurrently in different parts of a network -- 401 possibly differing in some blocks -- in the memory local to one or 402 more bundle nodes and/or in transit between nodes. In the context of 403 the operation of a bundle node, a bundle is an instance (copy), in 404 that node's local memory, of some bundle that is in the network. 406 The payload for a bundle forwarded in response to a bundle 407 transmission request is the application data unit whose location is 408 provided as a parameter to that request. The payload for a bundle 409 forwarded in response to reception of a bundle is the payload of the 410 received bundle. 412 In the most familiar case, a bundle node is instantiated as a single 413 process running on a general-purpose computer, but in general the 414 definition is meant to be broader: a bundle node might alternatively 415 be a thread, an object in an object-oriented operating system, a 416 special-purpose hardware device, etc. 418 The manner in which the functions of the BPA are performed is wholly 419 an implementation matter. For example, BPA functionality might be 420 coded into each node individually; it might be implemented as a 421 shared library that is used in common by any number of bundle nodes 422 on a single computer; it might be implemented as a daemon whose 423 services are invoked via inter-process or network communication by 424 any number of bundle nodes on one or more computers; it might be 425 implemented in hardware. 427 Every CLA implements its own thin layer of protocol, interposed 428 between BP and the (usually "top") protocol(s) of the underlying 429 native protocol stack; this "CL protocol" may only serve to 430 multiplex and de-multiplex bundles to and from the underlying native 431 protocol, or it may offer additional CL-specific functionality. The 432 manner in which a CLA sends and receives bundles, as well as the 433 definitions of CLAs and CL protocols, are beyond the scope of this 434 specification. 436 Note that the administrative element of a node's application agent 437 may itself, in some cases, function as a convergence-layer adapter. 438 That is, outgoing bundles may be "tunneled" through encapsulating 439 bundles: 441 . An outgoing bundle constitutes a byte array. This byte array 442 may, like any other, be presented to the bundle protocol agent 443 as an application data unit that is to be transmitted to some 444 endpoint. 445 . The original bundle thus forms the payload of an encapsulating 446 bundle that is forwarded using some other convergence-layer 447 protocol(s). 449 . When the encapsulating bundle is received, its payload is 450 delivered to the peer application agent administrative element, 451 which then instructs the bundle protocol agent to dispatch that 452 original bundle in the usual way. 454 The purposes for which this technique may be useful (such as cross- 455 domain security) are beyond the scope of this specification. 457 The only interface between the BPA and the application-specific 458 element of the AA is the BP service interface. But between the BPA 459 and the administrative element of the AA there is a (conceptual) 460 private control interface in addition to the BP service interface. 461 This private control interface enables the BPA and the 462 administrative element of the AA to direct each other to take action 463 under specific circumstances. 465 In the case of a node that serves simply as a BP "router", the AA 466 may have no application-specific element at all. The application- 467 specific elements of other nodes' AAs may perform arbitrarily 468 complex application functions, perhaps even offering multiplexed DTN 469 communication services to a number of other applications. As with 470 the BPA, the manner in which the AA performs its functions is wholly 471 an implementation matter. 473 Singletons are the most familiar sort of endpoint, but in general 474 the endpoint notion is meant to be broader. For example, the nodes 475 in a sensor network might constitute a set of bundle nodes that 476 identify themselves by a single common endpoint ID and thus form a 477 single bundle endpoint. *Note* too that a given bundle node might 478 identify itself by multiple endpoint IDs and thus be a member of 479 multiple bundle endpoints. 481 The destination of every bundle is an endpoint, which may or may not 482 be singleton. The source of every bundle is a node, identified by 483 the endpoint ID for some singleton endpoint that contains that node. 484 Note, though, that the source node ID asserted in a given bundle may 485 be the null endpoint ID (as described later) rather than the 486 endpoint ID of the actual source node; bundles for which the 487 asserted source node ID is the null endpoint ID are termed 488 "anonymous" bundles. 490 Any number of transmissions may be concurrently undertaken by the 491 bundle protocol agent of a given node. 493 When the bundle protocol agent of a node determines that a bundle 494 must be forwarded to a node (either to a node that is a member of 495 the bundle's destination endpoint or to some intermediate forwarding 496 node) in the course of completing the successful transmission of 497 that bundle, the bundle protocol agent invokes the services of one 498 or more CLAs in a sustained effort to cause a copy of the bundle to 499 be received by that node. 501 Upon reception, the processing of a bundle that has been received by 502 a given node depends on whether or not the receiving node is 503 registered in the bundle's destination endpoint. If it is, and if 504 the payload of the bundle is non-fragmentary (possibly as a result 505 of successful payload reassembly from fragmentary payloads, 506 including the original payload of the newly received bundle), then 507 the bundle is normally delivered to the node's application agent 508 subject to the registration characterizing the node's membership in 509 the destination endpoint. 511 The bundle protocol does not natively ensure delivery of a bundle to 512 its destination. Data loss along the path to the destination node 513 can be minimized by utilizing reliable convergence-layer protocols 514 between neighbors on all segments of the end-to-end path, but for 515 end-to-end bundle delivery assurance it will be necessary to develop 516 extensions to the bundle protocol and/or application-layer 517 mechanisms. 519 The bundle protocol is designed for extensibility. Bundle protocol 520 extensions, documented elsewhere, may extend this specification by: 522 . defining additional blocks; 523 . defining additional administrative records; 524 . defining additional bundle processing flags; 525 . defining additional block processing flags; 526 . defining additional types of bundle status reports; 527 . defining additional bundle status report reason codes; 528 . defining additional mandates and constraints on processing 529 that conformant bundle protocol agents must perform at 530 specified points in the inbound and outbound bundle processing 531 cycles. 533 3.3. Services Offered by Bundle Protocol Agents 535 The BPA of each node is expected to provide the following services 536 to the node's application agent: 538 . commencing a registration (registering the node in an 539 endpoint); 540 . terminating a registration; 541 . switching a registration between Active and Passive states; 542 . transmitting a bundle to an identified bundle endpoint; 543 . canceling a transmission; 544 . polling a registration that is in the Passive state; 545 . delivering a received bundle. 547 4. Bundle Format 549 The format of bundles SHALL conform to the Concise Binary Object 550 Representation (CBOR [RFC7049]). 552 Each bundle SHALL be a concatenated sequence of at least two blocks, 553 represented as a CBOR indefinite-length array. The first block in 554 the sequence (the first item of the array) MUST be a primary bundle 555 block in CBOR representation as described below; the bundle MUST 556 have exactly one primary bundle block. The primary block MUST be 557 followed by one or more canonical bundle blocks (additional array 558 items) in CBOR representation as described in 4.2.3 below. The last 559 such block MUST be a payload block; the bundle MUST have exactly one 560 payload block. The last item of the array, immediately following 561 the payload block, SHALL be a CBOR "break" stop code. 563 (Note that, while CBOR permits considerable flexibility in the 564 encoding of bundles, this flexibility must not be interpreted as 565 inviting increased complexity in protocol data unit structure.) 567 An implementation of the Bundle Protocol MAY discard any sequence of 568 bytes that does not conform to the Bundle Protocol specification. 570 An implementation of the Bundle Protocol MAY accept a sequence of 571 bytes that does not conform to the Bundle Protocol specification 572 (e.g., one that represents data elements in fixed-length arrays 573 rather than indefinite-length arrays) and transform it into 574 conformant BP structure before processing it. Procedures for 575 accomplishing such a transformation are beyond the scope of this 576 specification. 578 4.1. BP Fundamental Data Structures 580 4.1.1. CRC Type 582 CRC type is an unsigned integer type code for which the following 583 values (and no others) are valid: 585 . 0 indicates "no CRC is present." 586 . 1 indicates "a standard X-25 CRC-16 is present." [CRC16] 587 . 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present." 588 [CRC32C] 590 CRC type SHALL be represented as a CBOR unsigned integer. 592 For examples of CRC32C CRCs, see Appendix A.4 of [RFC7143]. 594 4.1.2. CRC 596 CRC SHALL be omitted from a block if and only if the block's CRC 597 type code is zero. 599 When not omitted, the CRC SHALL be represented as a CBOR unsigned 600 integer eitherbyte string of two bytes (that is, CBOR additional 601 information 252, if CRC type is 1) or as a sequence of four bytes 602 (that is, CBOR additional information 264, if CRC type is 2); in 603 each case the sequence of bytes SHALL constitute an unsigned integer 604 value (of 16 or 32 bits, respectively) in network byte order. 606 4.1.3. Bundle Processing Control Flags 608 Bundle processing control flags assert properties of the bundle as a 609 whole rather than of any particular block of the bundle. They are 610 conveyed in the primary block of the bundle. 612 The following properties are asserted by the bundle processing 613 control flags: 615 . The bundle is a fragment. (Boolean) 617 . The bundle's payload is an administrative record. (Boolean) 619 . The bundle must not be fragmented. (Boolean) 621 . Acknowledgment by the user application is requested. (Boolean) 623 . Status time is requested in all status reports. (Boolean) 625 . The bundle contains a "manifest" extension block. (Boolean) 627 . Flags requesting types of status reports (all Boolean): 629 o Request reporting of bundle reception. 631 o Request reporting of bundle forwarding. 633 o Request reporting of bundle delivery. 635 o Request reporting of bundle deletion. 637 If the bundle processing control flags indicate that the bundle's 638 application data unit is an administrative record, then all status 639 report request flag values must be zero. 641 If the bundle's source node is omitted (i.e., the source node ID is 642 the ID of the null endpoint, which has no members as discussed 643 below; this option enables anonymous bundle transmission), then the 644 bundle is not uniquely identifiable and all bundle protocol features 645 that rely on bundle identity must therefore be disabled: the "Bundle 646 must not be fragmented" flag value must be 1 and all status report 647 request flag values must be zero. 649 The bundle processing control flags SHALL be represented as a CBOR 650 unsigned integer item, of two bytes (that is, CBOR additional 651 information 25) containingthe value of which SHALL be processed as a 652 bit field of 16 bits indicating the control flag values as follows 653 (note that bit numbering in this instance is reversed from the usual 654 practice, beginning with the low-order bit instead of the high-order 655 bit, in recognition of the potential definition of additional 656 control flag values in the future): 658 . Bit 0 (the low-order bit, 0x000001: bundle is a fragment. 659 . Bit 1 (0x000002): payload is an administrative record. 660 . Bit 2 (0x000004): bundle must not be fragmented. 661 . Bit 3 (0x000008): reserved. 662 . Bit 4 (0x000010): reserved. 663 . Bit 5 (0x000020): user application acknowledgement is 664 requested. 665 . Bit 6 (0x000040): status time is requested in all status 666 reports. 667 . Bit 7 (0x000080): reserved. 668 . Bit 8 (0x000100): reserved. 669 . Bit 9 (0x000200): reserved. 670 . Bit 10(0x000400): reserved. 671 . Bit 11(0x000800): reserved. 672 . Bit 12(0x001000): reserved. 673 . Bit 13(0x002000): reserved. 674 . Bit 14(0x004000): bundle reception status reports are 675 requested. 676 . Bit 15(0x008000): reserved. 677 . Bit 16(0x010000): bundle forwarding status reports are 678 requested. 679 . Bit 17(0x020000): bundle delivery status reports are requested. 680 . Bit 18(0x040000): bundle deletion status reports are requested. 681 . Bits 19-20 are reserved. 682 . Bits 21-63 are unassigned. 684 4.1.4. Block Processing Control Flags 686 The block processing control flags assert properties of canonical 687 bundle blocks. They are conveyed in the header of the block to 688 which they pertain. 690 The following properties are asserted by the block processing 691 control flags: 693 . This block must be replicated in every fragment. (Boolean) 695 . Transmission of a status report is requested if this block 696 can't be processed. (Boolean) 698 . Block must be removed from the bundle if it can't be processed. 699 (Boolean) 701 . Bundle must be deleted if this block can't be processed. 702 (Boolean) 704 For each bundle whose bundle processing control flags indicate that 705 the bundle's application data unit is an administrative record, or 706 whose source node ID is the null endpoint ID as defined below, the 707 value of the "Transmit status report if block can't be processed" 708 flag in every canonical block of the bundle must be zero. 710 The block processing control flags SHALL be represented as a CBOR 711 unsigned integer item, of 1 byte (that is, CBOR additional 712 information 24) containingthe value of which SHALL be processed as a 713 bit field of 8 bits indicating the control flag values as follows 714 (note that bit numbering in this instance is reversed from the usual 715 practice, beginning with the low-order bit instead of the high-order 716 bit, for agreement with the bit numbering of the bundle processing 717 control flags): 719 . Bit 0(the low-order bit, 0x01): block must be replicated in 720 every fragment. 721 . Bit 1(0x02): transmission of a status report is requested if 722 block can't be processed. 723 . Bit 2(0x04): bundle must be deleted if block can't be 724 processed. 725 . Bit 3(0x08): reserved. 726 . Bit 4(0x10): block must be removed from bundle if it can't be 727 processed. 728 . Bit 5(0x20): reserved. 729 . Bit 6 (0x40): reserved. 730 . Bits 7-63 are unassigned. 732 4.1.5. Identifiers 734 4.1.5.1. Endpoint ID 736 The destinations of bundles are bundle endpoints, identified by text 737 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 738 (EID) is a Uniform Resource Identifier (URI; [URI]). As such, each 739 endpoint ID can be characterized as having this general structure: 741 < scheme name > : < scheme-specific part, or "SSP" > 743 The scheme identified by the < scheme name > in an endpoint ID is a 744 set of syntactic and semantic rules that fully explain how to parse 745 and interpret the SSP. The set of allowable schemes is effectively 746 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 747 protocol endpoint ID. 749 Note that, although endpoint IDs are URIs, implementations of the BP 750 service interface may support expression of endpoint IDs in some 751 internationalized manner (e.g., Internationalized Resource 752 Identifiers (IRIs); see [RFC3987]). 754 The endpoint ID "dtn:none" identifies the "null endpoint", the 755 endpoint that by definition never has any members. 757 Each BP endpoint ID (EID) SHALL be represented as a CBOR array 758 comprising a 2-tuple. 760 The first item of the array SHALL be the code number identifying the 761 endpoint's URI scheme [URI], as defined in the registry of URI 762 scheme code numbers for Bundle Protocol maintained by IANA as 763 described in Section 10. [URIREG]. Each URI scheme code number 764 SHALL be represented as a CBOR unsigned integer. 766 The second item of the array SHALL be the applicable CBOR 767 representation of the scheme-specific part (SSP) of the EID, defined 768 as follows: 770 . If the EID's URI scheme is "dtn" then the SSP SHALL be 771 represented as a CBOR text string unless the EID's SSP is 772 "none", in which case the SSP SHALL be represented as a CBOR 773 unsigned integer with the value zero. 774 . If the EID's URI scheme is "ipn" then the SSP SHALL be 775 represented as a CBOR array comprising a 2-tuple. The first 776 item of this array SHALL be the EID's node number represented 777 as a CBOR unsigned integer. The second item of this array 778 SHALL be the EID's service number represented as a CBOR 779 unsigned integer. 780 . Definitions of the CBOR representations of the SSPs of EIDs 781 encoded in other URI schemes are included in the specifications 782 defining those schemes. 784 4.1.5.2. Node ID 786 For many purposes of the Bundle Protocol it is important to identify 787 the node that is operative in some context. 789 As discussed in 3.1 above, nodes are distinct from endpoints; 790 specifically, an endpoint is a set of zero or more nodes. But 791 rather than define a separate namespace for node identifiers, we 792 instead use endpoint identifiers to identify nodes, subject to the 793 following restrictions: 795 . Every node MUST be a member of at least one singleton endpoint. 796 . The EID of any singleton endpoint of which a node is a member 797 MAY be used to identify that node. A "node ID" is an EID that 798 is used in this way. 799 . A node's membership in a given singleton endpoint MUST be 800 sustained at least until the nominal operation of the Bundle 801 Protocol no longer depends on the identification of that node 802 using that endpoint's ID. 804 4.1.6. DTN Time 806 A DTN time is an unsigned integer indicating an interval of Unix 807 epoch time [EPOCH] that has elapsed since the start of the year 2000 808 on the Coordinated Universal Time (UTC) scale [UTC], which is Unix 809 epoch timestamp 946684800. (Note that the DTN time that equates to 810 the current time as reported by the UNIX time() function can be 811 derived by subtracting 946684800 from that reported time value.) 812 Each DTN time SHALL be represented as a CBOR unsigned integer item. 814 Note: The choice of Unix epoch time as the scale on which time 815 values in DTN are expressed may need some explanation. 817 The computation of time intervals is integral to several DTN 818 protocol procedures. Inconsistency in the results of these 819 computations would result in inconsistent performance of those 820 procedures and would compromise the operation of the protocol. 822 So the key qualities sought in selecting the time scale to be used 823 for expressing DTN times were these: (a) the broadest possible 824 access to the value of the current time on the selected time scale, 825 enabling all nodes of the network to perform protocol procedures in 826 the same way using the same information, and (b) ease of time 827 interval computation. 829 UTC was an obvious candidate but fell short on both counts. First, 830 millions of devices can readily query the current UTC time, thanks 831 to NTP, but spacecraft operating beyond Earth orbit cannot. There 832 is currently no adaptation of NTP that operates over the long and 833 variable signal propagation delays between vehicles in deep space. 835 Moreover, computing the number of actual elapsed seconds between two 836 UTC times is non-trivial because UTC times include leap seconds. As 837 an illustration of the issue, consider the passage of UTC and TAI 838 time at a ground station antenna that began transmitting data at 839 8Kbps around midnight December 31, 2016 (UTC), when a leap second 840 was added (*): 842 UTC TAI Total bytes sent 844 t1 2016-12-31 23:59:58 2017-01-01 00:00:34 0 846 t2 2016-12-31 23:59:59 2017-01-01 00:00:35 1000 848 t3 2016-12-31 23:59:60* 2017-01-01 00:00:36 2000 850 t4 2017-01-01 00:00:00 2017-01-01 00:00:37 3000 852 t5 2017-01-01 00:00:01 2017-01-01 00:00:38 4000 854 Suppose we must compute the volume of data transmitted in the 855 interval between t1 and t5. If we use TAI time values, the elapsed 856 time interval is 4 seconds (00:00:38 minus 00:00:34); at 8Kbps, the 857 computed transmission volume is 4000 bytes, which is correct. If we 858 instead use UTC time values as stated, without special compensation 859 for the insertion of the leap second, the elapsed time interval is 3 860 seconds (00:00:01 minus 23:59:58); the computed transmission volume 861 is then 3000 bytes, which is incorrect. 863 TAI, then, would be an ideal time scale for DTN, as the interval in 864 seconds between two TAI times can be computed by simply subtracting 865 one from the other; there is no need to consult a table of leap 866 seconds each time a time interval is computed. Unfortunately the 867 current value of TAI, as tracked by atomic clocks on Earth and 868 carefully managed by the International Bureau of Weights and 869 Measures, is likewise not directly accessible to spacecraft. 871 Unix epoch time is the next best option. Like TAI, Unix epoch time 872 is simply a count of seconds elapsed since a standard epoch. Unlike 873 TAI, the current value of Unix epoch time is provided by virtually 874 all operating systems on which BP is likely to run. 876 Implementers of Bundle Protocol need to be aware that the difference 877 between DTN time and UTC time will increase with the passing years 878 as additional leap seconds are inserted into UTC. Converting DTN 879 time to the correct corresponding UTC time, in the event that such 880 conversion is needed, will require an understanding of the leap 881 second adjustments made to UTC over time; for software written in C, 882 the widely supported gmtime() function provides this service. 884 Implementers also need to be aware that DTN time values conveyed in 885 CBOR representation in bundles can conceivably exceed (2**32 - 1). 887 4.1.7. Creation Timestamp 889 Each creation timestamp SHALL be represented as a CBOR array item 890 comprising a 2-tuple. 892 The first item of the array SHALL be a DTN time. 894 The second item of the array SHALL be the creation timestamp's 895 sequence number, represented as a CBOR unsigned integer. 897 4.1.8. Block-type-specific Data 899 Block-type-specific data in each block (other than the primary 900 block) SHALL be the applicable CBOR representation of the content of 901 the block. Details of this representation are included in the 902 specification defining the block type. 904 4.2. Bundle Representation 906 This section describes the primary block in detail and non-primary 907 blocks in general. Rules for processing these blocks appear in 908 Section 5 of this document. 910 Note that supplementary DTN protocol specifications (including, but 911 not restricted to, the Bundle Security Protocol [BPSEC]) may require 912 that BP implementations conforming to those protocols construct and 913 process additional blocks. 915 4.2.1. Bundle 917 Each bundle SHALL be represented as a CBOR indefinite-length array. 918 The first item of this array SHALL be the CBOR representation of a 919 Primary Block. Every other item of the array except the last SHALL 920 be the CBOR representation of a Canonical Block. The last item of 921 the array SHALL be a CBOR "break" stop code. 923 Associated with each block of a bundle is a block number. The block 924 number uniquely identifies the block within the bundle, enabling 925 blocks (notably bundle security protocol blocks) to reference other 926 blocks in the same bundle without ambiguity. The block number of 927 the primary block is implicitly zero; the block numbers of all other 928 blocks are explicitly stated in block headers as noted below. Block 929 numbering is unrelated to the order in which blocks are sequenced in 930 the bundle. The block number of the payload block is always 1. 932 4.2.2. Primary Bundle Block 934 The primary bundle block contains the basic information needed to 935 forward bundles to their destinations. 937 Each primary block SHALL be represented as a CBOR array; the number 938 of elements in the array SHALL be 8 (if the bundle is not a fragment 939 and the block has no CRC), 9 (if the block has a CRC and the bundle 940 is not a fragment), 10 (if the bundle is a fragment and the block 941 has no CRC), or 11 (if the bundle is a fragment and the block has a 942 CRC). 944 The primary block of each bundle SHALL be immutable. The values of 945 all fields in the primary block must remain unchanged from the time 946 the block is created to the time it is delivered. 948 The fields of the primary bundle block SHALL be as follows, listed 949 in the order in which they MUST appear: 951 Version: An unsigned integer value indicating the version of the 952 bundle protocol that constructed this block. The present document 953 describes version 7 of the bundle protocol. Version number SHALL be 954 represented as a CBOR unsigned integer item. 956 Bundle Processing Control Flags: The Bundle Processing Control Flags 957 are discussed in Section 4.1.3. above. 959 CRC Type: CRC Type codes are discussed in Section 4.1.1. above. The 960 CRC Type code for the primary block MAY be zero if the bundle 961 contains a BPsec [BPSEC] Block Integrity Block whose target is the 962 primary block; otherwise the CRC Type code for the primary block 963 MUST be non-zero. 965 Destination EID: The Destination EID field identifies the bundle 966 endpoint that is the bundle's destination, i.e., the endpoint that 967 contains the node(s) at which the bundle is to be delivered. 969 Source node ID: The Source node ID field identifies the bundle node 970 at which the bundle was initially transmitted, except that Source 971 node ID may be the null endpoint ID in the event that the bundle's 972 source chooses to remain anonymous. 974 Report-to EID: The Report-to EID field identifies the bundle 975 endpoint to which status reports pertaining to the forwarding and 976 delivery of this bundle are to be transmitted. 978 Creation Timestamp: The creation timestamp (discussed in 4.1.7 979 above) comprises two unsigned integers that, together with the 980 source node ID and (if the bundle is a fragment) the fragment offset 981 and payload length, serve to identify the bundle. The first of these 982 integers is the bundle's creation time, while the second is the 983 bundle's creation timestamp sequence number. Bundle creation time 984 SHALL be the DTN time at which the transmission request was received 985 that resulted in the creation of the bundle. Sequence count SHALL be 986 the latest value (as of the time at which that transmission request 987 was received) of a monotonically increasing positive integer counter 988 managed by the source node's bundle protocol agent that MAY be reset 989 to zero whenever the current time advances by one second. For nodes 990 that lack accurate clocks, it is recommended that bundle creation 991 time be set to zero and that the counter used as the source of the 992 bundle sequence count never be reset to zero. Note that, in general, 993 the creation of two distinct bundles with the same source node ID 994 and bundle creation timestamp may result in unexpected network 995 behavior and/or suboptimal performance. The combination of source 996 node ID and bundle creation timestamp serves to identify a single 997 transmission request, enabling it to be acknowledged by the 998 receiving application (provided the source node ID is not the null 999 endpoint ID). 1001 Lifetime: The lifetime field is an unsigned integer that indicates 1002 the time at which the bundle's payload will no longer be useful, 1003 encoded as a number of microseconds past the creation time. (For 1004 high-rate deployments with very brief disruptions, fine-grained 1005 expression of bundle lifetime may be useful.) When a bundle's age 1006 exceeds its lifetime, bundle nodes need no longer retain or forward 1007 the bundle; the bundle SHOULD be deleted from the network. For 1008 bundles originating at nodes that lack accurate clocks, it is 1009 recommended that bundle age be obtained from the Bundle Age 1010 extension block (see 4.3.2 below) rather than from the difference 1011 between current time and bundle creation time. Bundle lifetime 1012 SHALL be represented as a CBOR unsigned integer item. 1014 Fragment offset: If and only if the Bundle Processing Control Flags 1015 of this Primary block indicate that the bundle is a fragment, 1016 fragment offset SHALL be present in the primary block. Fragment 1017 offset SHALL be represented as a CBOR unsigned integer indicating 1018 the offset from the start of the original application data unit at 1019 which the bytes comprising the payload of this bundle were located. 1021 Total Application Data Unit Length: If and only if the Bundle 1022 Processing Control Flags of this Primary block indicate that the 1023 bundle is a fragment, total application data unit length SHALL be 1024 present in the primary block. Total application data unit length 1025 SHALL be represented as a CBOR unsigned integer indicating the total 1026 length of the original application data unit of which this bundle's 1027 payload is a part. 1029 CRC: A CRC SHALL be present in the primary block unless the bundle 1030 includes a BPsec [BPSEC] Block Integrity Block whose target is the 1031 primary block, in which case a CRC MAY be present in the primary 1032 block. The length and nature of the CRC SHALL be as indicated by 1033 the CRC type. The CRC SHALL be computed over the concatenation of 1034 all bytes (including CBOR "break" characters) of the primary block 1035 including the CRC field itself, which for this purpose SHALL be 1036 temporarily populated with the value zero. 1038 4.2.3. Canonical Bundle Block Format 1040 Every block other than the primary block (all such blocks are termed 1041 "canonical" blocks) SHALL be represented as a CBOR array; the number 1042 of elements in the array SHALL be 5 (if CRC type is zero) or 6 1043 (otherwise). 1045 The fields of every canonical block SHALL be as follows, listed in 1046 the order in which they MUST appear: 1048 . Block type code, an unsigned integer. Bundle block type code 1 1049 indicates that the block is a bundle payload block. Block type 1050 codes 2 through 9 are explicitly reserved as noted later in 1051 this specification. Block type codes 192 through 255 are not 1052 reserved and are available for private and/or experimental use. 1053 All other block type code values are reserved for future use. 1054 . Block number, an unsigned integer as discussed in 4.2.1 above. 1055 Block number SHALL be represented as a CBOR unsigned integer. 1057 . Block processing control flags as discussed in Section 4.1.4 1058 above. 1059 . CRC type as discussed in Section 4.1.1 above. 1060 . Block-type-specific data represented as a single definite- 1061 length CBOR byte string, i.e., a CBOR byte string that is not 1062 of indefinite length. For each type of block, the block-type- 1063 specific data byte string is the serialization, in a block- 1064 type-specific manner, of the data conveyed by that type of 1065 block; definitions of blocks are required to define the manner 1066 in which block-type-specific data are serialized within the 1067 block-type-specific data field. For the Payload Block in 1068 particular (block type 1), the block-type-specific data field, 1069 termed the "payload", SHALL be an application data unit, or 1070 some contiguous extent thereof, represented as a definite- 1071 length CBOR byte string. 1072 . If and only if the value of the CRC type field of this block is 1073 non-zero, a CRC. If present, the length and nature of the CRC 1074 SHALL be as indicated by the CRC type and the CRC SHALL be 1075 computed over the concatenation of all bytes of the block 1076 (including CBOR "break" characters) including the CRC field 1077 itself, which for this purpose SHALL be temporarily populated 1078 with the value zero. 1080 4.3. Extension Blocks 1082 "Extension blocks" are all blocks other than the primary and payload 1083 blocks. Because not all extension blocks are defined in the Bundle 1084 Protocol specification (the present document), not all nodes 1085 conforming to this specification will necessarily instantiate Bundle 1086 Protocol implementations that include procedures for processing 1087 (that is, recognizing, parsing, acting on, and/or producing) all 1088 extension blocks. It is therefore possible for a node to receive a 1089 bundle that includes extension blocks that the node cannot process. 1090 The values of the block processing control flags indicate the action 1091 to be taken by the bundle protocol agent when this is the case. 1093 Extension block types 2 11 and 123 are reserved for the Block 1094 Integrity Block and Block Confidentiality Block as defined in the 1095 Bundle Security Protocol specification [BPSEC]. 1097 The following extension block types are reserved for extension 1098 blocks for which a need is anticipated but for which no definitions 1099 yet exist: 1101 . Block type 134 is reserved for the anticipated Manifest Block. 1102 Note: it is anticipated that the manifest block will identify 1103 the blocks that were present in the bundle at the time it was 1104 created, implying that the bundle MUST contain one (1) 1105 occurrence of this type of block if the value of the "manifest" 1106 flag in the bundle processing control flags (anticipated but 1107 not yet defined) is 1, but otherwise the bundle MUST NOT 1108 contain any Manifest block. 1109 . Block type 145 is reserved for the anticipated Metadata Block. 1110 Note: the structure and function of the anticipated Metadata 1111 Block are currently undefined. 1112 . Block type 156 is reserved for the anticipated Data Label 1113 Block. Note: it is anticipated that the data label block will 1114 provide additional information that can assist nodes in making 1115 forwarding decisions. 1117 The following extension blocks are defined in the current document. 1119 4.3.1. Previous Node 1121 The Previous Node block, block type 67, identifies the node that 1122 forwarded this bundle to the local node (i.e., to the node at which 1123 the bundle currently resides); its block-type-specific data is the 1124 node ID of that forwarder node which SHALL take the form of a node 1125 ID represented as described in Section 4.1.5.2. above. If the local 1126 node is the source of the bundle, then the bundle MUST NOT contain 1127 any previous node block. Otherwise the bundle SHOULD contain one 1128 (1) occurrence of this type of block. 1130 4.3.2. Bundle Age 1132 The Bundle Age block, block type 87, contains the number of 1133 microseconds that have elapsed between the time the bundle was 1134 created and time at which it was most recently forwarded. It is 1135 intended for use by nodes lacking access to an accurate clock, to 1136 aid in determining the time at which a bundle's lifetime expires. 1137 The block-type-specific data of this block is an unsigned integer 1138 containing the age of the bundle in microseconds, which SHALL be 1139 represented as a CBOR unsigned integer item. (The age of the bundle 1140 is the sum of all known intervals of the bundle's residence at 1141 forwarding nodes, up to the time at which the bundle was most 1142 recently forwarded, plus the summation of signal propagation time 1143 over all episodes of transmission between forwarding nodes. 1144 Determination of these values is an implementation matter.) If the 1145 bundle's creation time is zero, then the bundle MUST contain exactly 1146 one (1) occurrence of this type of block; otherwise, the bundle MAY 1147 contain at most one (1) occurrence of this type of block. A bundle 1148 MUST NOT contain multiple occurrences of the bundle age block, as 1149 this could result in processing anomalies. 1151 4.3.3. Hop Count 1153 The Hop Count block, block type 109, contains two unsigned integers, 1154 hop limit and hop count. A "hop" is here defined as an occasion on 1155 which a bundle was forwarded from one node to another node. Hop 1156 limit MUST be in the range 1 through 255. The hop limit value SHOULD 1157 NOT be changed at any time after creation of the Hop Count block; 1158 the hop count value SHOULD initially be zero and SHOULD be increased 1159 by 1 on each hop. 1161 The hop count block is mainly intended as a safety mechanism, a 1162 means of identifying bundles for removal from the network that can 1163 never be delivered due to a persistent forwarding error. When a 1164 bundle's hop count exceeds its hop limit, the bundle SHOULD be 1165 deleted for the reason "hop limit exceeded", following the bundle 1166 deletion procedure defined in Section 5.10. . Procedures for 1167 determining the appropriate hop limit for a block are beyond the 1168 scope of this specification. The block-type-specific data in a hop 1169 count block SHALL be represented as a CBOR array comprising a 2- 1170 tuple. The first item of this array SHALL be the bundle's hop 1171 limit, represented as a CBOR unsigned integer. The second item of 1172 this array SHALL be the bundle's hop count, represented as a CBOR 1173 unsigned integer. A bundle MAY contain at most one (1) occurrence of 1174 this type of block. 1176 5. Bundle Processing 1178 The bundle processing procedures mandated in this section and in 1179 Section 6 govern the operation of the Bundle Protocol Agent and the 1180 Application Agent administrative element of each bundle node. They 1181 are neither exhaustive nor exclusive. Supplementary DTN protocol 1182 specifications (including, but not restricted to, the Bundle 1183 Security Protocol [BPSEC]) may augment, override, or supersede the 1184 mandates of this document. 1186 5.1. Generation of Administrative Records 1188 All transmission of bundles is in response to bundle transmission 1189 requests presented by nodes' application agents. When required to 1190 "generate" an administrative record (such as a bundle status 1191 report), the bundle protocol agent itself is responsible for causing 1192 a new bundle to be transmitted, conveying that record. In concept, 1193 the bundle protocol agent discharges this responsibility by 1194 directing the administrative element of the node's application agent 1195 to construct the record and request its transmission as detailed in 1196 Section 6 below. In practice, the manner in which administrative 1197 record generation is accomplished is an implementation matter, 1198 provided the constraints noted in Section 6 are observed. 1200 Note that requesting status reports for any single bundle might 1201 easily result in the generation of (1 + (2 *(N-1))) status report 1202 bundles, where N is the number of nodes on the path from the 1203 bundle's source to its destination, inclusive. That is, the 1204 requesting of status reports for large numbers of bundles could 1205 result in an unacceptable increase in the bundle traffic in the 1206 network. For this reason, the generation of status reports MUST be 1207 disabled by default and enabled only when the risk of excessive 1208 network traffic is deemed acceptable. 1210 When the generation of status reports is enabled, the decision on 1211 whether or not to generate a requested status report is left to the 1212 discretion of the bundle protocol agent. Mechanisms that could 1213 assist in making such decisions, such as pre-placed agreements 1214 authorizing the generation of status reports under specified 1215 circumstances, are beyond the scope of this specification. 1217 Notes on administrative record terminology: 1219 . A "bundle reception status report" is a bundle status report 1220 with the "reporting node received bundle" flag set to 1. 1221 . A "bundle forwarding status report" is a bundle status report 1222 with the "reporting node forwarded the bundle" flag set to 1. 1223 . A "bundle delivery status report" is a bundle status report 1224 with the "reporting node delivered the bundle" flag set to 1. 1225 . A "bundle deletion status report" is a bundle status report 1226 with the "reporting node deleted the bundle" flag set to 1. 1228 5.2. Bundle Transmission 1230 The steps in processing a bundle transmission request are: 1232 Step 1: Transmission of the bundle is initiated. An outbound bundle 1233 MUST be created per the parameters of the bundle transmission 1234 request, with the retention constraint "Dispatch pending". The 1235 source node ID of the bundle MUST be either the null endpoint ID, 1236 indicating that the source of the bundle is anonymous, or else the 1237 EID of a singleton endpoint whose only member is the node of which 1238 the BPA is a component. 1240 Step 2: Processing proceeds from Step 1 of Section 5.4. 1242 5.3. Bundle Dispatching 1244 The steps in dispatching a bundle are: 1246 Step 1: If the bundle's destination endpoint is an endpoint of which 1247 the node is a member, the bundle delivery procedure defined in 1248 Section 5.7 MUST be followed and for the purposes of all subsequent 1249 processing of this bundle at this node the node's membership in the 1250 bundle's destination endpoint SHALL be disavowed; specifically, even 1251 though the node is a member of the bundle's destination endpoint, 1252 the node SHALL NOT undertake to forward the bundle to itself in the 1253 course of performing the procedure described in Section 5.4. 1255 Step 2: Processing proceeds from Step 1 of Section 5.4. 1257 5.4. Bundle Forwarding 1259 The steps in forwarding a bundle are: 1261 Step 1: The retention constraint "Forward pending" MUST be added to 1262 the bundle, and the bundle's "Dispatch pending" retention constraint 1263 MUST be removed. 1265 Step 2: The bundle protocol agent MUST determine whether or not 1266 forwarding is contraindicated for any of the reasons listed in 1267 Figure 4. In particular: 1269 . The bundle protocol agent MAY choose either to forward the 1270 bundle directly to its destination node(s) (if possible) or to 1271 forward the bundle to some other node(s) for further 1272 forwarding. The manner in which this decision is made may 1273 depend on the scheme name in the destination endpoint ID and/or 1274 on other state but in any case is beyond the scope of this 1275 document. If the BPA elects to forward the bundle to some other 1276 node(s) for further forwarding but finds it impossible to 1277 select any node(s) to forward the bundle to, then forwarding is 1278 contraindicated. 1279 . Provided the bundle protocol agent succeeded in selecting the 1280 node(s) to forward the bundle to, the bundle protocol agent 1281 MUST subsequently select the convergence layer adapter(s) whose 1282 services will enable the node to send the bundle to those 1283 nodes. The manner in which specific appropriate convergence 1284 layer adapters are selected is beyond the scope of this 1285 document. If the agent finds it impossible to select any 1286 appropriate convergence layer adapter(s) to use in forwarding 1287 this bundle, then forwarding is contraindicated. 1289 Step 3: If forwarding of the bundle is determined to be 1290 contraindicated for any of the reasons listed in Figure 4, then the 1291 Forwarding Contraindicated procedure defined in Section 5.4.1 MUST 1292 be followed; the remaining steps of Section 5.4 are skipped at this 1293 time. 1295 Step 4: For each node selected for forwarding, the bundle protocol 1296 agent MUST invoke the services of the selected convergence layer 1297 adapter(s) in order to effect the sending of the bundle to that 1298 node. Determining the time at which the bundle protocol agent 1299 invokes convergence layer adapter services is a BPA implementation 1300 matter. Determining the time at which each convergence layer 1301 adapter subsequently responds to this service invocation by sending 1302 the bundle is a convergence-layer adapter implementation matter. 1303 Note that: 1305 . If the bundle contains a data label extension block (to be 1306 defined in a future document) then that data label value MAY 1307 identify procedures for determining the order in which 1308 convergence layer adapters must send bundles, e.g., considering 1309 bundle source when determining the order in which bundles are 1310 sent. The definition of such procedures is beyond the scope of 1311 this specification. 1312 . If the bundle has a bundle age block, as defined in 4.3.2. 1313 above, then at the last possible moment before the CLA 1314 initiates conveyance of the bundle via the CL protocol the 1315 bundle age value MUST be increased by the difference between 1316 the current time and the time at which the bundle was received 1317 (or, if the local node is the source of the bundle, created). 1319 Step 5: When all selected convergence layer adapters have informed 1320 the bundle protocol agent that they have concluded their data 1321 sending procedures with regard to this bundle, processing may depend 1322 on the results of those procedures. If completion of the data 1323 sending procedures by all selected convergence layer adapters has 1324 not resulted in successful forwarding of the bundle (an 1325 implementation-specific determination that is beyond the scope of 1326 this specification), then the bundle protocol agent MAY choose (in 1327 an implementation-specific manner, again beyond the scope of this 1328 specification) to initiate another attempt to forward the bundle. 1329 In that event, processing proceeds from Step 4 of Section 5.4. 1331 If completion of the data sending procedures by all selected 1332 convergence layer adapters HAS resulted in successful forwarding of 1333 the bundle, or if it has not but the bundle protocol agent does not 1334 choose to initiate another attempt to forward the bundle, then: 1336 . If the "request reporting of bundle forwarding" flag in the 1337 bundle's status report request field is set to 1, and status 1338 reporting is enabled, then a bundle forwarding status report 1339 SHOULD be generated, destined for the bundle's report-to 1340 endpoint ID. The reason code on this bundle forwarding status 1341 report MUST be "no additional information". 1342 . If any applicable bundle protocol extensions mandate generation 1343 of status reports upon conclusion of convergence-layer data 1344 sending procedures, all such status reports SHOULD be generated 1345 with extension-mandated reason codes. 1346 . The bundle's "Forward pending" retention constraint MUST be 1347 removed. 1349 5.4.1. Forwarding Contraindicated 1351 The steps in responding to contraindication of forwarding are: 1353 Step 1: The bundle protocol agent MUST determine whether or not to 1354 declare failure in forwarding the bundle. Note: this decision is 1355 likely to be influenced by the reason for which forwarding is 1356 contraindicated. 1358 Step 2: If forwarding failure is declared, then the Forwarding 1359 Failed procedure defined in Section 5.4.2 MUST be followed. 1361 Otherwise, when -- at some future time - the forwarding of this 1362 bundle ceases to be contraindicated, processing proceeds from Step 4 1363 of Section 5.4. 1365 5.4.2. Forwarding Failed 1367 The steps in responding to a declaration of forwarding failure are: 1369 Step 1: The bundle protocol agent MAY forward the bundle back to the 1370 node that sent it, as identified by the Previous Node block, if 1371 present. This forwarding, if performed, SHALL be accomplished by 1372 performing Step 4 and Step 5 of section 5.4 where the sole node 1373 selected for forwarding SHALL be the node that sent the bundle. 1375 Step 2: If the bundle's destination endpoint is an endpoint of which 1376 the node is a member, then the bundle's "Forward pending" retention 1377 constraint MUST be removed. Otherwise, the bundle MUST be deleted: 1378 the bundle deletion procedure defined in Section 5.10 MUST be 1379 followed, citing the reason for which forwarding was determined to 1380 be contraindicated. 1382 5.5. Bundle Expiration 1384 A bundle expires when the bundle's age exceeds its lifetime as 1385 specified in the primary bundle block. Bundle age MAY be determined 1386 by subtracting the bundle's creation timestamp time from the current 1387 time if (a) that timestamp time is not zero and (b) the local node's 1388 clock is known to be accurate; otherwise bundle age MUST be obtained 1389 from the Bundle Age extension block. Bundle expiration MAY occur at 1390 any point in the processing of a bundle. When a bundle expires, the 1391 bundle protocol agent MUST delete the bundle for the reason 1392 "lifetime expired": the bundle deletion procedure defined in Section 1393 5.10 MUST be followed. 1395 5.6. Bundle Reception 1397 The steps in processing a bundle that has been received from another 1398 node are: 1400 Step 1: The retention constraint "Dispatch pending" MUST be added to 1401 the bundle. 1403 Step 2: If the "request reporting of bundle reception" flag in the 1404 bundle's status report request field is set to 1, and status 1405 reporting is enabled, then a bundle reception status report with 1406 reason code "No additional information" SHOULD be generated, 1407 destined for the bundle's report-to endpoint ID. 1409 Step 3: CRCs SHOULD be computed for every block of the bundle that 1410 has an attached CRC. If any block of the bundle is malformed 1411 according to this specification, or if any block has an attached CRC 1412 and the CRC computed for this block upon reception differs from that 1413 attached CRC, then the bundle protocol agent MUST delete the bundle 1414 for the reason "Block unintelligible". The bundle deletion 1415 procedure defined in Section 5.10 MUST be followed and all remaining 1416 steps of the bundle reception procedure MUST be skipped. 1418 Step 4: For each block in the bundle that is an extension block that 1419 the bundle protocol agent cannot process: 1421 . If the block processing flags in that block indicate that a 1422 status report is requested in this event, and status reporting 1423 is enabled, then a bundle reception status report with reason 1424 code "Block unintelligible" SHOULD be generated, destined for 1425 the bundle's report-to endpoint ID. 1426 . If the block processing flags in that block indicate that the 1427 bundle must be deleted in this event, then the bundle protocol 1428 agent MUST delete the bundle for the reason "Block 1429 unintelligible"; the bundle deletion procedure defined in 1430 Section 5.10 MUST be followed and all remaining steps of the 1431 bundle reception procedure MUST be skipped. 1432 . If the block processing flags in that block do NOT indicate 1433 that the bundle must be deleted in this event but do indicate 1434 that the block must be discarded, then the bundle protocol 1435 agent MUST remove this block from the bundle. 1436 . If the block processing flags in that block indicate neither 1437 that the bundle must be deleted nor that that the block must be 1438 discarded, then processing continues with the next extension 1439 block that the bundle protocol agent cannot process, if any; 1440 otherwise, processing proceeds from step 5. 1442 Step 5: Processing proceeds from Step 1 of Section 5.3. 1444 5.7. Local Bundle Delivery 1446 The steps in processing a bundle that is destined for an endpoint of 1447 which this node is a member are: 1449 Step 1: If the received bundle is a fragment, the application data 1450 unit reassembly procedure described in Section 5.9 MUST be followed. 1451 If this procedure results in reassembly of the entire original 1452 application data unit, processing of this bundle (whose fragmentary 1453 payload has been replaced by the reassembled application data unit) 1454 proceeds from Step 2; otherwise, the retention constraint 1455 "Reassembly pending" MUST be added to the bundle and all remaining 1456 steps of this procedure MUST be skipped. 1458 Step 2: Delivery depends on the state of the registration whose 1459 endpoint ID matches that of the destination of the bundle: 1461 . An additional implementation-specific delivery deferral 1462 procedure MAY optionally be associated with the registration. 1463 . If the registration is in the Active state, then the bundle 1464 MUST be delivered automatically as soon as it is the next 1465 bundle that is due for delivery according to the BPA's bundle 1466 delivery scheduling policy, an implementation matter. 1467 . If the registration is in the Passive state, or if delivery of 1468 the bundle fails for some implementation-specific reason, then 1469 the registration's delivery failure action MUST be taken. 1470 Delivery failure action MUST be one of the following: 1472 o defer delivery of the bundle subject to this registration 1473 until (a) this bundle is the least recently received of 1474 all bundles currently deliverable subject to this 1475 registration and (b) either the registration is polled or 1476 else the registration is in the Active state, and also 1477 perform any additional delivery deferral procedure 1478 associated with the registration; or 1480 o abandon delivery of the bundle subject to this registration 1481 (as defined in 3.1. ). 1483 Step 3: As soon as the bundle has been delivered, if the "request 1484 reporting of bundle delivery" flag in the bundle's status report 1485 request field is set to 1 and bundle status reporting is enabled, 1486 then a bundle delivery status report SHOULD be generated, destined 1487 for the bundle's report-to endpoint ID. Note that this status report 1488 only states that the payload has been delivered to the application 1489 agent, not that the application agent has processed that payload. 1491 5.8. Bundle Fragmentation 1493 It may at times be advantageous for bundle protocol agents to reduce 1494 the sizes of bundles in order to forward them. This might be the 1495 case, for example, if a node to which a bundle is to be forwarded is 1496 accessible only via intermittent contacts and no upcoming contact is 1497 long enough to enable the forwarding of the entire bundle. 1499 The size of a bundle can be reduced by "fragmenting" the bundle. To 1500 fragment a bundle whose payload is of size M is to replace it with 1501 two "fragments" -- new bundles with the same source node ID and 1502 creation timestamp as the original bundle -- whose payloads are the 1503 first N and the last (M - N) bytes of the original bundle's payload, 1504 where 0 < N < M. Note that fragments may themselves be fragmented, 1505 so fragmentation may in effect replace the original bundle with more 1506 than two fragments. (However, there is only one 'level' of 1507 fragmentation, as in IP fragmentation.) 1509 Any bundle whose primary block's bundle processing flags do NOT 1510 indicate that it must not be fragmented MAY be fragmented at any 1511 time, for any purpose, at the discretion of the bundle protocol 1512 agent. NOTE, however, that some combinations of bundle 1513 fragmentation, replication, and routing might result in unexpected 1514 traffic patterns. 1516 Fragmentation SHALL be constrained as follows: 1518 . The concatenation of the payloads of all fragments produced by 1519 fragmentation MUST always be identical to the payload of the 1520 fragmented bundle (that is, the bundle that is being 1521 fragmented). Note that the payloads of fragments resulting from 1522 different fragmentation episodes, in different parts of the 1523 network, may be overlapping subsets of the fragmented bundle's 1524 payload. 1525 . The primary block of each fragment MUST differ from that of the 1526 fragmented bundle, in that the bundle processing flags of the 1527 fragment MUST indicate that the bundle is a fragment and both 1528 fragment offset and total application data unit length must be 1529 provided. Additionally, the CRC of the primary block of the 1530 fragmented bundle, if any, MUST be replaced in each fragment by 1531 a new CRC computed for the primary block of that fragment. 1532 . The payload blocks of fragments will differ from that of the 1533 fragmented bundle as noted above. 1534 . If the fragmented bundle is not a fragment or is the fragment 1535 with offset zero, then all extension blocks of the fragmented 1536 bundle MUST be replicated in the fragment whose offset is zero. 1537 . Each of the fragmented bundle's extension blocks whose "Block 1538 must be replicated in every fragment" flag is set to 1 MUST be 1539 replicated in every fragment. 1540 . Beyond these rules, replication of extension blocks in the 1541 fragments is an implementation matter. 1543 5.9. Application Data Unit Reassembly 1545 If the concatenation -- as informed by fragment offsets and payload 1546 lengths -- of the payloads of all previously received fragments with 1547 the same source node ID and creation timestamp as this fragment, 1548 together with the payload of this fragment, forms a byte array whose 1549 length is equal to the total application data unit length in the 1550 fragment's primary block, then: 1552 . This byte array -- the reassembled application data unit -- 1553 MUST replace the payload of this fragment. 1554 . The "Reassembly pending" retention constraint MUST be removed 1555 from every other fragment whose payload is a subset of the 1556 reassembled application data unit. 1558 Note: reassembly of application data units from fragments occurs at 1559 the nodes that are members of destination endpoints as necessary; an 1560 application data unit MAY also be reassembled at some other node on 1561 the path to the destination. 1563 5.10. Bundle Deletion 1565 The steps in deleting a bundle are: 1567 Step 1: If the "request reporting of bundle deletion" flag in the 1568 bundle's status report request field is set to 1, and if status 1569 reporting is enabled, then a bundle deletion status report citing 1570 the reason for deletion SHOULD be generated, destined for the 1571 bundle's report-to endpoint ID. 1573 Step 2: All of the bundle's retention constraints MUST be removed. 1575 5.11. Discarding a Bundle 1577 As soon as a bundle has no remaining retention constraints it MAY be 1578 discarded, thereby releasing any persistent storage that may have 1579 been allocated to it. 1581 5.12. Canceling a Transmission 1583 When requested to cancel a specified transmission, where the bundle 1584 created upon initiation of the indicated transmission has not yet 1585 been discarded, the bundle protocol agent MUST delete that bundle 1586 for the reason "transmission cancelled". For this purpose, the 1587 procedure defined in Section 5.10 MUST be followed. 1589 6. Administrative Record Processing 1591 6.1. Administrative Records 1593 Administrative records are standard application data units that are 1594 used in providing some of the features of the Bundle Protocol. One 1595 type of administrative record has been defined to date: bundle 1596 status reports. Note that additional types of administrative 1597 records may be defined by supplementary DTN protocol specification 1598 documents. 1600 Every administrative record consists of: 1602 . Record type code (an unsigned integer for which valid values 1603 are as defined below). 1604 . Record content in type-specific format. 1606 Valid administrative record type codes are defined as follows: 1608 +---------+--------------------------------------------+ 1610 | Value | Meaning | 1612 +=========+============================================+ 1614 | 1 | Bundle status report. | 1616 +---------+--------------------------------------------+ 1617 | (other) | Reserved for future use. | 1619 +---------+--------------------------------------------+ 1621 Figure 3: Administrative Record Type Codes 1623 Each BP administrative record SHALL be represented as a CBOR array 1624 comprising a 2-tuple. 1626 The first item of the array SHALL be a record type code, which SHALL 1627 be represented as a CBOR unsigned integer. 1629 The second element of this array SHALL be the applicable CBOR 1630 representation of the content of the record. Details of the CBOR 1631 representation of administrative record type 1 are provided below. 1632 Details of the CBOR representation of other types of administrative 1633 record type are included in the specifications defining those 1634 records. 1636 6.1.1. Bundle Status Reports 1638 The transmission of "bundle status reports" under specified 1639 conditions is an option that can be invoked when transmission of a 1640 bundle is requested. These reports are intended to provide 1641 information about how bundles are progressing through the system, 1642 including notices of receipt, forwarding, final delivery, and 1643 deletion. They are transmitted to the Report-to endpoints of 1644 bundles. 1646 Each bundle status report SHALL be represented as a CBOR array. The 1647 number of elements in the array SHALL be either 6 (if the subject 1648 bundle is a fragment) or 4 (otherwise). 1650 The first item of the bundle status report array SHALL be bundle 1651 status information represented as a CBOR array of at least 4 1652 elements. The first four items of the bundle status information 1653 array shall provide information on the following four status 1654 assertions, in this order: 1656 . Reporting node received bundle. 1657 . Reporting node forwarded the bundle. 1658 . Reporting node delivered the bundle. 1659 . Reporting node deleted the bundle. 1661 Each item of the bundle status information array SHALL be a bundle 1662 status item represented as a CBOR array; the number of elements in 1663 each such array SHALL be either 2 (if the value of the first item of 1664 this bundle status item is 1 AND the "Report status time" flag was 1665 set to 1 in the bundle processing flags of the bundle whose status 1666 is being reported) or 1 (otherwise). The first item of the bundle 1667 status item array SHALL be a status indicator, a Boolean value 1668 indicating whether or not the corresponding bundle status is 1669 asserted, represented as a CBOR Boolean value. The second item of 1670 the bundle status item array, if present, SHALL indicate the time 1671 (as reported by the local system clock, an implementation matter) at 1672 which the indicated status was asserted for this bundle, represented 1673 as a DTN time as described in Section 4.1.6. above. 1675 The second item of the bundle status report array SHALL be the 1676 bundle status report reason code explaining the value of the status 1677 indicator, represented as a CBOR unsigned integer. Valid status 1678 report reason codes are defined in Figure 4 below but the list of 1679 status report reason codes provided here is neither exhaustive nor 1680 exclusive; supplementary DTN protocol specifications (including, but 1681 not restricted to, the Bundle Security Protocol [BPSEC]) may define 1682 additional reason codes. 1684 +---------+--------------------------------------------+ 1686 | Value | Meaning | 1688 +=========+============================================+ 1690 | 0 | No additional information. | 1692 +---------+--------------------------------------------+ 1694 | 1 | Lifetime expired. | 1696 +---------+--------------------------------------------+ 1698 | 2 | Forwarded over unidirectional link. | 1700 +---------+--------------------------------------------+ 1702 | 3 | Transmission canceled. | 1704 +---------+--------------------------------------------+ 1706 | 4 | Depleted storage. | 1708 +---------+--------------------------------------------+ 1710 | 5 | Destination endpoint ID unintelligible. | 1711 +---------+--------------------------------------------+ 1713 | 6 | No known route to destination from here. | 1715 +---------+--------------------------------------------+ 1717 | 7 | No timely contact with next node on route. | 1719 +---------+--------------------------------------------+ 1721 | 8 | Block unintelligible. | 1723 +---------+--------------------------------------------+ 1725 | 9 | Hop limit exceeded. | 1727 +---------+--------------------------------------------+ 1729 | 10 | Traffic pared (e.g., status reports). | 1731 +---------+--------------------------------------------+ 1733 | (other) | Reserved for future use. | 1735 +---------+--------------------------------------------+ 1737 Figure 4: Status Report Reason Codes 1739 The third item of the bundle status report array SHALL be the source 1740 node ID identifying the source of the bundle whose status is being 1741 reported, represented as described in Section 4.1.5.2. above. 1743 The fourth item of the bundle status report array SHALL be the 1744 creation timestamp of the bundle whose status is being reported, 1745 represented as described in Section 4.1.7. above. 1747 The fifth item of the bundle status report array SHALL be present if 1748 and only if the bundle whose status is being reported contained a 1749 fragment offset. If present, it SHALL be the subject bundle's 1750 fragment offset represented as a CBOR unsigned integer item. 1752 The sixth item of the bundle status report array SHALL be present if 1753 and only if the bundle whose status is being reported contained a 1754 fragment offset. If present, it SHALL be the length of the subject 1755 bundle's payload represented as a CBOR unsigned integer item. 1757 Note that the forwarding parameters (such as lifetime, applicable 1758 security measures, etc.) of the bundle whose status is being 1759 reported MAY be reflected in the parameters governing the forwarding 1760 of the bundle that conveys a status report, but this is an 1761 implementation matter. Bundle protocol deployment experience to 1762 date has not been sufficient to suggest any clear guidance on this 1763 topic. 1765 6.2. Generation of Administrative Records 1767 Whenever the application agent's administrative element is directed 1768 by the bundle protocol agent to generate an administrative record 1769 with reference to some bundle, the following procedure must be 1770 followed: 1772 Step 1: The administrative record must be constructed. If the 1773 administrative record references a bundle and the referenced bundle 1774 is a fragment, the administrative record MUST contain the fragment 1775 offset and fragment length. 1777 Step 2: A request for transmission of a bundle whose payload is this 1778 administrative record MUST be presented to the bundle protocol 1779 agent. 1781 7. Services Required of the Convergence Layer 1783 7.1. The Convergence Layer 1785 The successful operation of the end-to-end bundle protocol depends 1786 on the operation of underlying protocols at what is termed the 1787 "convergence layer"; these protocols accomplish communication 1788 between nodes. A wide variety of protocols may serve this purpose, 1789 so long as each convergence layer protocol adapter provides a 1790 defined minimal set of services to the bundle protocol agent. This 1791 convergence layer service specification enumerates those services. 1793 7.2. Summary of Convergence Layer Services 1795 Each convergence layer protocol adapter is expected to provide the 1796 following services to the bundle protocol agent: 1798 . sending a bundle to a bundle node that is reachable via the 1799 convergence layer protocol; 1800 . notifying the bundle protocol agent when it has concluded its 1801 data sending procedures with regard to a bundle; 1802 . delivering to the bundle protocol agent a bundle that was sent 1803 by a bundle node via the convergence layer protocol. 1805 The convergence layer service interface specified here is neither 1806 exhaustive nor exclusive. That is, supplementary DTN protocol 1807 specifications (including, but not restricted to, the Bundle 1808 Security Protocol [BPSEC]) may expect convergence layer adapters 1809 that serve BP implementations conforming to those protocols to 1810 provide additional services such as reporting on the transmission 1811 and/or reception progress of individual bundles (at completion 1812 and/or incrementally), retransmitting data that were lost in 1813 transit, discarding bundle-conveying data units that the convergence 1814 layer protocol determines are corrupt or inauthentic, or reporting 1815 on the integrity and/or authenticity of delivered bundles. 1817 8. Implementation Status 1819 [NOTE to the RFC Editor: please remove this section before 1820 publication, as well as the reference to RFC 7942.] 1822 This section records the status of known implementations of the 1823 protocol defined by this specification at the time of posting of 1824 this Internet-Draft, and is based on a proposal described in RFC 1825 7942. The description of implementations in this section is 1826 intended to assist the IETF in its decision processes in progressing 1827 drafts to RFCs. Please note that the listing of any individual 1828 implementation here does not imply endorsement by the IETF. 1829 Furthermore, no effort has been spent to verify the information 1830 presented here that was supplied by IETF contributors. This is not 1831 intended as, and must not be construed to be, a catalog of available 1832 implementations or their features. Readers are advised to note that 1833 other implementations may exist. 1835 According to RFC 7942, "this will allow reviewers and working groups 1836 to assign due consideration to documents that have the benefit of 1837 running code, which may serve as evidence of valuable 1838 experimentation and feedback that have made the implemented 1839 protocols more mature. It is up to the individual working groups to 1840 use this information as they see fit". 1842 At the time of this writing, there are three known implementations 1843 of the current document. 1845 The first known implementation is microPCN (https://upcn.eu/). 1846 According to the developers: 1848 The Micro Planetary Communication Network (uPCN) is a free 1849 software project intended to offer an implementation of Delay- 1850 tolerant Networking protocols for POSIX operating systems (well, 1851 and for Linux) plus for the ARM Cortex STM32F4 microcontroller 1852 series. More precisely it currently provides an implementation of 1854 . the Bundle Protocol (BP, RFC 5050), 1855 . the Bundle Protocol version 7 specification draft (version 6), 1856 . the DTN IP Neighbor Discovery (IPND) protocol, and 1857 . a routing approach optimized for message-ferry micro LEO 1858 satellites. 1860 uPCN is written in C and is built upon the real-time operating 1861 system FreeRTOS. The source code of uPCN is released under the 1862 "BSD 3-Clause License". 1864 The project depends on an execution environment offering link 1865 layer protocols such as AX.25. The source code uses the USB 1866 subsystem to interact with the environment. 1868 The second known implementation is PyDTN, developed by X-works, 1869 s.r.o (https://x-works.sk/). The final third of the implementation 1870 was developed during the IETF 101 Hackathon. According to the 1871 developers, PyDTN implements bundle coding/decoding and neighbor 1872 discovery. PyDTN is written in Python and has been shown to be 1873 interoperable with uPCN. 1875 The third known implementation is "Terra" 1876 (https://github.com/RightMesh/Terra/), a Java implementation 1877 developed in the context of terrestrial DTN. It includes an 1878 implementation of a "minimal TCP" convergence layer adapter. 1880 9. Security Considerations 1882 The bundle protocol security architecture and the available security 1883 services are specified in an accompanying document, the Bundle 1884 Security Protocol specification [BPSEC]. 1886 The bpsec extensions to Bundle Protocol enable each block of a 1887 bundle (other than a bpsec extension block) to be individually 1888 authenticated by a signature block (Block Integrity Block, or BIB) 1889 and also enable each block of a bundle other than the primary block 1890 (and the bpsec extension blocks themselves) to be individually 1891 encrypted by a BCB. 1893 Because the security mechanisms are extension blocks that are 1894 themselves inserted into the bundle, the integrity and 1895 confidentiality of bundle blocks are protected while the bundle is 1896 at rest, awaiting transmission at the next forwarding opportunity, 1897 as well as in transit. 1899 Additionally, convergence-layer protocols that ensure authenticity 1900 of communication between adjacent nodes in BP network topology 1901 SHOULD be used where available, to minimize the ability of 1902 unauthenticated nodes to introduce inauthentic traffic into the 1903 network. Convergence-layer protocols that ensure confidentiality of 1904 communication between adjacent nodes in BP network topology SHOULD 1905 also be used where available, to minimize exposure of the bundle's 1906 primary block and other clear-text blocks, thereby offering some 1907 defense against traffic analysis. 1909 Note that, while the primary block must remain in the clear for 1910 routing purposes, the Bundle Protocol can be protected against 1911 traffic analysis to some extent by using bundle-in-bundle 1912 encapsulation to tunnel bundles to a safe forward distribution 1913 point: the encapsulated bundle forms the payload of an encapsulating 1914 bundle, and that payload block may be encrypted by a BCB. 1916 Note that the generation of bundle status reports is disabled by 1917 default because malicious initiation of bundle status reporting 1918 could result in the transmission of extremely large numbers of 1919 bundles, effecting a denial of service attack. 1921 The bpsec extensions accommodate an open-ended range of 1922 ciphersuites; different ciphersuites may be utilized to protect 1923 different blocks. One possible variation is to sign and/or encrypt 1924 blocks using symmetric keys securely formed by Diffie-Hellman 1925 procedures (such as EKDH) using the public and private keys of the 1926 sending and receiving nodes. For this purpose, the key distribution 1927 problem reduces to the problem of trustworthy delay-tolerant 1928 distribution of public keys, a current research topic. 1930 Bundle security MUST NOT be invalidated by forwarding nodes even 1931 though they themselves might not use the Bundle Security Protocol. 1933 In particular, while blocks MAY be added to bundles transiting 1934 intermediate nodes, removal of blocks with the "Discard block if it 1935 can't be processed" flag set in the block processing control flags 1936 may cause security to fail. 1938 Inclusion of the Bundle Security Protocol in any Bundle Protocol 1939 implementation is RECOMMENDED. Use of the Bundle Security Protocol 1940 in Bundle Protocol operations is OPTIONAL, subject to the following 1941 guidelines: 1943 . Every block (that is not a bpsec extension block) of every 1944 bundle SHOULD be authenticated by a BIB citing the ID of the 1945 node that inserted that block. (Note that a single BIB may 1946 authenticate multiple "target" blocks.) BIB authentication MAY 1947 be omitted on (and only on) any initial end-to-end path 1948 segments on which it would impose unacceptable overhead, 1949 provided that satisfactory authentication is ensured at the 1950 convergence layer and that BIB authentication is asserted on 1951 the first path segment on which the resulting overhead is 1952 acceptable and on all subsequent path segments. 1953 . If any segment of the end-to-end path of a bundle will traverse 1954 the Internet or any other potentially insecure communication 1955 environment, then the payload block SHOULD be encrypted by a 1956 BCB on this path segment and all subsequent segments of the 1957 end-to-end path. 1959 10. IANA Considerations 1961 The Bundle Protocol includes fields requiring registries managed by 1962 IANA. 1964 10.1. Bundle Block Types 1966 The current Bundle Block Types Registry is augmented by adding a 1967 column identifying the version of the Bundle protocol (Bundle 1968 Protocol Version) that applies to the new values, and by adding the 1969 following values, as described in section 4.3.1. The current values 1970 in the registry should have the Bundle Protocol Version set to the 1971 value "6", as shown below.IANA is requested to add values 2-9, as 1972 noted below, to the Bundle Block Type registry. In addition, the 1973 value "0" was not defined in that registry; as per consensus by the 1974 DTN working group, it is reserved per this document. 1976 +----------+-------+-----------------------------+---------------+ 1978 | Bundle | Value | Description | Reference | 1980 | Protocol | | | | 1982 | Version | | | | 1984 +----------+-------+-----------------------------+---------------+ 1986 | none | 0 | Reserved | [RFC6255] | 1988 | 6,7 | 1 | Bundle Payload Block | [RFC5050] | 1990 | 6 | 2 | Bundle Authentication Block | [RFC6257] | 1992 | 6 | 3 | Payload Integrity Block | [RFC6257] | 1993 | 6 | 4 | Payload Confidentiality Blk | [RFC6257] | 1995 | 6 | 5 | Previous-Hop Insertion Block| [RFC6259] | 1997 | 7 | 6 | Previous node (proximate | 4.3.1 | 1999 | | | sender) | | 2001 | 7 | 7 | Bundle age (in seconds) | 4.3.2 | 2003 | 6 | 8 | Metadata Extension Block | [RFC6258] | 2005 | 6 | 9 | Extension Security Block | [RFC6257] | 2007 | 7 | 10 | Hop count (#prior xmit | 4.3.3 | 2009 | | | attempts) | | 2011 | 7 | 11-15 | Reserved as noted earlier | 4.3 | 2013 | | 16-191| Unassigned | | 2015 | 6 |192-255| Reserved for Private and/or | [RFC5050] | 2017 | | | Experimental Use | | 2019 +----------+-------+-----------------------------+---------------+ 2021 10.2. Primary Bundle Protocol Version 2023 The current Primary Bundle Protocol Version Registry is augmented by 2024 adding the following value. 2026 the following values:IANA is requested to add value 7, as noted 2027 below, to the Primary Bundle Protocol Version registry. In 2028 addition, the values "0-5" were not defined in that registry; as per 2029 consensus by the DTN working group, they are reserved per this 2030 document. 2032 +-------+-------------+---------------+ 2034 | Value | Description | Reference | 2036 +-------+-------------+---------------+ 2038 | 7 | Assigned | 4.2.2 | 2039 +-------+-------------+---------------+ 2041 10.3. Bundle Processing Control Flags 2043 The current Bundle Processing Control Flags Registry is augmented by 2044 adding a column identifying the version of the Bundle protocol 2045 (Bundle Protocol Version) that applies to the new values, and by 2046 adding the following values, as described in section 4.1.3. The 2047 current values in the registry should have the Bundle Protocol 2048 Version set to the value 6 or "6, 7", as shown below.The Bundle 2049 Protocol has a Bundle Processing Control Flags field (Section 4.1.3) 2050 for which IANA is requested to create and maintain a new registry 2051 named "BPv7 Bundle Processing Control Flags". Initial values for 2052 this registry are given below. 2054 The registration policy for this registry is: Specification 2055 Required. The nominated expert(s) verify that a specification 2056 exists and is readily accessible. Specifications for new 2057 registrations need to describe in detail the manner in which bundle 2058 processing is affected by the new flag settings. Expert(s) are 2059 encouraged to be biased towards approving registrations unless they 2060 are abusive, frivolous, or actively harmful (not merely 2061 aesthetically displeasing, or architecturally dubious). 2063 The value range is: variable length. Maximum number of flag bit 2064 positions: 16. 2066 Bundle Processing Control Flags Registry 2068 +--------------------+----------------------------------+----------+ 2070 | Bundle | Bit | Description | Reference| 2072 | Protocol| Position | | | 2074 | Version | (right | | | 2076 | | to left) | | | 2078 +--------------------+----------------------------------+----------+ 2080 | 6,7 | 0 | Bundle is a fragment | [RFC5050]| 2082 | 6,7 | 1 | Application data unit is an | [RFC5050]| 2084 | | | administrative record | | 2085 | 6,7 | 2 | Bundle must not be fragmented | [RFC5050]| 2087 | 6 | 3 | Custody transfer is requested | [RFC5050]| 2089 | 6 | 4 | Destination endpoint is singleton| [RFC5050]| 2091 | 6,7 | 5 | Acknowledgement by application | [RFC5050]| 2093 | | | is requested | | 2095 | 7 | 6 | Status time requested in reports | 4.1.3 | 2097 | 6 | 7 | Class of service, priority | [RFC5050]| 2099 | 6 | 8 | Class of service, priority | [RFC5050]| 2101 | 6 | 9 | Class of service, reserved | [RFC5050]| 2103 | 6 | 10 | Class of service, reserved | [RFC5050]| 2105 | 6 | 11 | Class of service, reserved | [RFC5050]| 2107 | 6 | 12 | Class of service, reserved | [RFC5050]| 2109 | 6 | 13 | Class of service, reserved | [RFC5050]| 2111 | 6,7 | 14 | Request reporting of bundle | [RFC5050]| 2113 | | | reception | | 2115 | 6 | 15 | Request reporting of custody | [RFC5050]| 2117 | | | acceptance | | 2119 | 6,7 | 16 | Request reporting of bundle | [RFC5050]| 2121 | | | forwarding | | 2123 | 6,7 | 17 | Request reporting of bundle | [RFC5050]| 2125 | | | delivery | | 2127 | 6,7 | 18 | Request reporting of bundle | [RFC5050]| 2129 | | | deletion | | 2131 | 6 | 19 | Reserved | [RFC5050]| 2132 | 6 | 20 | Reserved | [RFC5050]| 2134 | | 21-63 | Unassigned | | 2136 +--------------------+----------------------------------+----------+ 2138 The registration policy is changed to "Expert Review". Given the 2139 maximum number of bits available, the allocation should only be 2140 approved with a well-defined specification and proof of real usage. 2142 10.4. Block Processing Control Flags 2144 The current Block Processing Control Flags Registry is augmented by 2145 adding a column identifying the version of the Bundle protocol 2146 (Bundle Protocol Version) that applies to the related BP version. 2147 The current values in the registry should have the Bundle Protocol 2148 Version set to the value 6 or "6, 7", as shown belowThe Bundle 2149 Protocol has a Block Processing Control Flags field (Section 4.1.4) 2150 for which IANA is requested to create and maintain a new registry 2151 named "BPv7 Block Processing Control Flags". Initial values for 2152 this registry are given below. 2154 The registration policy for this registry is: Specification 2155 Required. The nominated expert(s) verify that a specification 2156 exists and is readily accessible. Specifications for new 2157 registrations need to describe in detail the manner in which block 2158 processing is affected by the new flag settings. Expert(s) are 2159 encouraged to be biased towards approving registrations unless they 2160 are abusive, frivolous, or actively harmful (not merely 2161 aesthetically displeasing, or architecturally dubious). 2163 The value range is: variable length. Maximum number of flag bit 2164 positions: 8. 2166 Block Processing Control Flags Registry 2168 +--------------------+----------------------------------+----------+ 2170 | Bundle | Bit | Description | Reference| 2172 | Protocol| Position | | | 2174 | Version | (right | | | 2176 | | to left) | | | 2178 +--------------------+----------------------------------+----------+ 2179 | 6,7 | 0 | Block must be replicated in | [RFC5050]| 2181 | | | every fragment | | 2183 | 6,7 | 1 | Transmit status report if block | [RFC5050]| 2185 | | | can't be processed | | 2187 | 6,7 | 2 | Delete bundle if block can't be | [RFC5050]| 2189 | | | processed | | 2191 | 6 | 3 | Last block | [RFC5050]| 2193 | 6,7 | 4 | Discard block if it can't be | [RFC5050]| 2195 | | | processed | | 2197 | 6 | 5 | Block was forwarded without | [RFC5050]| 2199 | | | being processed | | 2201 | 6 | 6 | Block contains an EID reference | [RFC5050]| 2203 | | | field | | 2205 | | 7-63 | Unassigned | | 2207 +--------------------+----------------------------------+----------+ 2209 10.5. Bundle Status Report Reason Codes 2211 The current Bundle Status Report Reason Codes Registry is augmented 2212 by adding a column identifying the version of the Bundle protocol 2213 (Bundle Protocol Version) that applies to the new values, and by 2214 adding the following values, as described in section 6.1.1. The 2215 current values in the registry should have the Bundle Protocol 2216 Version set to the value 6 or 7 or "6, 7", as shown belowThe Bundle 2217 Protocol has a Bundle Status Report Reason Codes field (Section 2218 6.1.1) for which IANA is requested to create and maintain a new 2219 registry named "BPv7 Bundle Status Report Reason Codes". Initial 2220 values for this registry are given below. 2222 The registration policy for this registry is: Specification 2223 Required. The nominated expert(s) verify that a specification exists 2224 and is readily accessible. Specifications for new registrations need 2225 to describe in detail the conditions under which bundle processing 2226 may result in the transmission of status reports annotated with the 2227 new reason codes. Expert(s) are encouraged to be biased towards 2228 approving registrations unless they are abusive, frivolous, or 2229 actively harmful (not merely aesthetically displeasing, or 2230 architecturally dubious). 2232 The value range is: unsigned 8-bit integer. 2234 Bundle Status Report Reason Codes Registry 2236 +--------------------+----------------------------------+----------+ 2238 | Bundle | Value | Description | Reference| 2240 | Protocol| | | | 2242 | Version | | | | 2244 | | | | | 2246 +--------------------+----------------------------------+----------+ 2248 | 6,7 | 0 | No additional information | [RFC5050]| 2250 | 6,7 | 1 | Lifetime expired | [RFC5050]| 2252 | 6,7 | 2 | Forwarded over unidirectional | [RFC5050]| 2254 | | | link | | 2256 | 6,7 | 3 | Transmission canceled | [RFC5050]| 2258 | 6,7 | 4 | Depleted storage | [RFC5050]| 2260 | 6,7 | 5 | Destination endpoint ID | [RFC5050]| 2262 | | | unintelligible | | 2264 | 6,7 | 6 | No known route to destination | [RFC5050]| 2266 | | | from here | | 2268 | 6,7 | 7 | No timely contact with next node | [RFC5050]| 2270 | | | on route | | 2272 | 6,7 | 8 | Block unintelligible | [RFC6255]| 2273 | 7 | 9 | Hop limit exceeded | 6.1.1 | 2275 | 7 | 10 | Traffic pared | 6.1.1 | 2277 | | 11-254 | Unassigned | | 2279 | 6 | 255 | Reserved | [RFC6255]| 2281 +-------+-----------------------------------------------+----------+ 2283 10.6. Bundle Protocol URI scheme types 2285 The Bundle Protocol has a URI scheme type field - an unsigned 2286 integer of undefined length - for which IANA is requested to create 2287 and maintain a new registry named "Bundle Protocol URI Scheme Type 2288 RegistryURI scheme type codes". Initial values for the Bundle 2289 Protocol URI scheme type registry are given below. 2291 The registration policy for this registry is: Specification 2292 Required. The nominated expert(s) verify that a specification exists 2293 and is readily accessible. Specifications for new registrations need 2294 to reference the documents defining the URIs for which new scheme 2295 types are being registered. Expert(s) are encouraged to be biased 2296 towards approving registrations unless they are abusive, frivolous, 2297 or actively harmful (not merely aesthetically displeasing, or 2298 architecturally dubious). 2300 The value range is: unsigned 8-bit integer. 2302 Each assignment consists of a URI scheme type name and its 2303 associated description and reference. 2305 Bundle Protocol URI Scheme Type Registry 2307 +--------------+-----------------------------+-------------------+ 2309 | Value | Description | Reference | 2311 +--------------+-----------------------------+-------------------+ 2313 | 0 | Reserved | | 2315 | 1 | dtn | 10.7 | 2317 | 2 | ipn | RFC6260, Section 4| 2319 | 3-254 | Unassigned | | 2320 | 255 | reserved | | 2322 +--------------+-----------------------------+-------------------+ 2324 10.7. New URI scheme "dtn" 2326 IANA is requested to update the registration of theer a URI scheme 2327 with the string "dtn" as the scheme name, as follows: 2329 URI scheme name: "dtn" 2331 Status: permanent 2333 URI scheme syntax: 2335 This specification uses the Augmented Backus-Naur Form (ABNF) 2336 notation of [RFC5234]. 2338 dtn-uri = "dtn:" dtn-hier-part 2340 dtn-hier-part = "//" node-name name-delim demux ; a path-rootless 2342 node-name = 1*VCHAR 2344 name-delim = "/" 2346 demux = *VCHAR 2348 None of the reserved characters defined in the generic URI syntax 2349 are used as delimiters within URIs of the DTN scheme. 2351 URI scheme semantics: URIs of the DTN scheme are used as endpoint 2352 identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol 2353 (BP) as described in Section 4.1.5.1. 2355 Encoding considerations: URIs of the DTN scheme are encoded 2356 exclusively in US-ASCII characters. 2358 Applications and/or protocols that use this URI scheme name: the 2359 Delay-Tolerant Networking (DTN) Bundle Protocol (BP). 2361 Interoperability considerations: as noted above, URIs of the DTN 2362 scheme are encoded exclusively in US-ASCII characters. 2364 Security considerations: 2366 . Reliability and consistency: none of the BP endpoints 2367 identified by the URIs of the DTN scheme are guaranteed to be 2368 reachable at any time, and the identity of the processing 2369 entities operating on those endpoints is never guaranteed by 2370 the Bundle Protocol itself. Bundle authentication as defined by 2371 the Bundle Security Protocol is required for this purpose. 2372 . Malicious construction: malicious construction of a conformant 2373 DTN-scheme URI is limited to the malicious selection of node 2374 names and the malicious selection of demux strings. That is, a 2375 maliciously constructed DTN-scheme URI could be used to direct 2376 a bundle to an endpoint that might be damaged by the arrival of 2377 that bundle or, alternatively, to declare a false source for a 2378 bundle and thereby cause incorrect processing at a node that 2379 receives the bundle. In both cases (and indeed in all bundle 2380 processing), the node that receives a bundle should verify its 2381 authenticity and validity before operating on it in any way. 2382 . Back-end transcoding: the limited expressiveness of URIs of the 2383 DTN scheme effectively eliminates the possibility of threat due 2384 to errors in back-end transcoding. 2385 . Rare IP address formats: not relevant, as IP addresses do not 2386 appear anywhere in conformant DTN-scheme URIs. 2387 . Sensitive information: because DTN-scheme URIs are used only to 2388 represent the identities of Bundle Protocol endpoints, the risk 2389 of disclosure of sensitive information due to interception of 2390 these URIs is minimal. Examination of DTN-scheme URIs could be 2391 used to support traffic analysis; where traffic analysis is a 2392 plausible danger, bundles should be conveyed by secure 2393 convergence-layer protocols that do not expose endpoint IDs. 2394 . Semantic attacks: the simplicity of DTN-scheme URI syntax 2395 minimizes the possibility of misinterpretation of a URI by a 2396 human user. 2398 Contact: 2400 Scott Burleigh 2402 Jet Propulsion Laboratory, 2404 California Institute of Technology 2406 scott.c.burleigh@jpl.nasa.gov 2408 +1 (800) 393-3353 2410 Author/Change controller: 2412 Scott Burleigh 2413 Jet Propulsion Laboratory, 2415 California Institute of Technology 2417 scott.c.burleigh@jpl.nasa.gov 2419 10.8. Change status of URI scheme "ipn" 2421 IANA is requested to change to "permanent" the status of the URI 2422 scheme named "ipn". 2424 11. References 2426 11.1. Normative References 2428 [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work 2429 In Progress, October 2015. 2431 [CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4, 2432 International Telecommunications Union, October 1996. 2434 [CRC32C] Castagnoli, G., Brauer, S., and M. Herrmann, "Optimization 2435 of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE 2436 Transact. on Communications, Vol. 41, No. 6, June 1993. 2438 [EPOCH] Thompson, K. and D. M. Ritchie, "UNIX Programmer's Manual, 2439 Fifth Edition", Bell Telephone Laboratories Inc., June 1974. See 2440 https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man. 2441 pdf. 2443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2444 Requirement Levels", BCP 14, RFC 2119, March 1997. 2446 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2447 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2449 [RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object 2450 Representation (CBOR)", RFC 7049, October 2013. 2452 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2453 2119 Key Words", BCP 14, RFC 8174, May 2017. 2455 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2456 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 2457 January 2005. 2459 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2460 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 2461 2015. 2463 11.2. Informative References 2465 [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 2466 4838, April 2007. 2468 [BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", Work In 2469 Progress, June 2017. 2471 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 2472 Identifiers (IRIs)", RFC 3987, January 2005. 2474 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 2475 Specification", RFC 5050, November 2007. 2477 [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol 2478 IANA Registries", RFC 6255, May 2011. 2480 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 2481 "Bundle Security Protocol Specification", RFC 6257, May 2011. 2483 [RFC6258] Symington, S., " Delay-Tolerant Networking Metadata 2484 Extension Block", RFC 6258, May 2011. 2486 [RFC6259] Symington, S., " Delay-Tolerant Networking Previous-Hop 2487 Insertion Block", RFC 6259, May 2011. 2489 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, 2490 "Internet Small Computer System Interface (iSCSI) Protocol 2491 (Consolidated)", RFC 7143, April 2014. 2493 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 2494 Challenged Internets", SIGCOMM 2003. 2496 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 2497 historical background and perspectives" in "Journees systemes de 2498 reference spatio-temporels", 2004. 2500 12. Acknowledgments 2502 This work is freely adapted from RFC 5050, which was an effort of 2503 the Delay Tolerant Networking Research Group. The following DTNRG 2504 participants contributed significant technical material and/or 2505 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 2506 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 2507 Michael Demmer of the University of California at Berkeley, Robert 2508 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 2509 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 2510 College Dublin, Howard Weiss and Peter Lovell of SPARTA, Inc., and 2511 Manikantan Ramadas of Ohio University. 2513 This document was prepared using 2-Word-v2.0.template.dot. 2515 13. Significant Changes from RFC 5050 2517 Points on which this draft significantly differs from RFC 5050 2518 include the following: 2520 . Clarify the difference between transmission and forwarding. 2521 . Migrate custody transfer to the bundle-in-bundle encapsulation 2522 specification [BIBE]. 2523 . Introduce the concept of "node ID" as functionally distinct 2524 from endpoint ID, while having the same syntax. 2525 . Restructure primary block, making it immutable. Add optional 2526 CRC. 2527 . Add optional CRCs to non-primary blocks. 2528 . Add block ID number to canonical block format (to support 2529 BPSEC). 2530 . Add definition of bundle age extension block. 2531 . Add definition of previous node extension block. 2532 . Add definition of hop count extension block. 2533 . Remove Quality of Service markings. 2534 . Change from SDNVs to CBOR representation. 2536 Appendix A. For More Information 2538 Please refer comments to dtn@ietf.org. DTN Working Group documents 2539 are located at https://datatracker.ietf.org/wg/dtn/documents. The 2540 original Delay Tolerant Networking Research Group (DTNRG) Web site 2541 is located at https://irtf.org/concluded/dtnrg. 2543 Copyright (c) 2019 IETF Trust and the persons identified as authors 2544 of the code. All rights reserved. 2546 Redistribution and use in source and binary forms, with or without 2547 modification, is permitted pursuant to, and subject to the license 2548 terms contained in, the Simplified BSD License set forth in Section 2549 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2550 (http://trustee.ietf.org/license-info). 2552 Appendix B. CDDL expression 2554 For informational purposes, Carsten Bormann and Brian Sipos have 2555 kindly provided an expression of the Bundle Protocol specification 2556 in the Concise Data Definition Language (CDDL). That CDDL 2557 expression is presented below. Note that wherever the CDDL 2558 expression is in disagreement with the textual representation of the 2559 BP specification presented in the earlier sections of this document, 2560 the textual representation rules. 2562 start = bundle / #6.55799(bundle) 2564 ; Times before 2000 are invalid 2566 dtn-time = uint 2568 ; CRC enumerated type 2570 crc-type = &( 2572 crc-none: 0, 2574 crc-16bit: 1, 2576 crc-32bit: 2 2578 ) 2580 ; Either 16-bit or 32-bit 2582 crc-value = (bstr .size 2) / (bstr .size 4) 2584 creation-timestamp = [ 2586 dtn-time, ; absolute time of creation 2588 sequence: uint ; sequence within the time 2590 ] 2592 eid = $eid .within eid-structure 2594 eid-structure = [ 2596 uri-code: uint, 2597 SSP: any 2599 ] 2601 $eid /= [ 2603 uri-code: 1, 2605 SSP: (tstr / 0) 2607 ] 2609 $eid /= [ 2611 uri-code: 2, 2613 SSP: [ 2615 nodenum: uint, 2617 servicenum: uint 2619 ] 2621 ] 2623 ; The root bundle array 2625 bundle = [primary-block, *extension-block, payload-block] 2627 primary-block = [ 2629 version: 7, 2631 bundle-control-flags, 2633 crc-type, 2635 destination: eid, 2637 source-node: eid, 2639 report-to: eid, 2641 creation-timestamp, 2643 lifetime: uint, 2644 ? ( 2646 fragment-offset: uint, 2648 total-application-data-length: uint 2650 ), 2652 ? crc-value, 2654 ] 2656 bundle-control-flags = uint .bits bundleflagbits 2658 bundleflagbits = &( 2660 reserved: 2115, 2662 reserved: 2014, 2664 reserved: 193, 2666 bundle-deletion-status-reports-are-requested: 182, 2668 bundle-delivery-status-reports-are-requested: 171, 2670 bundle-forwarding-status-reports-are-requested: 160, 2672 reserved: 15, 2674 bundle-reception-status-reports-are-requested: 14, 2676 reserved: 13, 2678 reserved: 12, 2680 reserved: 11, 2682 reserved: 10, 2684 reserved: 9, 2686 bundle-reception-status-reports-are-requested: 8,reserved: 8, 2688 reserved: 7, 2690 bundle-contains-a-Manifest-block: 7, 2691 status-time-is-requested-in-all-status-reports: 6, 2693 user-application-acknowledgement-is-requested: 5, 2695 reserved: 4, 2697 reserved: 3, 2699 bundle-must-not-be-fragmented: 2, 2701 payload-is-an-administrative-record: 1, 2703 bundle-is-a-fragment: 0 2705 ) 2707 ; Abstract shared structure of all non-primary blocks 2709 canonical-block-structure = [ 2711 block-type-code: uint, 2713 block-number: uint, 2715 block-control-flags, 2717 crc-type, 2719 ; Each block type defines the content within the bytestring 2721 block-type-specific-data, 2723 ? crc-value 2725 ] 2727 block-control-flags = uint .bits blockflagbits 2729 blockflagbits = &( 2731 reserved: 7, 2733 reserved: 6, 2735 reserved: 5, 2737 block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4, 2738 reserved: 34, 2740 bundle-must-be-deleted-if-block-cannot-be-processed: 23, 2742 status-report-must-be-transmitted-if-block-cannot-be-processed: 2743 12, 2745 block-must-be-removed-from-bundle-if-it-cannot-be-processed: 1, 2747 block-must-be-replicated-in-every-fragment: 0 2749 ) 2751 block-type-specific-data = bstr / #6.24(bstr) 2753 ; Actual CBOR data embedded in a bytestring, with optional tag to 2754 indicate so 2756 embedded-cbor = (bstr .cbor Item) / #6.24(bstr .cbor Item) 2758 ; Extension block type, which does not specialize other than the 2759 code/number 2761 extension-block = $extension-block-structure .within canonical- 2762 block-structure 2764 ; Generic shared structure of all non-primary blocks 2766 extension-block-use = [ 2768 block-type-code: CodeValue, 2770 block-number: (uint .gt 1), 2772 block-control-flags, 2774 crc-type, 2776 BlockData, 2778 ? crc-value 2780 ] 2782 ; Payload block type 2783 payload-block = payload-block-structure .within canonical-block- 2784 structure 2786 payload-block-structure = [ 2788 block-type-code: 1, 2790 block-number: 1, 2792 block-control-flags, 2794 crc-type, 2796 $payload-block-data, 2798 ? crc-value 2800 ] 2802 ; Arbitrary payload data, including non-CBOR bytestring 2804 $payload-block-data /= block-type-specific-data 2806 ; Administrative record as a payload data specialization 2808 $payload-block-data /= embedded-cbor 2810 admin-record = $admin-record .within admin-record-structure 2812 admin-record-structure = [ 2814 record-type-code: uint, 2816 record-content: any 2818 ] 2820 ; Only one defined record type 2822 $admin-record /= [1, status-record-content] 2824 status-record-content = [ 2826 bundle-status-information, 2828 status-report-reason-code: uint, 2829 source-node-eid: eid, 2831 subject-creation-timestamp: creation-timestamp, 2833 ? ( 2835 subject-payload-offset: uint, 2837 subject-payload-length: uint 2839 ) 2841 ] 2843 bundle-status-information = [ 2845 reporting-node-received-bundle: status-info-content, 2847 reporting-node-forwarded-bundle: status-info-content, 2849 reporting-node-delivered-bundle: status-info-content, 2851 reporting-node-deleted-bundle: status-info-content 2853 ] 2855 status-info-content = [ 2857 status-indicator: bool, 2859 ? timestamp: dtn-time 2861 ] 2863 ; Previous Node extension block 2865 $extension-block-structure /= 2867 extension-block-use<7, embedded-cbor> 2869 ext-data-previous-node = eid 2871 ; Bundle Age extension block 2873 $extension-block-structure /= 2875 extension-block-use<8, embedded-cbor> 2877 ext-data-bundle-age = uint 2879 ; Hop Count extension block 2881 $extension-block-structure /= 2883 extension-block-use<9, embedded-cbor> 2885 ext-data-hop-count = [ 2887 hop-limit: uint, 2889 hop-count: uint 2891 ] 2893 Authors' Addresses 2895 Scott Burleigh 2896 Jet Propulsion Laboratory, California Institute of Technology 2897 4800 Oak Grove Dr. 2898 Pasadena, CA 91109-8099 2899 US 2900 Phone: +1 818 393 3353 2901 Email: Scott.C.Burleigh@jpl.nasa.gov 2903 Kevin Fall 2904 Roland Computing Services 2905 3871 Piedmont Ave. Suite 8 2906 Oakland, CA 94611 2907 US 2908 Email: kfall+rcs@kfall.com 2910 Edward J. Birrane 2911 Johns Hopkins University Applied Physics Laboratory 2912 11100 Johns Hopkins Rd 2913 Laurel, MD 20723 2914 US 2915 Phone: +1 443 778 7423 2916 Email: Edward.Birrane@jhuapl.edu