idnits 2.17.1 draft-ietf-dtn-bpbis-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 30, 2018) is 2157 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. 'CRC' ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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: December 2018 Nefeli Networks, Inc. 5 E. Birrane 6 APL, Johns Hopkins University 7 May 30, 2018 9 Bundle Protocol Version 7 10 draft-ietf-dtn-bpbis-11.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 December 1, 2018. 35 Copyright Notice 37 Copyright (c) 2018 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............................................5 62 3.1. Definitions...............................................5 63 3.2. Discussion of BP concepts.................................9 64 3.3. Services Offered by Bundle Protocol Agents...............12 65 4. Bundle Format.................................................12 66 4.1. BP Fundamental Data Structures...........................13 67 4.1.1. CRC Type............................................13 68 4.1.2. CRC.................................................13 69 4.1.3. Bundle Processing Control Flags.....................13 70 4.1.4. Block Processing Control Flags......................14 71 4.1.5. Identifiers.........................................15 72 4.1.5.1. Endpoint ID....................................15 73 4.1.5.2. Node ID........................................16 74 4.1.6. DTN Time............................................17 75 4.1.7. Creation Timestamp..................................17 76 4.1.8. Block-type-specific Data............................17 77 4.2. Bundle Representation....................................17 78 4.2.1. Bundle..............................................18 79 4.2.2. Primary Bundle Block................................18 80 4.2.3. Canonical Bundle Block Format.......................20 81 4.3. Extension Blocks.........................................21 82 4.3.1. Previous Node.......................................21 83 4.3.2. Bundle Age..........................................22 84 4.3.3. Hop Count...........................................22 85 5. Bundle Processing.............................................23 86 5.1. Generation of Administrative Records.....................23 87 5.2. Bundle Transmission......................................24 88 5.3. Bundle Dispatching.......................................24 89 5.4. Bundle Forwarding........................................24 90 5.4.1. Forwarding Contraindicated..........................26 91 5.4.2. Forwarding Failed...................................26 92 5.5. Bundle Expiration........................................27 93 5.6. Bundle Reception.........................................27 94 5.7. Local Bundle Delivery....................................28 95 5.8. Bundle Fragmentation.....................................29 96 5.9. Application Data Unit Reassembly.........................30 97 5.10. Bundle Deletion.........................................30 98 5.11. Discarding a Bundle.....................................31 99 5.12. Canceling a Transmission................................31 100 6. Administrative Record Processing..............................31 101 6.1. Administrative Records...................................31 102 6.1.1. Bundle Status Reports...............................32 103 6.2. Generation of Administrative Records.....................34 104 7. Services Required of the Convergence Layer....................35 105 7.1. The Convergence Layer....................................35 106 7.2. Summary of Convergence Layer Services....................35 107 8. Implementation Status.........................................35 108 9. Security Considerations.......................................37 109 10. IANA Considerations..........................................38 110 11. References...................................................39 111 11.1. Normative References....................................39 112 11.2. Informative References..................................40 113 12. Acknowledgments..............................................40 114 13. Significant Changes from RFC 5050............................41 115 Appendix A. For More Information.................................42 116 Appendix B. CDDL expression......................................43 118 1. Introduction 120 Since the publication of the Bundle Protocol Specification 121 (Experimental RFC 5050) in 2007, the Delay-Tolerant Networking (DTN) 122 Bundle Protocol has been implemented in multiple programming 123 languages and deployed to a wide variety of computing platforms. 124 This implementation and deployment experience has identified 125 opportunities for making the protocol simpler, more capable, and 126 easier to use. The present document, standardizing the Bundle 127 Protocol (BP), is adapted from RFC 5050 in that context. 129 This document describes version 7 of BP. 131 Delay Tolerant Networking is a network architecture providing 132 communications in and/or through highly stressed environments. 133 Stressed networking environments include those with intermittent 134 connectivity, large and/or variable delays, and high bit error 135 rates. To provide its services, BP may be viewed as sitting at the 136 application layer of some number of constituent networks, forming a 137 store-carry-forward overlay network. Key capabilities of BP 138 include: 140 . Ability to use physical motility for the movement of data 141 . Ability to move the responsibility for error control from one 142 node to another 143 . Ability to cope with intermittent connectivity, including cases 144 where the sender and receiver are not concurrently present in 145 the network 146 . Ability to take advantage of scheduled, predicted, and 147 opportunistic connectivity, whether bidirectional or 148 unidirectional, in addition to continuous connectivity 149 . Late binding of overlay network endpoint identifiers to 150 underlying constituent network addresses 152 For descriptions of these capabilities and the rationale for the DTN 153 architecture, see [ARCH] and [SIGC]. 155 BP's location within the standard protocol stack is as shown in 156 Figure 1. BP uses underlying "native" transport and/or network 157 protocols for communications within a given constituent network. 159 The interface between the bundle protocol and a specific underlying 160 protocol is termed a "convergence layer adapter". 162 Figure 1 shows three distinct transport and network protocols 163 (denoted T1/N1, T2/N2, and T3/N3). 165 +-----------+ +-----------+ 166 | BP app | | BP app | 167 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 168 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 169 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 170 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 171 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 172 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 173 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 174 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 175 +-----------+ +-------------+ +-------------+ +-----------+ 176 | | | | 177 |<---- A network ---->| |<---- A network ---->| 178 | | | | 180 Figure 1: The Bundle Protocol in the Protocol Stack Model 182 This document describes the format of the protocol data units 183 (called "bundles") passed between entities participating in BP 184 communications. 186 The entities are referred to as "bundle nodes". This document does 187 not address: 189 . Operations in the convergence layer adapters that bundle nodes 190 use to transport data through specific types of internets. 191 (However, the document does discuss the services that must be 192 provided by each adapter at the convergence layer.) 193 . The bundle route computation algorithm. 194 . Mechanisms for populating the routing or forwarding information 195 bases of bundle nodes. 196 . The mechanisms for securing bundles en route. 197 . The mechanisms for managing bundle nodes. 199 Note that implementations of the specification presented in this 200 document will not be interoperable with implementations of RFC 5050. 202 2. Conventions used in this document 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in RFC-2119 [RFC2119]. 208 In this document, these words will appear with that interpretation 209 only when in ALL CAPS. Lower case uses of these words are not to be 210 interpreted as carrying RFC-2119 significance. 212 3. Service Description 214 3.1. Definitions 216 Bundle - A bundle is a protocol data unit of BP, so named because 217 negotiation of the parameters of a data exchange may be impractical 218 in a delay-tolerant network: it is often better practice to "bundle" 219 with a unit of data all metadata that might be needed in order to 220 make the data immediately usable when delivered to applications. 221 Each bundle comprises a sequence of two or more "blocks" of protocol 222 data, which serve various purposes. 224 Block - A bundle protocol block is one of the protocol data 225 structures that together constitute a well-formed bundle. 227 Bundle payload - A bundle payload (or simply "payload") is the 228 application data whose conveyance to the bundle's destination is the 229 purpose for the transmission of a given bundle; it is the content of 230 the bundle's payload block. The terms "bundle content", "bundle 231 payload", and "payload" are used interchangeably in this document. 233 Partial payload - A partial payload is a payload that comprises 234 either the first N bytes or the last N bytes of some other payload 235 of length M, such that 0 < N < M. Note that every partial payload 236 is a payload and therefore can be further subdivided into partial 237 payloads. 239 Fragment - A fragment is a bundle whose payload block contains a 240 partial payload. 242 Bundle node - A bundle node (or, in the context of this document, 243 simply a "node") is any entity that can send and/or receive bundles. 244 Each bundle node has three conceptual components, defined below, as 245 shown in Figure 2: a "bundle protocol agent", a set of zero or more 246 "convergence layer adapters", and an "application agent". 248 +-----------------------------------------------------------+ 249 |Node | 250 | | 251 | +-------------------------------------------------------+ | 252 | |Application Agent | | 253 | | | | 254 | | +--------------------------+ +----------------------+ | | 255 | | |Administrative element | |Application-specific | | | 256 | | | | |element | | | 257 | | | | | | | | 258 | | +--------------------------+ +----------------------+ | | 259 | | ^ ^ | | 260 | | Admin|records Application|data | | 261 | | | | | | 262 | +----------------v--------------------------v-----------+ | 263 | ^ | 264 | | ADUs | 265 | | | 266 | +-----------------------------v-------------------------+ | 267 | |Bundle Protocol Agent | | 268 | | | | 269 | | | | 270 | +-------------------------------------------------------+ | 271 | ^ ^ ^ | 272 | | Bundles | Bundles Bundles | | 273 | | | | | 274 | +------v-----+ +-----v------+ +-----v-----+ | 275 | |CLA 1 | |CLA 2 | |CLA n | | 276 | | | | | . . . | | | 277 | | | | | | | | 278 +-+------------+-----+------------+-----------+-----------+-+ 279 ^ ^ ^ 281 CL1|PDUs CL2|PDUs CLn|PDUs 282 | | | 283 +------v-----+ +-----v------+ +-----v-----+ 284 Network 1 Network 2 Network n 286 Figure 2: Components of a BP Node 288 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 289 the node component that offers the BP services and executes the 290 procedures of the bundle protocol. 292 Convergence layer adapter - A convergence layer adapter (CLA) is a 293 node component that sends and receives bundles on behalf of the BPA, 294 utilizing the services of some 'native' protocol stack that is 295 supported in one of the networks within which the node is 296 functionally located. 298 Application agent - The application agent (AA) of a node is the node 299 component that utilizes the BP services to effect communication for 300 some user purpose. The application agent in turn has two elements, 301 an administrative element and an application-specific element. 303 Application-specific element - The application-specific element of 304 an AA is the node component that constructs, requests transmission 305 of, accepts delivery of, and processes units of user application 306 data. 308 Administrative element - The administrative element of an AA is the 309 node component that constructs and requests transmission of 310 administrative records (defined below), including status reports, 311 and accepts delivery of and processes any administrative records 312 that the node receives. 314 Administrative record - A BP administrative record is an application 315 data unit that is exchanged between the administrative elements of 316 nodes' application agents for some BP administrative purpose. The 317 only administrative record defined in this specification is the 318 status report, discussed later. 320 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 321 of zero or more bundle nodes that all identify themselves for BP 322 purposes by some common identifier, called a "bundle endpoint ID" 323 (or, in this document, simply "endpoint ID"; endpoint IDs are 324 described in detail in Section 4.4.1 below). 326 Singleton endpoint - A singleton endpoint is an endpoint that always 327 contains exactly one member. 329 Registration - A registration is the state machine characterizing a 330 given node's membership in a given endpoint. Any single 331 registration has an associated delivery failure action as defined 332 below and must at any time be in one of two states: Active or 333 Passive. 335 Delivery - A bundle is considered to have been delivered at a node 336 subject to a registration as soon as the application data unit that 337 is the payload of the bundle, together with any relevant metadata 338 (an implementation matter), has been presented to the node's 339 application agent in a manner consistent with the state of that 340 registration. 342 Deliverability - A bundle is considered "deliverable" subject to a 343 registration if and only if (a) the bundle's destination endpoint is 344 the endpoint with which the registration is associated, (b) the 345 bundle has not yet been delivered subject to this registration, and 346 (c) the bundle has not yet been "abandoned" (as defined below) 347 subject to this registration. 349 Abandonment - To abandon a bundle subject to some registration is to 350 assert that the bundle is not deliverable subject to that 351 registration. 353 Delivery failure action - The delivery failure action of a 354 registration is the action that is to be taken when a bundle that is 355 "deliverable" subject to that registration is received at a time 356 when the registration is in the Passive state. 358 Destination - The destination of a bundle is the endpoint comprising 359 the node(s) at which the bundle is to be delivered (as defined 360 below). 362 Transmission - A transmission is an attempt by a node's BPA to cause 363 copies of a bundle to be delivered to one or more of the nodes that 364 are members of some endpoint (the bundle's destination) in response 365 to a transmission request issued by the node's application agent. 367 Forwarding - To forward a bundle to a node is to invoke the services 368 of one or more CLAs in a sustained effort to cause a copy of the 369 bundle to be received by that node. 371 Discarding - To discard a bundle is to cease all operations on the 372 bundle and functionally erase all references to it. The specific 373 procedures by which this is accomplished are an implementation 374 matter. 376 Retention constraint - A retention constraint is an element of the 377 state of a bundle that prevents the bundle from being discarded. 378 That is, a bundle cannot be discarded while it has any retention 379 constraints. 381 Deletion - To delete a bundle is to remove unconditionally all of 382 the bundle's retention constraints, enabling the bundle to be 383 discarded. 385 3.2. Discussion of BP concepts 387 Multiple instances of the same bundle (the same unit of DTN protocol 388 data) might exist concurrently in different parts of a network -- 389 possibly differing in some blocks -- in the memory local to one or 390 more bundle nodes and/or in transit between nodes. In the context of 391 the operation of a bundle node, a bundle is an instance (copy), in 392 that node's local memory, of some bundle that is in the network. 394 The payload for a bundle forwarded in response to a bundle 395 transmission request is the application data unit whose location is 396 provided as a parameter to that request. The payload for a bundle 397 forwarded in response to reception of a bundle is the payload of the 398 received bundle. 400 In the most familiar case, a bundle node is instantiated as a single 401 process running on a general-purpose computer, but in general the 402 definition is meant to be broader: a bundle node might alternatively 403 be a thread, an object in an object-oriented operating system, a 404 special-purpose hardware device, etc. 406 The manner in which the functions of the BPA are performed is wholly 407 an implementation matter. For example, BPA functionality might be 408 coded into each node individually; it might be implemented as a 409 shared library that is used in common by any number of bundle nodes 410 on a single computer; it might be implemented as a daemon whose 411 services are invoked via inter-process or network communication by 412 any number of bundle nodes on one or more computers; it might be 413 implemented in hardware. 415 Every CLA implements its own thin layer of protocol, interposed 416 between BP and the (usually "top") protocol(s) of the underlying 417 native protocol stack; this "CL protocol" may only serve to 418 multiplex and de-multiplex bundles to and from the underlying native 419 protocol, or it may offer additional CL-specific functionality. The 420 manner in which a CLA sends and receives bundles, as well as the 421 definitions of CLAs and CL protocols, are beyond the scope of this 422 specification. 424 Note that the administrative element of a node's application agent 425 may itself, in some cases, function as a convergence-layer adapter. 426 That is, outgoing bundles may be "tunneled" through encapsulating 427 bundles: 429 . An outgoing bundle constitutes a byte array. This byte array 430 may, like any other, be presented to the bundle protocol agent 431 as an application data unit that is to be transmitted to some 432 endpoint. 433 . The original bundle thus forms the payload of an encapsulating 434 bundle that is forwarded using some other convergence-layer 435 protocol(s). 436 . When the encapsulating bundle is received, its payload is 437 delivered to the peer application agent administrative element, 438 which then instructs the bundle protocol agent to dispatch that 439 original bundle in the usual way. 441 The purposes for which this technique may be useful (such as cross- 442 domain security) are beyond the scope of this specification. 444 The only interface between the BPA and the application-specific 445 element of the AA is the BP service interface. But between the BPA 446 and the administrative element of the AA there is a (conceptual) 447 private control interface in addition to the BP service interface. 448 This private control interface enables the BPA and the 449 administrative element of the AA to direct each other to take action 450 under specific circumstances. 452 In the case of a node that serves simply as a BP "router", the AA 453 may have no application-specific element at all. The application- 454 specific elements of other nodes' AAs may perform arbitrarily 455 complex application functions, perhaps even offering multiplexed DTN 456 communication services to a number of other applications. As with 457 the BPA, the manner in which the AA performs its functions is wholly 458 an implementation matter. 460 Singletons are the most familiar sort of endpoint, but in general 461 the endpoint notion is meant to be broader. For example, the nodes 462 in a sensor network might constitute a set of bundle nodes that 463 identify themselves by a single common endpoint ID and thus form a 464 single bundle endpoint. *Note* too that a given bundle node might 465 identify itself by multiple endpoint IDs and thus be a member of 466 multiple bundle endpoints. 468 The destination of every bundle is an endpoint, which may or may not 469 be singleton. The source of every bundle is a node, identified by 470 the endpoint ID for some singleton endpoint that contains that node. 472 Note, though, that the source node ID asserted in a given bundle may 473 be the null endpoint ID (as described later) rather than the 474 endpoint ID of the actual source node; bundles for which the 475 asserted source node ID is the null endpoint ID are termed 476 "anonymous" bundles. 478 Any number of transmissions may be concurrently undertaken by the 479 bundle protocol agent of a given node. 481 When the bundle protocol agent of a node determines that a bundle 482 must be forwarded to a node (either to a node that is a member of 483 the bundle's destination endpoint or to some intermediate forwarding 484 node) in the course of completing the successful transmission of 485 that bundle, it invokes the services of one or more CLAs in a 486 sustained effort to cause a copy of the bundle to be received by 487 that node. 489 Upon reception, the processing of a bundle that has been received by 490 a given node depends on whether or not the receiving node is 491 registered in the bundle's destination endpoint. If it is, and if 492 the payload of the bundle is non-fragmentary (possibly as a result 493 of successful payload reassembly from fragmentary payloads, 494 including the original payload of the newly received bundle), then 495 the bundle is normally delivered to the node's application agent 496 subject to the registration characterizing the node's membership in 497 the destination endpoint. 499 The bundle protocol does not natively ensure delivery of a bundle to 500 its destination. Data loss along the path to the destination node 501 can be minimized by utilizing reliable convergence-layer protocols 502 between neighbors on all segments of the end-to-end path, but for 503 end-to-end bundle delivery assurance it will be necessary to develop 504 extensions to the bundle protocol and/or application-layer 505 mechanisms. 507 The bundle protocol is designed for extensibility. Bundle protocol 508 extensions, documented elsewhere, may extend this specification by: 510 . defining additional blocks; 511 . defining additional administrative records; 512 . defining additional bundle processing flags; 513 . defining additional block processing flags; 514 . defining additional types of bundle status reports; 515 . defining additional bundle status report reason codes; 516 . defining additional mandates and constraints on processing 517 that conformant bundle protocol agents must perform at 518 specified points in the inbound and outbound bundle processing 519 cycles. 521 3.3. Services Offered by Bundle Protocol Agents 523 The BPA of each node is expected to provide the following services 524 to the node's application agent: 526 . commencing a registration (registering the node in an 527 endpoint); 528 . terminating a registration; 529 . switching a registration between Active and Passive states; 530 . transmitting a bundle to an identified bundle endpoint; 531 . canceling a transmission; 532 . polling a registration that is in the Passive state; 533 . delivering a received bundle. 535 4. Bundle Format 537 The format of bundles SHALL conform to the Concise Binary Object 538 Representation (CBOR [RFC7049]). 540 Each bundle SHALL be a concatenated sequence of at least two blocks, 541 represented as a CBOR indefinite-length array. The first block in 542 the sequence (the first item of the array) MUST be a primary bundle 543 block in CBOR representation as described below; the bundle MUST 544 have exactly one primary bundle block. The primary block MUST be 545 followed by one or more canonical bundle blocks (additional array 546 items) in CBOR representation as described below. The last such 547 block MUST be a payload block; the bundle MUST have exactly one 548 payload block. The last item of the array, immediately following 549 the payload block, SHALL be a CBOR "break" stop code. 551 (Note that, while CBOR permits considerable flexibility in the 552 encoding of bundles, this flexibility must not be interpreted as 553 inviting increased complexity in protocol data unit structure.) 555 An implementation of the Bundle Protocol MAY discard any sequence of 556 bytes that does not conform to the Bundle Protocol specification. 558 An implementation of the Bundle Protocol MAY accept a sequence of 559 bytes that does not conform to the Bundle Protocol specification 560 (e.g., one that represents data elements in fixed-length arrays 561 rather than indefinite-length arrays) and transform it into 562 conformant BP structure before processing it. Procedures for 563 accomplishing such a transformation are beyond the scope of this 564 specification. 566 4.1. BP Fundamental Data Structures 568 4.1.1. CRC Type 570 CRC type is an unsigned integer type code for which the following 571 values (and no others) are valid: 573 . 0 indicates "no CRC is present." 574 . 1 indicates "a standard X-25 CRC-16 is present." [CRC] 575 . 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present." 576 [CRC] 578 CRC type SHALL be represented as a CBOR unsigned integer. 580 4.1.2. CRC 582 CRC SHALL be omitted from a block if and only if the block's CRC 583 type code is zero. 585 When not omitted, the CRC SHALL be represented as sequence of two 586 bytes (if CRC type is 1) or as a sequence of four bytes (if CRC type 587 is 2); in each case the sequence of bytes SHALL constitute an 588 unsigned integer value (of 16 or 32 bits, respectively) in network 589 byte order. 591 4.1.3. Bundle Processing Control Flags 593 Bundle processing control flags assert properties of the bundle as a 594 whole rather than of any particular block of the bundle. They are 595 conveyed in the primary block of the bundle. 597 The following properties are asserted by the bundle processing 598 control flags: 600 . The bundle is a fragment. (Boolean) 602 . The bundle's payload is an administrative record. (Boolean) 604 . The bundle must not be fragmented. (Boolean) 606 . Acknowledgment by the user application is requested. (Boolean) 608 . Status time is requested in all status reports. (Boolean) 610 . The bundle contains a "manifest" extension block. (Boolean) 612 . Flags requesting types of status reports (all Boolean): 614 o Request reporting of bundle reception. 616 o Request reporting of bundle forwarding. 618 o Request reporting of bundle delivery. 620 o Request reporting of bundle deletion. 622 If the bundle processing control flags indicate that the bundle's 623 application data unit is an administrative record, then all status 624 report request flag values must be zero. 626 If the bundle's source node is omitted (i.e., the source node ID is 627 the ID of the null endpoint, which has no members as discussed 628 below; this option enables anonymous bundle transmission), then the 629 bundle is not uniquely identifiable and all bundle protocol features 630 that rely on bundle identity must therefore be disabled: the "Bundle 631 must not be fragmented" flag value must be 1 and all status report 632 request flag values must be zero. 634 The bundle processing control flags SHALL be represented as a CBOR 635 unsigned integer item containing a bit field of 16 bits indicating 636 the control flag values as follows: 638 . Bit 0 (the high-order bit, 0x8000): reserved. 639 . Bit 1 (0x4000): reserved. 640 . Bit 2 (0x2000): reserved. 641 . Bit 3(0x1000): bundle deletion status reports are requested. 642 . Bit 4(0x0800): bundle delivery status reports are requested. 643 . Bit 5(0x0400): bundle forwarding status reports are requested. 644 . Bit 6(0x0200): reserved. 645 . Bit 7(0x0100): bundle reception status reports are requested. 646 . Bit 8(0x0080): bundle contains a Manifest block. 647 . Bit 9(0x0040): status time is requested in all status reports. 648 . Bit 10(0x0020): user application acknowledgement is requested. 649 . Bit 11(0x0010): reserved. 650 . Bit 12(0x0008): reserved. 651 . Bit 13(0x0004): bundle must not be fragmented. 652 . Bit 14(0x0002): payload is an administrative record. 653 . Bit 15 (the low-order bit, 0x0001: bundle is a fragment. 655 4.1.4. Block Processing Control Flags 657 The block processing control flags assert properties of canonical 658 bundle blocks. They are conveyed in the header of the block to 659 which they pertain. 661 The following properties are asserted by the block processing 662 control flags: 664 . This block must be replicated in every fragment. (Boolean) 666 . Transmission of a status report is requested if this block 667 can't be processed. (Boolean) 669 . Block must be removed from the bundle if it can't be processed. 670 (Boolean) 672 . Bundle must be deleted if this block can't be processed. 673 (Boolean) 675 For each bundle whose bundle processing control flags indicate that 676 the bundle's application data unit is an administrative record, or 677 whose source node ID is the null endpoint ID as defined below, the 678 value of the "Transmit status report if block can't be processed" 679 flag in every canonical block of the bundle must be zero. 681 The block processing control flags SHALL be represented as a CBOR 682 unsigned integer item containing a bit field of 8 bits indicating 683 the control flag values as follows: 685 . Bit 0 (the high-order bit, 0x80): reserved. 686 . Bit 1 (0x40): reserved. 687 . Bit 2(0x20): reserved. 688 . Bit 3(0x10): reserved. 689 . Bit 4(0x08): bundle must be deleted if block can't be 690 processed. 691 . Bit 5(0x04): transmission of a status report is requested if 692 block can't be processed. 693 . Bit 6(0x02): block must be removed from bundle if it can't be 694 processed. 695 . Bit 7(the low-order bit, 0x01): block must be replicated in 696 every fragment. 698 4.1.5. Identifiers 700 4.1.5.1. Endpoint ID 702 The destinations of bundles are bundle endpoints, identified by text 703 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 704 (EID) is a Uniform Resource Identifier (URI; [URI]). As such, each 705 endpoint ID can be characterized as having this general structure: 707 < scheme name > : < scheme-specific part, or "SSP" > 708 The scheme identified by the < scheme name > in an endpoint ID is a 709 set of syntactic and semantic rules that fully explain how to parse 710 and interpret the SSP. The set of allowable schemes is effectively 711 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 712 protocol endpoint ID. 714 Note that, although endpoint IDs are URIs, implementations of the BP 715 service interface may support expression of endpoint IDs in some 716 internationalized manner (e.g., Internationalized Resource 717 Identifiers (IRIs); see [RFC3987]). 719 The endpoint ID "dtn:none" identifies the "null endpoint", the 720 endpoint that by definition never has any members. 722 Each BP endpoint ID (EID) SHALL be represented as a CBOR array 723 comprising a 2-tuple. 725 The first item of the array SHALL be the code number identifying the 726 endpoint's URI scheme [URI], as defined in the registry of URI 727 scheme code numbers for Bundle Protocol maintained by IANA as 728 described in Section 10. [URIREG]. Each URI scheme code number 729 SHALL be represented as a CBOR unsigned integer. 731 The second item of the array SHALL be the applicable CBOR 732 representation of the scheme-specific part (SSP) of the EID, defined 733 as follows: 735 . If the EID's URI scheme is "dtn" then the SSP SHALL be 736 represented as a CBOR text string unless the EID's SSP is 737 "none", in which case the SSP SHALL be represented as a CBOR 738 unsigned integer with the value zero. 739 . If the EID's URI scheme is "ipn" then the SSP SHALL be 740 represented as a CBOR array comprising a 2-tuple. The first 741 item of this array SHALL be the EID's node number represented 742 as a CBOR unsigned integer. The second item of this array 743 SHALL be the EID's service number represented as a CBOR 744 unsigned integer. 745 . Definitions of the CBOR representations of the SSPs of EIDs 746 encoded in other URI schemes are included in the specifications 747 defining those schemes. 749 4.1.5.2. Node ID 751 For many purposes of the Bundle Protocol it is important to identify 752 the node that is operative in some context. 754 As discussed in 3.1 above, nodes are distinct from endpoints; 755 specifically, an endpoint is a set of zero or more nodes. But 756 rather than define a separate namespace for node identifiers, we 757 instead use endpoint identifiers to identify nodes, subject to the 758 following restrictions: 760 . Every node MUST be a member of at least one singleton endpoint. 761 . The EID of any singleton endpoint of which a node is a member 762 MAY be used to identify that node. A "node ID" is an EID that 763 is used in this way. 764 . A node's membership in a given singleton endpoint MUST be 765 sustained at least until the nominal operation of the Bundle 766 Protocol no longer depends on the identification of that node 767 using that endpoint's ID. 769 4.1.6. DTN Time 771 A DTN time is an unsigned integer indicating an interval of Unix 772 epoch time that has elapsed since the start of the year 2000 on the 773 Coordinated Universal Time (UTC) scale [UTC], which is Unix epoch 774 timestamp 946684800. (Note that the DTN time that equates to the 775 current time as reported by the POSIX time() function can be derived 776 by subtracting 946684800 from that reported time value.) Each DTN 777 time SHALL be represented as a CBOR unsigned integer item. 779 4.1.7. Creation Timestamp 781 Each creation timestamp SHALL be represented as a CBOR array item 782 comprising a 2-tuple. 784 The first item of the array SHALL be a DTN time. 786 The second item of the array SHALL be the creation timestamp's 787 sequence number, represented as a CBOR unsigned integer. 789 4.1.8. Block-type-specific Data 791 Block-type-specific data in each block (other than the primary 792 block) SHALL be the applicable CBOR representation of the content of 793 the block. Details of this representation are included in the 794 specification defining the block type. 796 4.2. Bundle Representation 798 This section describes the primary block in detail and non-primary 799 blocks in general. Rules for processing these blocks appear in 800 Section 5 of this document. 802 Note that supplementary DTN protocol specifications (including, but 803 not restricted to, the Bundle Security Protocol [BPSEC]) may require 804 that BP implementations conforming to those protocols construct and 805 process additional blocks. 807 4.2.1. Bundle 809 Each bundle SHALL be represented as a CBOR indefinite-length array. 810 The first item of this array SHALL be the CBOR representation of a 811 Primary Block. Every other item of the array except the last SHALL 812 be the CBOR representation of a Canonical Block. The last item of 813 the array SHALL be a CBOR "break" stop code. 815 4.2.2. Primary Bundle Block 817 The primary bundle block contains the basic information needed to 818 forward bundles to their destinations. 820 Each primary block SHALL be represented as a CBOR array; the number 821 of elements in the array SHALL be 8 (if the bundle is not a fragment 822 and CRC type is zero) or 9 (if the bundle is not a fragment and CRC 823 type is non-zero) or 10 (if the bundle is a fragment and CRC type is 824 zero) or 11 (if the bundle is a fragment and CRC-type is non-zero). 826 The fields of the primary bundle block SHALL be as follows, listed 827 in the order in which they MUST appear: 829 Version: An unsigned integer value indicating the version of the 830 bundle protocol that constructed this block. The present document 831 describes version 7 of the bundle protocol. Version number SHALL be 832 represented as a CBOR unsigned integer item. 834 Bundle Processing Control Flags: The Bundle Processing Control Flags 835 are discussed in Section 4.1.3. above. 837 CRC Type: CRC Type codes are discussed in Section 4.1.1. above. 839 Destination EID: The Destination EID field identifies the bundle 840 endpoint that is the bundle's destination, i.e., the endpoint that 841 contains the node(s) at which the bundle is to be delivered. 843 Source node ID: The Source node ID field identifies the bundle node 844 at which the bundle was initially transmitted, except that Source 845 node ID may be the null endpoint ID in the event that the bundle's 846 source chooses to remain anonymous. 848 Report-to EID: The Report-to EID field identifies the bundle 849 endpoint to which status reports pertaining to the forwarding and 850 delivery of this bundle are to be transmitted. 852 Creation Timestamp: The creation timestamp is a pair of unsigned 853 integers that, together with the source node ID and (if the bundle 854 is a fragment) the fragment offset and payload length, serve to 855 identify the bundle. The first of these integers is the bundle's 856 creation time, while the second is the bundle's creation timestamp 857 sequence number. Bundle creation time shall be the DTN time at which 858 the transmission request was received that resulted in the creation 859 of the bundle. Sequence count shall be the latest value (as of the 860 time at which that transmission request was received) of a 861 monotonically increasing positive integer counter managed by the 862 source node's bundle protocol agent that may be reset to zero 863 whenever the current time advances by one second. For nodes that 864 lack accurate clocks, it is recommended that bundle creation time be 865 set to zero and that the counter used as the source of the bundle 866 sequence count never be reset to zero. Note that, in general, the 867 creation of two distinct bundles with the same source node ID and 868 bundle creation timestamp may result in unexpected network behavior 869 and/or suboptimal performance. The combination of source node ID and 870 bundle creation timestamp serves to identify a single transmission 871 request, enabling it to be acknowledged by the receiving application 872 (provided the source node ID is not the null endpoint ID). 874 Lifetime: The lifetime field is an unsigned integer that indicates 875 the time at which the bundle's payload will no longer be useful, 876 encoded as a number of microseconds past the creation time. (For 877 high-rate deployments with very brief disruptions, fine-grained 878 expression of bundle lifetime may be useful.) When a bundle's age 879 exceeds its lifetime, bundle nodes need no longer retain or forward 880 the bundle; the bundle SHOULD be deleted from the network. Bundle 881 lifetime SHALL be represented as a CBOR unsigned integer item. 883 Fragment offset: If and only if the Bundle Processing Control Flags 884 of this Primary block indicate that the bundle is a fragment, 885 fragment offset SHALL be present in the primary block. Fragment 886 offset SHALL be represented as a CBOR unsigned integer indicating 887 the offset from the start of the original application data unit at 888 which the bytes comprising the payload of this bundle were located. 890 CRC: If and only if the value of the CRC type field of this Primary 891 block is non-zero, a CRC SHALL be present in the primary block. The 892 length and nature of the CRC SHALL be as indicated by the CRC type. 893 The CRC SHALL be computed over the concatenation of all bytes 894 (including CBOR "break" characters) of the primary block including 895 the CRC field itself, which for this purpose SHALL be temporarily 896 populated with the value zero. 898 4.2.3. Canonical Bundle Block Format 900 Every block other than the primary block (all such blocks are termed 901 "canonical" blocks) SHALL be represented as a CBOR array; the number 902 of elements in the array SHALL be 6 (if CRC type is zero) or 7 903 (otherwise). 905 The fields of every canonical block SHALL be as follows, listed in 906 the order in which they MUST appear: 908 . Block type code, an unsigned integer. Bundle block type code 1 909 indicates that the block is a bundle payload block. Block type 910 codes 2 through 9 are explicitly reserved as noted later in 911 this specification. Block type codes 192 through 255 are not 912 reserved and are available for private and/or experimental use. 913 All other block type code values are reserved for future use. 914 . Block number, an unsigned integer. The block number uniquely 915 identifies the block within the bundle, enabling blocks 916 (notably bundle security protocol blocks) to explicitly 917 reference other blocks in the same bundle. Block numbers need 918 not be in continuous sequence, and blocks need not appear in 919 block number sequence in the bundle. The block number of the 920 payload block is always zero. 921 . Block processing control flags as discussed in Section 4.1.4 922 above. 923 . CRC type as discussed in Section 4.1.1 above. 924 . Block-type-specific data fields, whose nature and order are 925 type-specific, all of which SHALL appear in CBOR 926 representation. For the Payload Block in particular (block 927 type 1), there SHALL be exactly one block-type-specific data 928 field, termed the "payload", which SHALL be an application data 929 unit, or some contiguous extent thereof, represented as a CBOR 930 byte string. 931 . If and only if the value of the CRC type field of this block is 932 non-zero, a CRC. If present, the length and nature of the CRC 933 SHALL be as indicated by the CRC type and the CRC SHALL be 934 computed over the concatenation of all bytes of the block 935 (including CBOR "break" characters) including the CRC field 936 itself, which for this purpose SHALL be temporarily populated 937 with the value zero. 939 4.3. Extension Blocks 941 "Extension blocks" are all blocks other than the primary and payload 942 blocks. Because not all extension blocks are defined in the Bundle 943 Protocol specification (the present document), not all nodes 944 conforming to this specification will necessarily instantiate Bundle 945 Protocol implementations that include procedures for processing 946 (that is, recognizing, parsing, acting on, and/or producing) all 947 extension blocks. It is therefore possible for a node to receive a 948 bundle that includes extension blocks that the node cannot process. 949 The values of the block processing control flags indicate the action 950 to be taken by the bundle protocol agent when this is the case. 952 The following extension blocks are defined in other DTN protocol 953 specification documents as noted: 955 . Block Integrity Block (block type 2) and Block Confidentiality 956 Block (block type 3) are defined in the Bundle Security 957 Protocol specification (work in progress). 958 . Manifest Block (block type 4) is defined in the Manifest 959 Extension Block specification (work in progress). The manifest 960 block identifies the blocks that were present in the bundle at 961 the time it was created. The bundle MUST contain one (1) 962 occurrence of this type of block if the value of the "manifest" 963 flag in the bundle processing control flags is 1; otherwise the 964 bundle MUST NOT contain any Manifest block. 965 . The Flow Label Block (block type 6) is defined in the Flow 966 Label Extension Block specification (work in progress). The 967 flow label block is intended to govern transmission of the 968 bundle by convergence-layer adapters. 970 The following extension blocks are defined in the current document. 972 4.3.1. Previous Node 974 The Previous Node block, block type 7, identifies the node that 975 forwarded this bundle to the local node (i.e., to the node at which 976 the bundle currently resides); its block-type-specific data is the 977 node ID of that forwarder node which SHALL take the form of a node 978 ID represented as described in Section 4.1.5.2. above. If the local 979 node is the source of the bundle, then the bundle MUST NOT contain 980 any previous node block. Otherwise the bundle SHOULD contain one 981 (1) occurrence of this type of block. 983 4.3.2. Bundle Age 985 The Bundle Age block, block type 8, contains the number of 986 microseconds that have elapsed between the time the bundle was 987 created and time at which it was most recently forwarded. It is 988 intended for use by nodes lacking access to an accurate clock, to 989 aid in determining the time at which a bundle's lifetime expires. 990 The block-type-specific data of this block is an unsigned integer 991 containing the age of the bundle in microseconds, which SHALL be 992 represented as a CBOR unsigned integer item. (The age of the bundle 993 is the sum of all known intervals of the bundle's residence at 994 forwarding nodes, up to the time at which the bundle was most 995 recently forwarded, plus the summation of signal propagation time 996 over all episodes of transmission between forwarding nodes. 997 Determination of these values is an implementation matter.) If the 998 bundle's creation time is zero, then the bundle MUST contain exactly 999 one (1) occurrence of this type of block; otherwise, the bundle MAY 1000 contain at most one (1) occurrence of this type of block. A bundle 1001 MUST NOT contain multiple occurrences of the bundle age block, as 1002 this could result in processing anomalies. 1004 4.3.3. Hop Count 1006 The Hop Count block, block type 9, contains two unsigned integers, 1007 hop limit and hop count. A "hop" is here defined as an occasion on 1008 which a bundle was forwarded from one node to another node. The hop 1009 limit value SHOULD NOT be changed at any time after creation of the 1010 Hop Count block; the hop count value SHOULD initially be zero and 1011 SHOULD be increased by 1 on each hop. 1013 The hop count block is mainly intended as a safety mechanism, a 1014 means of identifying bundles for removal from the network that can 1015 never be delivered due to a persistent forwarding error. When a 1016 bundle's hop count exceeds its hop limit, the bundle SHOULD be 1017 deleted for the reason "hop limit exceeded", following the bundle 1018 deletion procedure defined in Section 5.10. . Procedures for 1019 determining the appropriate hop limit for a block are beyond the 1020 scope of this specification. The block-type-specific data in a hop 1021 count block SHALL be represented as a CBOR array comprising a 2- 1022 tuple. The first item of this array SHALL be the bundle's hop 1023 limit, represented as a CBOR unsigned integer. The second item of 1024 this array SHALL be the bundle's hop count, represented as a CBOR 1025 unsigned integer. A bundle MAY contain at most one (1) occurrence of 1026 this type of block. 1028 5. Bundle Processing 1030 The bundle processing procedures mandated in this section and in 1031 Section 6 govern the operation of the Bundle Protocol Agent and the 1032 Application Agent administrative element of each bundle node. They 1033 are neither exhaustive nor exclusive. Supplementary DTN protocol 1034 specifications (including, but not restricted to, the Bundle 1035 Security Protocol [BPSEC]) may augment, override, or supersede the 1036 mandates of this document. 1038 5.1. Generation of Administrative Records 1040 All transmission of bundles is in response to bundle transmission 1041 requests presented by nodes' application agents. When required to 1042 "generate" an administrative record (such as a bundle status 1043 report), the bundle protocol agent itself is responsible for causing 1044 a new bundle to be transmitted, conveying that record. In concept, 1045 the bundle protocol agent discharges this responsibility by 1046 directing the administrative element of the node's application agent 1047 to construct the record and request its transmission as detailed in 1048 Section 6 below. In practice, the manner in which administrative 1049 record generation is accomplished is an implementation matter, 1050 provided the constraints noted in Section 6 are observed. 1052 Under some circumstances, the requesting of status reports could 1053 result in an unacceptable increase in the bundle traffic in the 1054 network. For this reason, the generation of status reports MUST be 1055 disabled by default and enabled only when the risk of excessive 1056 network traffic is deemed acceptable. 1058 When the generation of status reports is enabled, the decision on 1059 whether or not to generate a requested status report is left to the 1060 discretion of the bundle protocol agent. Mechanisms that could 1061 assist in making such decisions, such as pre-placed agreements 1062 authorizing the generation of status reports under specified 1063 circumstances, are beyond the scope of this specification. 1065 Notes on administrative record terminology: 1067 . A "bundle reception status report" is a bundle status report 1068 with the "reporting node received bundle" flag set to 1. 1069 . A "bundle forwarding status report" is a bundle status report 1070 with the "reporting node forwarded the bundle" flag set to 1. 1071 . A "bundle delivery status report" is a bundle status report 1072 with the "reporting node delivered the bundle" flag set to 1. 1073 . A "bundle deletion status report" is a bundle status report 1074 with the "reporting node deleted the bundle" flag set to 1. 1076 5.2. Bundle Transmission 1078 The steps in processing a bundle transmission request are: 1080 Step 1: Transmission of the bundle is initiated. An outbound bundle 1081 MUST be created per the parameters of the bundle transmission 1082 request, with the retention constraint "Dispatch pending". The 1083 source node ID of the bundle MUST be either the null endpoint ID, 1084 indicating that the source of the bundle is anonymous, or else the 1085 EID of a singleton endpoint whose only member is the node of which 1086 the BPA is a component. 1088 Step 2: Processing proceeds from Step 1 of Section 5.4. 1090 5.3. Bundle Dispatching 1092 The steps in dispatching a bundle are: 1094 Step 1: If the bundle's destination endpoint is an endpoint of which 1095 the node is a member, the bundle delivery procedure defined in 1096 Section 5.7 MUST be followed and for the purposes of all subsequent 1097 processing of this bundle at this node the node's membership in the 1098 bundle's destination endpoint SHALL be disavowed. 1100 Step 2: Processing proceeds from Step 1 of Section 5.4. 1102 5.4. Bundle Forwarding 1104 The steps in forwarding a bundle are: 1106 Step 1: The retention constraint "Forward pending" MUST be added to 1107 the bundle, and the bundle's "Dispatch pending" retention constraint 1108 MUST be removed. 1110 Step 2: The bundle protocol agent MUST determine whether or not 1111 forwarding is contraindicated for any of the reasons listed in 1112 Figure 4. In particular: 1114 . The bundle protocol agent MAY choose either to forward the 1115 bundle directly to its destination node(s) (if possible) or to 1116 forward the bundle to some other node(s) for further 1117 forwarding. The manner in which this decision is made may 1118 depend on the scheme name in the destination endpoint ID and/or 1119 on other state but in any case is beyond the scope of this 1120 document. If the BPA elects to forward the bundle to some other 1121 node(s) for further forwarding but finds it impossible to 1122 select any node(s) to forward the bundle to, then forwarding is 1123 contraindicated. 1124 . Provided the bundle protocol agent succeeded in selecting the 1125 node(s) to forward the bundle to, the bundle protocol agent 1126 MUST select the convergence layer adapter(s) whose services 1127 will enable the node to send the bundle to those nodes. The 1128 manner in which specific appropriate convergence layer adapters 1129 are selected is beyond the scope of this document. If the agent 1130 finds it impossible to select any appropriate convergence layer 1131 adapter(s) to use in forwarding this bundle, then forwarding is 1132 contraindicated. 1134 Step 3: If forwarding of the bundle is determined to be 1135 contraindicated for any of the reasons listed in Figure 4, then the 1136 Forwarding Contraindicated procedure defined in Section 5.4.1 MUST 1137 be followed; the remaining steps of Section 5 are skipped at this 1138 time. 1140 Step 4: For each node selected for forwarding, the bundle protocol 1141 agent MUST invoke the services of the selected convergence layer 1142 adapter(s) in order to effect the sending of the bundle to that 1143 node. Determining the time at which the bundle protocol agent 1144 invokes convergence layer adapter services is a BPA implementation 1145 matter. Determining the time at which each convergence layer 1146 adapter subsequently responds to this service invocation by sending 1147 the bundle is a convergence-layer adapter implementation matter. 1148 Note that: 1150 . If the bundle contains a flow label extension block (to be 1151 defined in a future document) then that flow label value MAY 1152 identify procedures for determining the order in which 1153 convergence layer adapters must send bundles, e.g., considering 1154 bundle source when determining the order in which bundles are 1155 sent. The definition of such procedures is beyond the scope of 1156 this specification. 1157 . If the bundle has a bundle age block, as defined in 4.3.2. 1158 above, then at the last possible moment before the CLA 1159 initiates conveyance of the bundle node via the CL protocol the 1160 bundle age value MUST be increased by the difference between 1161 the current time and the time at which the bundle was received 1162 (or, if the local node is the source of the bundle, created). 1164 Step 5: When all selected convergence layer adapters have informed 1165 the bundle protocol agent that they have concluded their data 1166 sending procedures with regard to this bundle: 1168 . If the "request reporting of bundle forwarding" flag in the 1169 bundle's status report request field is set to 1, and status 1170 reporting is enabled, then a bundle forwarding status report 1171 SHOULD be generated, destined for the bundle's report-to 1172 endpoint ID. The reason code on this bundle forwarding status 1173 report MUST be "no additional information". 1174 . If any applicable bundle protocol extensions mandate generation 1175 of status reports upon conclusion of convergence-layer data 1176 sending procedures, all such status reports SHOULD be generated 1177 with extension-mandated reason codes. 1178 . The bundle's "Forward pending" retention constraint MUST be 1179 removed. 1181 5.4.1. Forwarding Contraindicated 1183 The steps in responding to contraindication of forwarding are: 1185 Step 1: The bundle protocol agent MUST determine whether or not to 1186 declare failure in forwarding the bundle. Note: this decision is 1187 likely to be influenced by the reason for which forwarding is 1188 contraindicated. 1190 Step 2: If forwarding failure is declared, then the Forwarding 1191 Failed procedure defined in Section 5.4.2 MUST be followed. 1193 Otherwise, when -- at some future time - the forwarding of this 1194 bundle ceases to be contraindicated, processing proceeds from Step 4 1195 of Section 5.4. 1197 5.4.2. Forwarding Failed 1199 The steps in responding to a declaration of forwarding failure are: 1201 Step 1: The bundle protocol agent MAY forward the bundle back to the 1202 node that sent it, as identified by the Previous Node block, if 1203 present. This forwarding, if performed, SHALL be accomplished by 1204 performing Step 4 and Step 5 of section 5.4 where the sole node 1205 selected for forwarding SHALL be the node that sent the bundle. 1207 Step 2: If the bundle's destination endpoint is an endpoint of which 1208 the node is a member, then the bundle's "Forward pending" retention 1209 constraint MUST be removed. Otherwise, the bundle MUST be deleted: 1210 the bundle deletion procedure defined in Section 5.10 MUST be 1211 followed, citing the reason for which forwarding was determined to 1212 be contraindicated. 1214 5.5. Bundle Expiration 1216 A bundle expires when the bundle's age exceeds its lifetime as 1217 specified in the primary bundle block. Bundle age MAY be determined 1218 by subtracting the bundle's creation timestamp time from the current 1219 time if (a) that timestamp time is not zero and (b) the local node's 1220 clock is known to be accurate; otherwise bundle age MUST be obtained 1221 from the Bundle Age extension block. Bundle expiration MAY occur at 1222 any point in the processing of a bundle. When a bundle expires, the 1223 bundle protocol agent MUST delete the bundle for the reason 1224 "lifetime expired": the bundle deletion procedure defined in Section 1225 5.10 MUST be followed. 1227 5.6. Bundle Reception 1229 The steps in processing a bundle that has been received from another 1230 node are: 1232 Step 1: The retention constraint "Dispatch pending" MUST be added to 1233 the bundle. 1235 Step 2: If the "request reporting of bundle reception" flag in the 1236 bundle's status report request field is set to 1, and status 1237 reporting is enabled, then a bundle reception status report with 1238 reason code "No additional information" SHOULD be generated, 1239 destined for the bundle's report-to endpoint ID. 1241 Step 3: For each block in the bundle that is an extension block that 1242 the bundle protocol agent cannot process: 1244 . If the block processing flags in that block indicate that a 1245 status report is requested in this event, and status reporting 1246 is enabled, then a bundle reception status report with reason 1247 code "Block unintelligible" SHOULD be generated, destined for 1248 the bundle's report-to endpoint ID. 1249 . If the block processing flags in that block indicate that the 1250 bundle must be deleted in this event, then the bundle protocol 1251 agent MUST delete the bundle for the reason "Block 1252 unintelligible"; the bundle deletion procedure defined in 1253 Section 5.10 MUST be followed and all remaining steps of the 1254 bundle reception procedure MUST be skipped. 1255 . If the block processing flags in that block do NOT indicate 1256 that the bundle must be deleted in this event but do indicate 1257 that the block must be discarded, then the bundle protocol 1258 agent MUST remove this block from the bundle. 1259 . If the block processing flags in that block indicate neither 1260 that the bundle must be deleted nor that that the block must be 1261 discarded, then processing continues with the next extension 1262 block that the bundle protocol agent cannot process, if any; 1263 otherwise, processing proceeds from step 4. 1265 Step 4: Processing proceeds from Step 1 of Section 5.3. 1267 5.7. Local Bundle Delivery 1269 The steps in processing a bundle that is destined for an endpoint of 1270 which this node is a member are: 1272 Step 1: If the received bundle is a fragment, the application data 1273 unit reassembly procedure described in Section 5.9 MUST be followed. 1274 If this procedure results in reassembly of the entire original 1275 application data unit, processing of this bundle (whose fragmentary 1276 payload has been replaced by the reassembled application data unit) 1277 proceeds from Step 2; otherwise, the retention constraint 1278 "Reassembly pending" MUST be added to the bundle and all remaining 1279 steps of this procedure MUST be skipped. 1281 Step 2: Delivery depends on the state of the registration whose 1282 endpoint ID matches that of the destination of the bundle: 1284 . An additional implementation-specific delivery deferral 1285 procedure MAY optionally be associated with the registration. 1286 . If the registration is in the Active state, then the bundle 1287 MUST be delivered automatically as soon as it is the next 1288 bundle that is due for delivery according to the BPA's bundle 1289 delivery scheduling policy, an implementation matter. 1290 . If the registration is in the Passive state, or if delivery of 1291 the bundle fails for some implementation-specific reason, then 1292 the registration's delivery failure action MUST be taken. 1293 Delivery failure action MUST be one of the following: 1295 o defer delivery of the bundle subject to this registration 1296 until (a) this bundle is the least recently received of 1297 all bundles currently deliverable subject to this 1298 registration and (b) either the registration is polled or 1299 else the registration is in the Active state, and also 1300 perform any additional delivery deferral procedure 1301 associated with the registration; or 1303 o abandon delivery of the bundle subject to this registration 1304 (as defined in 3.1. ). 1306 Step 3: As soon as the bundle has been delivered, if the "request 1307 reporting of bundle delivery" flag in the bundle's status report 1308 request field is set to 1 and bundle status reporting is enabled, 1309 then a bundle delivery status report SHOULD be generated, destined 1310 for the bundle's report-to endpoint ID. Note that this status report 1311 only states that the payload has been delivered to the application 1312 agent, not that the application agent has processed that payload. 1314 5.8. Bundle Fragmentation 1316 It may at times be advantageous for bundle protocol agents to reduce 1317 the sizes of bundles in order to forward them. This might be the 1318 case, for example, if a node to which a bundle is to be forwarded is 1319 accessible only via intermittent contacts and no upcoming contact is 1320 long enough to enable the forwarding of the entire bundle. 1322 The size of a bundle can be reduced by "fragmenting" the bundle. To 1323 fragment a bundle whose payload is of size M is to replace it with 1324 two "fragments" -- new bundles with the same source node ID and 1325 creation timestamp as the original bundle -- whose payloads are the 1326 first N and the last (M - N) bytes of the original bundle's payload, 1327 where 0 < N < M. Note that fragments may themselves be fragmented, 1328 so fragmentation may in effect replace the original bundle with more 1329 than two fragments. (However, there is only one 'level' of 1330 fragmentation, as in IP fragmentation.) 1332 Any bundle whose primary block's bundle processing flags do NOT 1333 indicate that it must not be fragmented MAY be fragmented at any 1334 time, for any purpose, at the discretion of the bundle protocol 1335 agent. NOTE, however, that some combinations of bundle 1336 fragmentation, replication, and routing might result in unexpected 1337 traffic patterns. 1339 Fragmentation SHALL be constrained as follows: 1341 . The concatenation of the payloads of all fragments produced by 1342 fragmentation MUST always be identical to the payload of the 1343 fragmented bundle (that is, the bundle that is being 1344 fragmented). Note that the payloads of fragments resulting from 1345 different fragmentation episodes, in different parts of the 1346 network, may be overlapping subsets of the fragmented bundle's 1347 payload. 1348 . The primary block of each fragment MUST differ from that of the 1349 fragmented bundle, in that the bundle processing flags of the 1350 fragment MUST indicate that the bundle is a fragment and both 1351 fragment offset and total application data unit length must be 1352 provided. Additionally, the CRC of the primary block of the 1353 fragmented bundle, if any, MUST be replaced in each fragment by 1354 a new CRC computed for the primary block of that fragment. 1356 . The payload blocks of fragments will differ from that of the 1357 fragmented bundle as noted above. 1358 . If the fragmented bundle is not a fragment or is the fragment 1359 with offset zero, then all extension blocks of the fragmented 1360 bundle MUST be replicated in the fragment whose offset is zero. 1361 . Each of the fragmented bundle's extension blocks whose "Block 1362 must be replicated in every fragment" flag is set to 1 MUST be 1363 replicated in every fragment. 1364 . Beyond these rules, replication of extension blocks in the 1365 fragments is an implementation matter. 1367 5.9. Application Data Unit Reassembly 1369 If the concatenation -- as informed by fragment offsets and payload 1370 lengths -- of the payloads of all previously received fragments with 1371 the same source node ID and creation timestamp as this fragment, 1372 together with the payload of this fragment, forms a byte array whose 1373 length is equal to the total application data unit length in the 1374 fragment's primary block, then: 1376 . This byte array -- the reassembled application data unit -- 1377 MUST replace the payload of this fragment. 1378 . The "Reassembly pending" retention constraint MUST be removed 1379 from every other fragment whose payload is a subset of the 1380 reassembled application data unit. 1382 Note: reassembly of application data units from fragments occurs at 1383 the nodes that are members of destination endpoints as necessary; an 1384 application data unit MAY also be reassembled at some other node on 1385 the path to the destination. 1387 5.10. Bundle Deletion 1389 The steps in deleting a bundle are: 1391 Step 1: If the "request reporting of bundle deletion" flag in the 1392 bundle's status report request field is set to 1, and if status 1393 reporting is enabled, then a bundle deletion status report citing 1394 the reason for deletion SHOULD be generated, destined for the 1395 bundle's report-to endpoint ID. 1397 Step 2: All of the bundle's retention constraints MUST be removed. 1399 5.11. Discarding a Bundle 1401 As soon as a bundle has no remaining retention constraints it MAY be 1402 discarded, thereby releasing any persistent storage that may have 1403 been allocated to it. 1405 5.12. Canceling a Transmission 1407 When requested to cancel a specified transmission, where the bundle 1408 created upon initiation of the indicated transmission has not yet 1409 been discarded, the bundle protocol agent MUST delete that bundle 1410 for the reason "transmission cancelled". For this purpose, the 1411 procedure defined in Section 5.10 MUST be followed. 1413 6. Administrative Record Processing 1415 6.1. Administrative Records 1417 Administrative records are standard application data units that are 1418 used in providing some of the features of the Bundle Protocol. One 1419 type of administrative record has been defined to date: bundle 1420 status reports. Note that additional types of administrative 1421 records may be defined by supplementary DTN protocol specification 1422 documents. 1424 Every administrative record consists of: 1426 . Record type code (an unsigned integer for which valid values 1427 are as defined below). 1428 . Record content in type-specific format. 1430 Valid administrative record type codes are defined as follows: 1432 +---------+--------------------------------------------+ 1434 | Value | Meaning | 1436 +=========+============================================+ 1438 | 1 | Bundle status report. | 1440 +---------+--------------------------------------------+ 1442 | (other) | Reserved for future use. | 1444 +---------+--------------------------------------------+ 1445 Figure 3: Administrative Record Type Codes 1447 Each BP administrative record SHALL be represented as a CBOR array 1448 comprising a 2-tuple. 1450 The first item of the array SHALL be a record type code, which SHALL 1451 be represented as a CBOR unsigned integer. 1453 The second element of this array SHALL be the applicable CBOR 1454 representation of the content of the record. Details of the CBOR 1455 representation of administrative record type 1 are provided below. 1456 Details of the CBOR representation of other types of administrative 1457 record type are included in the specifications defining those 1458 records. 1460 6.1.1. Bundle Status Reports 1462 The transmission of "bundle status reports" under specified 1463 conditions is an option that can be invoked when transmission of a 1464 bundle is requested. These reports are intended to provide 1465 information about how bundles are progressing through the system, 1466 including notices of receipt, forwarding, final delivery, and 1467 deletion. They are transmitted to the Report-to endpoints of 1468 bundles. 1470 Each bundle status report SHALL be represented as a CBOR array. The 1471 number of elements in the array SHALL be either 6 (if the subject 1472 bundle is a fragment) or 4 (otherwise). 1474 The first item of the bundle status report array SHALL be bundle 1475 status information represented as a CBOR array of at least 4 1476 elements. The first four items of the bundle status information 1477 array shall provide information on the following four status 1478 assertions, in this order: 1480 . Reporting node received bundle. 1481 . Reporting node forwarded the bundle. 1482 . Reporting node delivered the bundle. 1483 . Reporting node deleted the bundle. 1485 Each item of the bundle status information array SHALL be a bundle 1486 status item represented as a CBOR array; the number of elements in 1487 each such array SHALL be either 2 (if the value of the first item of 1488 this bundle status item is 1 AND the "Report status time" flag was 1489 set to 1 in the bundle processing flags of the bundle whose status 1490 is being reported) or 1 (otherwise). The first item of the bundle 1491 status item array SHALL be a status indicator, a Boolean value 1492 indicating whether or not the corresponding bundle status is 1493 asserted, represented as a CBOR Boolean value. The second item of 1494 the bundle status item array, if present, SHALL indicate the time 1495 (as reported by the local system clock, an implementation matter) at 1496 which the indicated status was asserted for this bundle, represented 1497 as a DTN time as described in Section 4.1.6. above. 1499 The second item of the bundle status report array SHALL be the 1500 bundle status report reason code explaining the value of the status 1501 indicator, represented as a CBOR unsigned integer. Valid status 1502 report reason codes are defined in Figure 4 below but the list of 1503 status report reason codes provided here is neither exhaustive nor 1504 exclusive; supplementary DTN protocol specifications (including, but 1505 not restricted to, the Bundle Security Protocol [BPSEC]) may define 1506 additional reason codes. 1508 +---------+--------------------------------------------+ 1510 | Value | Meaning | 1512 +=========+============================================+ 1514 | 0 | No additional information. | 1516 +---------+--------------------------------------------+ 1518 | 1 | Lifetime expired. | 1520 +---------+--------------------------------------------+ 1522 | 2 | Forwarded over unidirectional link. | 1524 +---------+--------------------------------------------+ 1526 | 3 | Transmission canceled. | 1528 +---------+--------------------------------------------+ 1530 | 4 | Depleted storage. | 1532 +---------+--------------------------------------------+ 1534 | 5 | Destination endpoint ID unintelligible. | 1536 +---------+--------------------------------------------+ 1538 | 6 | No known route to destination from here. | 1539 +---------+--------------------------------------------+ 1541 | 7 | No timely contact with next node on route. | 1543 +---------+--------------------------------------------+ 1545 | 8 | Block unintelligible. | 1547 +---------+--------------------------------------------+ 1549 | 9 | Hop limit exceeded. | 1551 +---------+--------------------------------------------+ 1553 | (other) | Reserved for future use. | 1555 +---------+--------------------------------------------+ 1557 Figure 4: Status Report Reason Codes 1559 The third item of the bundle status report array SHALL be the source 1560 node ID identifying the source of the bundle whose status is being 1561 reported, represented as described in Section 4.1.5.2. above. 1563 The fourth item of the bundle status report array SHALL be the 1564 creation timestamp of the bundle whose status is being reported, 1565 represented as described in Section 4.1.7. above. 1567 The fifth item of the bundle status report array SHALL be present if 1568 and only if the bundle whose status is being reported contained a 1569 fragment offset. If present, it SHALL be the subject bundle's 1570 fragment offset represented as a CBOR unsigned integer item. 1572 The sixth item of the bundle status report array SHALL be present if 1573 and only if the bundle whose status is being reported contained a 1574 fragment offset. If present, it SHALL be the length of the subject 1575 bundle's payload represented as a CBOR unsigned integer item. 1577 6.2. Generation of Administrative Records 1579 Whenever the application agent's administrative element is directed 1580 by the bundle protocol agent to generate an administrative record 1581 with reference to some bundle, the following procedure must be 1582 followed: 1584 Step 1: The administrative record must be constructed. If the 1585 administrative record references a bundle and the referenced bundle 1586 is a fragment, the administrative record MUST contain the fragment 1587 offset and fragment length. 1589 Step 2: A request for transmission of a bundle whose payload is this 1590 administrative record MUST be presented to the bundle protocol 1591 agent. 1593 7. Services Required of the Convergence Layer 1595 7.1. The Convergence Layer 1597 The successful operation of the end-to-end bundle protocol depends 1598 on the operation of underlying protocols at what is termed the 1599 "convergence layer"; these protocols accomplish communication 1600 between nodes. A wide variety of protocols may serve this purpose, 1601 so long as each convergence layer protocol adapter provides a 1602 defined minimal set of services to the bundle protocol agent. This 1603 convergence layer service specification enumerates those services. 1605 7.2. Summary of Convergence Layer Services 1607 Each convergence layer protocol adapter is expected to provide the 1608 following services to the bundle protocol agent: 1610 . sending a bundle to a bundle node that is reachable via the 1611 convergence layer protocol; 1612 . delivering to the bundle protocol agent a bundle that was sent 1613 by a bundle node via the convergence layer protocol. 1615 The convergence layer service interface specified here is neither 1616 exhaustive nor exclusive. That is, supplementary DTN protocol 1617 specifications (including, but not restricted to, the Bundle 1618 Security Protocol [BPSEC]) may expect convergence layer adapters 1619 that serve BP implementations conforming to those protocols to 1620 provide additional services such as reporting on the transmission 1621 and/or reception progress of individual bundles (at completion 1622 and/or incrementally), retransmitting data that were lost in 1623 transit, discarding bundle-conveying data units that the convergence 1624 layer protocol determines are corrupt or inauthentic, or reporting 1625 on the integrity and/or authenticity of delivered bundles. 1627 8. Implementation Status 1629 [NOTE to the RFC Editor: please remove this section before 1630 publication, as well as the reference to RFC 7942.] 1631 This section records the status of known implementations of the 1632 protocol defined by this specification at the time of posting of 1633 this Internet-Draft, and is based on a proposal described in RFC 1634 7942. The description of implementations in this section is 1635 intended to assist the IETF in its decision processes in progressing 1636 drafts to RFCs. Please note that the listing of any individual 1637 implementation here does not imply endorsement by the IETF. 1638 Furthermore, no effort has been spent to verify the information 1639 presented here that was supplied by IETF contributors. This is not 1640 intended as, and must not be construed to be, a catalog of available 1641 implementations or their features. Readers are advised to note that 1642 other implementations may exist. 1644 According to RFC 7942, "this will allow reviewers and working groups 1645 to assign due consideration to documents that have the benefit of 1646 running code, which may serve as evidence of valuable 1647 experimentation and feedback that have made the implemented 1648 protocols more mature. It is up to the individual working groups to 1649 use this information as they see fit". 1651 At the time of this writing, there are two known implementations of 1652 the current document. 1654 The first known implementation is microPCN (https://upcn.eu/). 1655 According to the developers: 1657 The Micro Planetary Communication Network (uPCN) is a free 1658 software project intended to offer an implementation of Delay- 1659 tolerant Networking protocols for POSIX operating systems (well, 1660 and for Linux) plus for the ARM Cortex STM32F4 microcontroller 1661 series. More precisely it currently provides an implementation of 1663 . the Bundle Protocol (BP, RFC 5050), 1664 . the Bundle Protocol version 7 specification draft (version 6), 1665 . the DTN IP Neighbor Discovery (IPND) protocol, and 1666 . a routing approach optimized for message-ferry micro LEO 1667 satellites. 1669 uPCN is written in C and is built upon the real-time operating 1670 system FreeRTOS. The source code of uPCN is released under the 1671 "BSD 3-Clause License". 1673 The project depends on an execution environment offering link 1674 layer protocols such as AX.25. The source code uses the USB 1675 subsystem to interact with the environment. 1677 The second known implementation is PyDTN, developed by X-works, 1678 s.r.o (https://x-works.sk/). The final third of the implementation 1679 was developed during the IETF 101 Hackathon. According to the 1680 developers, PyDTN implements bundle coding/decoding and neighbor 1681 discovery. PyDTN is written in Python and has been shown to be 1682 interoperable with uPDN. 1684 9. Security Considerations 1686 The bundle protocol security architecture and the available security 1687 services are specified in an accompanying document, the Bundle 1688 Security Protocol specification [BPSEC]. 1690 The bpsec extensions to Bundle Protocol enable each block of a 1691 bundle (other than a bpsec extension block) to be individually 1692 authenticated by a signature block (Block Integrity Block, or BIB) 1693 and also enable each block of a bundle other than the primary block 1694 (and the bpsec extension blocks themselves) to be individually 1695 encrypted by a BCB. 1697 Because the security mechanisms are extension blocks that are 1698 themselves inserted into the bundle, the integrity and 1699 confidentiality of bundle blocks are protected while the bundle is 1700 at rest, awaiting transmission at the next forwarding opportunity, 1701 as well as in transit. 1703 Additionally, convergence-layer protocols that ensure authenticity 1704 of communication between adjacent nodes in BP network topology 1705 SHOULD be used where available, to minimize the ability of 1706 unauthenticated nodes to introduce inauthentic traffic into the 1707 network. 1709 Note that, while the primary block must remain in the clear for 1710 routing purposes, the Bundle Protocol can be protected against 1711 traffic analysis to some extent by using bundle-in-bundle 1712 encapsulation to tunnel bundles to a safe forward distribution 1713 point: the encapsulated bundle forms the payload of an encapsulating 1714 bundle, and that payload block may be encrypted by a BCB. 1716 Note that the generation of bundle status reports is disabled by 1717 default because malicious initiation of bundle status reporting 1718 could result in the transmission of extremely large numbers of 1719 bundle, effecting a denial of service attack. 1721 The bpsec extensions accommodate an open-ended range of 1722 ciphersuites; different ciphersuites may be utilized to protect 1723 different blocks. One possible variation is to sign and/or encrypt 1724 blocks in symmetric keys securely formed by Diffie-Hellman 1725 procedures (such as EKDH) using the public and private keys of the 1726 sending and receiving nodes. For this purpose, the key distribution 1727 problem reduces to the problem of trustworthy delay-tolerant 1728 distribution of public keys, a current research topic. 1730 Bundle security MUST NOT be invalidated by forwarding nodes even 1731 though they themselves might not use the Bundle Security Protocol. 1733 In particular, while blocks MAY be added to bundles transiting 1734 intermediate nodes, removal of blocks with the "Discard block if it 1735 can't be processed" flag set in the block processing control flags 1736 may cause security to fail. 1738 Inclusion of the Bundle Security Protocol in any Bundle Protocol 1739 implementation is RECOMMENDED. Use of the Bundle Security Protocol 1740 in Bundle Protocol operations is OPTIONAL, subject to the following 1741 guidelines: 1743 . Every block (that is not a bpsec extension block) of every 1744 bundle SHOULD be authenticated by a BIB citing the ID of the 1745 node that inserted that block. (Note that a single BIB may 1746 authenticate multiple "target" blocks.) BIB authentication MAY 1747 be omitted on (and only on) any initial end-to-end path 1748 segments on which it would impose unacceptable overhead, 1749 provided that satisfactory authentication is ensured at the 1750 convergence layer and that BIB authentication is asserted on 1751 the first path segment on which the resulting overhead is 1752 acceptable and on all subsequent path segments. 1753 . If any segment of the end-to-end path of a bundle will traverse 1754 the Internet or any other potentially insecure communication 1755 environment, then the payload block SHOULD be encrypted by a 1756 BCB on this path segment and all subsequent segments of the 1757 end-to-end path. 1759 10. IANA Considerations 1761 This document defines the following additional Bundle Protocol block 1762 types, for which values are to be assigned from the Bundle 1763 Administrative Record Types namespace [RFC6255]: 1765 Value Name Meaning Reference 1767 ----- ------------- ----------------------------- ---------- 1769 7 Previous node Identifies sender This document 1770 8 Bundle age Bundle age in seconds This document 1772 9 Hop count #prior transmission attempts This document 1774 This document also defines a new URI scheme type field - an unsigned 1775 integer of undefined length - for which IANA is to create and 1776 maintain a new registry named "URI scheme type values". Initial 1777 values for the Bundle Protocol URI scheme type registry are given 1778 below; future assignments are to be made through Expert Review. 1779 Each assignment consists of a URI scheme type name and its 1780 associated value. 1782 Value URI Scheme Type Name Reference 1784 ----- ------------------------ ------------------------------- 1786 0 Reserved 1788 1 dtn RFC5050, Section 4.4 1790 2 ipn RFC6260, Section 4 1792 3-254 Unassigned 1794 255 Reserved 1796 --------------------------------------------------------------- 1798 11. References 1800 11.1. Normative References 1802 [CRC] International Telecommunication Union, "Error-correcting 1803 procedures for DCEs using asynchronous-to-synchronous conversion", 1804 ITU-T Recommendation V.42, March 2002. 1806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1807 Requirement Levels", BCP 14, RFC 2119, March 1997. 1809 [RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object 1810 Representation (CBOR)", RFC 7049, October 2013. 1812 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1813 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 1814 January 2005. 1816 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 1817 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 1818 2015. 1820 11.2. Informative References 1822 [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 1823 4838, April 2007. 1825 [BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", Work In 1826 Progress, June 2017. 1828 [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work 1829 In Progress, October 2015. 1831 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1832 Identifiers (IRIs)", RFC 3987, January 2005. 1834 [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol 1835 IANA Registries", RFC 6255, May 2011. 1837 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 1838 Challenged Internets", SIGCOMM 2003. 1840 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 1841 historical background and perspectives" in "Journees systemes de 1842 reference spatio-temporels", 2004. 1844 12. Acknowledgments 1846 This work is freely adapted from RFC 5050, which was an effort of 1847 the Delay Tolerant Networking Research Group. The following DTNRG 1848 participants contributed significant technical material and/or 1849 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 1850 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 1851 Michael Demmer of the University of California at Berkeley, Robert 1852 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 1853 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 1854 College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of 1855 Ohio University, and Howard Weiss of SPARTA, Inc. 1857 This document was prepared using 2-Word-v2.0.template.dot. 1859 13. Significant Changes from RFC 5050 1861 Points on which this draft significantly differs from RFC 5050 1862 include the following: 1864 . Clarify the difference between transmission and forwarding. 1865 . Migrate custody transfer to the bundle-in-bundle encapsulation 1866 specification [BIBE]. 1867 . Introduce the concept of "node ID" as functionally distinct 1868 from endpoint ID, while having the same syntax. 1869 . Restructure primary block, making it immutable. Add optional 1870 CRC. 1871 . Add optional CRCs to non-primary blocks. 1872 . Add block ID number to canonical block format (to support 1873 streamlined BSP). 1874 . Add bundle age extension block, defined in this specification. 1875 . Add previous node extension block, defined in this 1876 specification. 1877 . Add flow label extension block, *not* defined in this 1878 specification. 1879 . Add manifest extension block, *not* defined in this 1880 specification. 1881 . Add hop count extension block, defined in this specification. 1882 . Migrate Quality of Service markings to a new QoS extension 1883 block, *not* defined in this specification. 1885 Appendix A. For More Information 1887 Please refer comments to dtn@ietf.org. DTN Working Group documents 1888 are located at https://datatracker.ietf.org/wg/dtn/documents. The 1889 original Delay Tolerant Networking Research Group (DTNRG) Web site 1890 is located at https://irtf.org/concluded/dtnrg. 1892 Copyright (c) 2018 IETF Trust and the persons identified as authors 1893 of the code. All rights reserved. 1895 Redistribution and use in source and binary forms, with or without 1896 modification, is permitted pursuant to, and subject to the license 1897 terms contained in, the Simplified BSD License set forth in Section 1898 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 1899 (http://trustee.ietf.org/license-info). 1901 Appendix B. CDDL expression 1903 For informational purposes, Carsten Bormann has kindly provided an 1904 expression of the Bundle Protocol specification in the Concise Data 1905 Definition Language (CDDL). That CDDL expression is presented 1906 below, somewhat edited by the authors. Note that wherever the CDDL 1907 expression is in disagreement with the textual representation of the 1908 BP specification presented in the earlier sections of this document, 1909 the textual representation rules. 1911 start = bundle 1913 dtn-time = uint 1915 creation-timestamp = [dtn-time, sequence: uint] 1917 eid-generic = [uri-code, SSP: any] 1919 uri-code = uint 1921 eid = eid-choice .within eid-generic 1923 eid-choice /= [dtn-code, SSP: (text / 0)] 1925 dtn-code = 1 ; TBD 1927 eid-choice /= [ipn-code, SSP: [nodenum: uint, servicenum: uint]] 1929 ipn-code = 2 ; TBD 1931 bundle-control-flags = uint .bits bundleflagbits 1933 bundleflagbits = &( 1935 reserved: 15 1937 reserved: 14 1939 reserved: 13 1941 bundle-deletion-status-reports-are-requested: 12 1943 bundle-delivery-status-reports-are-requested: 11 1945 bundle-forwarding-status-reports-are-requested: 10 1947 reserved: 9 1948 bundle-reception-status-reports-are-requested: 8 1950 bundle-contains-a-Manifest-block: 7 1952 status-time-is-requested-in-all-status-reports: 6 1954 user-application-acknowledgement-is-requested: 5 1956 reserved: 4 1958 reserved: 3 1960 bundle-must-not-be-fragmented: 2 1962 payload-is-an-administrative-record: 1 1964 bundle-is-a-fragment: 0 1966 ) 1968 crc = bytes 1970 block-control-flags = uint .bits blockflagbits 1972 blockflagbits = &( 1974 reserved: 7 1976 reserved: 6 1978 reserved: 5 1980 reserved: 4 1982 bundle-must-be-deleted-if-block-cannot-be-processed: 3 1984 status-report-must-be-transmitted-if-block-cannot-be-processed: 2 1986 block-must-be-removed-from-bundle-if-it-cannot-be-processed: 1 1988 block-must-be-replicated-in-every-fragment: 0 1990 ) 1992 bundle = [primary-block, *extension-block, payload-block] 1994 primary-block = [ 1995 version: 7, 1997 bundle-control-flags, 1999 crc-type: uint, 2001 destination: eid, 2003 source-node: eid, 2005 report-to: eid, 2007 creation-timestamp, 2009 lifetime: uint, 2011 ? fragment-offset: uint, 2013 ? total-application-data-length: uint, 2015 ? crc, 2017 ] 2019 canonical-block-generic = [ 2021 block-type-code: uint, 2023 canonical-block-common, 2025 content: any, 2027 ? crc 2029 ] 2031 canonical-block-common = ( 2033 block-number: uint, 2035 block-control-flags, 2037 crc-type: uint 2039 ) 2040 canonical-block = canonical-block-choice .within canonical-block- 2041 generic 2043 canonical-block-choice /= payload-block 2045 payload-block = [1, canonical-block-common, adu-extent: payload] 2047 payload = bytes / bytes .cbor admin-record 2049 canonical-block-choice /= extension-block 2051 extension-block = extension-block-choice .within canonical-block 2053 extension-block-choice /= previous-node-block 2055 previous-node-block = [7, canonical-block-common, eid] 2057 extension-block-choice /= bundle-age-block 2059 bundle-age-block = [8, canonical-block-common, bundle-age: uint] 2061 extension-block-choice /= hop-count-block 2063 hop-count-block = [9, canonical-block-common, 2065 [hop-limit: uint, 2067 hop-count: uint] 2069 ] 2071 admin-record-generic = [record-type: uint, any] 2073 admin-record = admin-record-choice .within admin-record-generic 2075 admin-record-choice /= bundle-status-report 2077 bundle-status-report = [1, [bundle-status-information, 2079 bundle-status-reason: uint, 2081 admin-common] 2083 ] 2085 admin-common = ( 2086 source-node: eid, 2088 creation-timestamp, 2090 ? fragment-offset: uint, 2092 ? payload-length: uint 2094 ) 2096 bundle-status-information = [ 2098 reporting-node-received-bundle: bundle-status-item, 2100 reporting-node-forwarded-the-bundle: bundle-status-item, 2102 reporting-node-delivered-the-bundle: bundle-status-item, 2104 reporting-node-deleted-the-bundle: bundle-status-item, 2106 ] 2108 bundle-status-item = [ 2110 asserted: bool, 2112 ? time-of-assertion: dtn-time 2114 ] 2116 Authors' Addresses 2118 Scott Burleigh 2119 Jet Propulsion Laboratory, California Institute of Technology 2120 4800 Oak Grove Dr. 2121 Pasadena, CA 91109-8099 2122 US 2123 Phone: +1 818 393 3353 2124 Email: Scott.Burleigh@jpl.nasa.gov 2125 Kevin Fall 2126 Nefeli Networks, Inc. 2127 2150 Shattuck Ave. 2128 Berkeley, CA 94704 2129 US 2130 Email: kfall@kfall.com 2132 Edward J. Birrane 2133 Johns Hopkins University Applied Physics Laboratory 2134 11100 Johns Hopkins Rd 2135 Laurel, MD 20723 2136 US 2137 Phone: +1 443 778 7423 2138 Email: Edward.Birrane@jhuapl.edu