idnits 2.17.1 draft-ietf-dtn-bpbis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 29, 2016) is 2735 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) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay-Tolerant Networking Working Group S. Burleigh 2 Internet Draft JPL, Calif. Inst. Of Technology 3 Intended status: Standards Track K. Fall 4 Expires: May 2017 Carnegie Mellon University / SEI 5 E. Birrane 6 APL, Johns Hopkins University 7 October 29, 2016 9 Bundle Protocol 10 draft-ietf-dtn-bpbis-06.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on May 2, 2017. 35 Copyright Notice 37 Copyright (c) 2016 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...............14 65 4. Bundle Format.................................................14 66 4.1. BP Fundamental Data Structures...........................15 67 4.1.1. CRC Type............................................15 68 4.1.2. CRC.................................................15 69 4.1.3. Bundle Processing Control Flags.....................15 70 4.1.4. Block Processing Control Flags......................17 71 4.1.5. Identifiers.........................................18 72 4.1.5.1. Endpoint ID....................................18 73 4.1.5.2. Node ID........................................19 74 4.1.6. DTN Time............................................19 75 4.1.7. Creation Timestamp..................................19 76 4.1.8. Block-type-specific Data............................19 77 4.2. Bundle Representation....................................20 78 4.2.1. Bundle..............................................20 79 4.2.2. Primary Bundle Block................................20 80 4.2.3. Canonical Bundle Block Format.......................22 81 4.3. Extension Blocks.........................................23 82 4.3.1. Current Custodian...................................24 83 4.3.2. Previous Node.......................................24 84 4.3.3. Bundle Age..........................................24 85 4.3.4. Hop Count...........................................25 86 5. Bundle Processing.............................................25 87 5.1. Generation of Administrative Records.....................25 88 5.2. Bundle Transmission......................................26 89 5.3. Bundle Dispatching.......................................27 90 5.4. Bundle Forwarding........................................27 91 5.4.1. Forwarding Contraindicated..........................29 92 5.4.2. Forwarding Failed...................................29 94 5.5. Bundle Expiration........................................30 95 5.6. Bundle Reception.........................................30 96 5.7. Local Bundle Delivery....................................31 97 5.8. Bundle Fragmentation.....................................32 98 5.9. Application Data Unit Reassembly.........................33 99 5.10. Custody Transfer........................................34 100 5.10.1. Custody Acceptance.................................34 101 5.10.2. Custody Release....................................35 102 5.11. Custody Transfer Success................................35 103 5.12. Custody Transfer Failure................................35 104 5.13. Custody Transfer Deferral...............................36 105 5.14. Bundle Deletion.........................................36 106 5.15. Discarding a Bundle.....................................37 107 5.16. Canceling a Transmission................................37 108 6. Administrative Record Processing..............................37 109 6.1. Administrative Records...................................37 110 6.1.1. Bundle Status Reports...............................38 111 6.1.2. Custody Signals.....................................40 112 6.2. Generation of Administrative Records.....................43 113 6.3. Reception of Custody Signals.............................44 114 7. Services Required of the Convergence Layer....................44 115 7.1. The Convergence Layer....................................44 116 7.2. Summary of Convergence Layer Services....................44 117 8. Security Considerations.......................................45 118 9. IANA Considerations...........................................46 119 10. References...................................................46 120 10.1. Normative References....................................46 121 10.2. Informative References..................................47 122 11. Acknowledgments..............................................47 123 12. Significant Changes from RFC 5050............................48 124 Appendix A. For More Information.................................49 125 Appendix B. CDDL expression......................................50 127 1. Introduction 129 Since the publication of the Bundle Protocol Specification 130 (Experimental RFC 5050[RFC5050]) in 2007, the Delay-Tolerant 131 Networking Bundle Protocol has been implemented in multiple 132 programming languages and deployed to a wide variety of computing 133 platforms for a wide range of successful exercises. This 134 implementation and deployment experience has demonstrated the 135 general utility of the protocol for challenged network operations. 137 It has also, as expected, identified opportunities for making the 138 protocol simpler, more capable, and easier to use. The present 139 document, standardizing the Bundle Protocol (BP), is adapted from 140 RFC 5050 in that context. 142 This document describes version 7 of BP. 144 Delay Tolerant Networking is a network architecture providing 145 communications in and/or through highly stressed environments. 146 Stressed networking environments include those with intermittent 147 connectivity, large and/or variable delays, and high bit error 148 rates. To provide its services, BP may be viewed as sitting at the 149 application layer of some number of constituent networks, forming a 150 store-carry-forward overlay network. Key capabilities of BP 151 include: 153 . Custodial forwarding 154 . Ability to cope with intermittent connectivity, including cases 155 where the sender and receiver are not concurrently present in 156 the network 157 . Ability to take advantage of scheduled, predicted, and 158 opportunistic connectivity, whether bidirectional or 159 unidirectional, in addition to continuous connectivity 160 . Late binding of overlay network endpoint identifiers to 161 underlying constituent network addresses 163 For descriptions of these capabilities and the rationale for the DTN 164 architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial- 165 level overview of DTN concepts. 167 BP's location within the standard protocol stack is as shown in 168 Figure 1. BP uses underlying "native" transport and/or network 169 protocols for communications within a given constituent network. 171 The interface between the bundle protocol and a specific underlying 172 protocol is termed a "convergence layer adapter". 174 Figure 1 shows three distinct transport and network protocols 175 (denoted T1/N1, T2/N2, and T3/N3). 177 +-----------+ +-----------+ 178 | BP app | | BP app | 179 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 180 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 181 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 182 | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | 183 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 184 | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | 185 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 186 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 187 +-----------+ +-------------+ +-------------+ +-----------+ 188 | | | | 189 |<---- A network ---->| |<---- A network ---->| 190 | | | | 192 Figure 1: The Bundle Protocol in the Protocol Stack Model 194 This document describes the format of the protocol data units 195 (called "bundles") passed between entities participating in BP 196 communications. 198 The entities are referred to as "bundle nodes". This document does 199 not address: 201 . Operations in the convergence layer adapters that bundle nodes 202 use to transport data through specific types of internets. 203 (However, the document does discuss the services that must be 204 provided by each adapter at the convergence layer.) 205 . The bundle route computation algorithm. 206 . Mechanisms for populating the routing or forwarding information 207 bases of bundle nodes. 208 . The mechanisms for securing bundles en route. 209 . The mechanisms for managing bundle nodes. 211 2. Conventions used in this document 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in RFC-2119 [RFC2119]. 217 In this document, these words will appear with that interpretation 218 only when in ALL CAPS. Lower case uses of these words are not to be 219 interpreted as carrying RFC-2119 significance. 221 3. Service Description 223 3.1. Definitions 225 Bundle - A bundle is a protocol data unit of BP, so named because 226 negotiation of the parameters of a data exchange may be impractical 227 in a delay-tolerant network: it is often better practice to "bundle" 228 with a unit of data all metadata that might be needed in order to 229 make the data immediately usable when delivered to applications. 230 Each bundle comprises a sequence of two or more "blocks" of protocol 231 data, which serve various purposes. 233 Block - A bundle protocol block is one of the protocol data 234 structures that together constitute a well-formed bundle. 236 Bundle payload - A bundle payload (or simply "payload") is the 237 application data whose conveyance to the bundle's destination is the 238 purpose for the transmission of a given bundle; it is the content of 239 the bundle's payload block. The terms "bundle content", "bundle 240 payload", and "payload" are used interchangeably in this document. 242 Partial payload - A partial payload is a payload that comprises 243 either the first N bytes or the last N bytes of some other payload 244 of length M, such that 0 < N < M. 246 Fragment - A fragment is a bundle whose payload block contains a 247 partial payload. 249 Bundle node - A bundle node (or, in the context of this document, 250 simply a "node") is any entity that can send and/or receive bundles. 251 Each bundle node has three conceptual components, defined below, as 252 shown in Figure 2: a "bundle protocol agent", a set of zero or more 253 "convergence layer adapters", and an "application agent". 255 +-----------------------------------------------------------+ 256 |Node | 257 | | 258 | +-------------------------------------------------------+ | 259 | |Application Agent | | 260 | | | | 261 | | +--------------------------+ +----------------------+ | | 262 | | |Administrative element | |Application-specific | | | 263 | | | | |element | | | 264 | | | | | | | | 265 | | +--------------------------+ +----------------------+ | | 266 | | ^ ^ | | 267 | | Admin|records Application|data | | 268 | | | | | | 269 | +----------------v--------------------------v-----------+ | 270 | ^ | 271 | | ADUs | 272 | | | 273 | +-----------------------------v-------------------------+ | 274 | |Bundle Protocol Agent | | 275 | | | | 276 | | | | 277 | +-------------------------------------------------------+ | 278 | ^ ^ ^ | 279 | | Bundles | Bundles Bundles | | 280 | | | | | 281 | +------v-----+ +-----v------+ +-----v-----+ | 282 | |CLA 1 | |CLA 2 | |CLA n | | 283 | | | | | . . . | | | 284 | | | | | | | | 285 +-+------------+-----+------------+-----------+-----------+-+ 286 ^ ^ ^ 287 CL1|PDUs CL2|PDUs CLn|PDUs 288 | | | 289 +------v-----+ +-----v------+ +-----v-----+ 290 Network 1 Network 2 Network n 292 Figure 2: Components of a BP Node 294 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 295 the node component that offers the BP services and executes the 296 procedures of the bundle protocol. 298 Convergence layer adapter - A convergence layer adapter (CLA) is a 299 node component that sends and receives bundles on behalf of the BPA, 300 utilizing the services of some 'native' protocol stack that is 301 supported in one of the networks within which the node is 302 functionally located. 304 Application agent - The application agent (AA) of a node is the node 305 component that utilizes the BP services to effect communication for 306 some user purpose. The application agent in turn has two elements, 307 an administrative element and an application-specific element. 309 Application-specific element - The application-specific element of 310 an AA is the node component that constructs, requests transmission 311 of, accepts delivery of, and processes units of user application 312 data. 314 Administrative element - The administrative element of an AA is the 315 node component that constructs and requests transmission of 316 administrative records (defined below), including status reports and 317 custody signals, and accepts delivery of and processes any custody 318 signals that the node receives. 320 Administrative record - A BP administrative record is an application 321 data unit that is exchanged between the administrative elements of 322 nodes' application agents for some BP administrative purpose. The 323 formats of some fundamental administrative records (and of no other 324 application data units) are defined in this specification. 326 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 327 of zero or more bundle nodes that all identify themselves for BP 328 purposes by some common identifier, called a "bundle endpoint ID" 329 (or, in this document, simply "endpoint ID"; endpoint IDs are 330 described in detail in Section 4.4.1 below). 332 Singleton endpoint - A singleton endpoint is an endpoint that always 333 contains exactly one member. 335 Registration - A registration is the state machine characterizing a 336 given node's membership in a given endpoint. Any single 337 registration has an associated delivery failure action as defined 338 below and must at any time be in one of two states: Active or 339 Passive. 341 Delivery - A bundle is considered to have been delivered at a node 342 subject to a registration as soon as the application data unit that 343 is the payload of the bundle, together with any relevant metadata 344 (an implementation matter), has been presented to the node's 345 application agent in a manner consistent with the state of that 346 registration. 348 Deliverability - A bundle is considered "deliverable" subject to a 349 registration if and only if (a) the bundle's destination endpoint is 350 the endpoint with which the registration is associated, (b) the 351 bundle has not yet been delivered subject to this registration, and 352 (c) the bundle has not yet been "abandoned" (as defined below) 353 subject to this registration. 355 Abandonment - To abandon a bundle subject to some registration is to 356 assert that the bundle is not deliverable subject to that 357 registration. 359 Delivery failure action - The delivery failure action of a 360 registration is the action that is to be taken when a bundle that is 361 "deliverable" subject to that registration is received at a time 362 when the registration is in the Passive state. 364 Destination - The destination of a bundle is the endpoint comprising 365 the node(s) at which the bundle is to be delivered (as defined 366 below). 368 Minimum reception group - The minimum reception group of an endpoint 369 is the minimum number of members of the endpoint (nodes) at which 370 the bundle must have been delivered in order for the bundle to be 371 considered delivered to the endpoint. 373 Transmission - A transmission is an attempt by a node's BPA to cause 374 copies of a bundle to be delivered at all nodes in the minimum 375 reception group of some endpoint (the bundle's destination) in 376 response to a transmission request issued by the node's application 377 agent. 379 Forwarding - To forward a bundle to a node is to invoke the services 380 of a CLA in a sustained effort to cause a copy of the bundle to be 381 received by that node. 383 Discarding - To discard a bundle is to cease all operations on the 384 bundle and functionally erase all references to it. The specific 385 procedures by which this is accomplished are an implementation 386 matter. 388 Retention constraint - A retention constraint is an element of the 389 state of a bundle that prevents the bundle from being discarded. 390 That is, a bundle cannot be discarded while it has any retention 391 constraints. 393 Deletion - To delete a bundle is to remove unconditionally all of 394 the bundle's retention constraints, enabling the bundle to be 395 discarded. 397 Custodian - A custodian of a bundle is a node that has determined 398 that it will retain a copy of that bundle for an indefinite period 399 of time, forwarding and possibly re-forwarding the bundle as 400 appropriate, until it detects one of the conditions under which it 401 may cease being a custodian of that bundle (discussed later). 403 Taking custody - To take custody of a bundle is to become a 404 custodian of that bundle. 406 Accepting custody - To accept custody of a bundle is to take custody 407 of the bundle, mark the bundle in such a way as to indicate this 408 custodianship to nodes that subsequently receive copies of the 409 bundle, and announce this custodianship to all current custodians of 410 the bundle. 412 Refusing custody - To "refuse custody" of a bundle is to notify all 413 current custodians of that bundle that an opportunity to take 414 custody of the bundle has been declined. 416 Releasing custody - To release custody of a bundle is to cease to be 417 a custodian of the bundle. 419 3.2. Discussion of BP concepts 421 Multiple instances of the same bundle (the same unit of DTN protocol 422 data) might exist concurrently in different parts of a network -- 423 possibly differing in some blocks -- in the memory local to one or 424 more bundle nodes and/or in transit between nodes. In the context of 425 the operation of a bundle node, a bundle is an instance (copy), in 426 that node's local memory, of some bundle that is in the network. 428 The payload for a bundle forwarded in response to a bundle 429 transmission request is the application data unit whose location is 430 provided as a parameter to that request. The payload for a bundle 431 forwarded in response to reception of a bundle is the payload of the 432 received bundle. 434 In the most familiar case, a bundle node is instantiated as a single 435 process running on a general-purpose computer, but in general the 436 definition is meant to be broader: a bundle node might alternatively 437 be a thread, an object in an object-oriented operating system, a 438 special-purpose hardware device, etc. 440 The manner in which the functions of the BPA are performed is wholly 441 an implementation matter. For example, BPA functionality might be 442 coded into each node individually; it might be implemented as a 443 shared library that is used in common by any number of bundle nodes 444 on a single computer; it might be implemented as a daemon whose 445 services are invoked via inter-process or network communication by 446 any number of bundle nodes on one or more computers; it might be 447 implemented in hardware. 449 Every CLA implements its own thin layer of protocol, interposed 450 between BP and the (usually "top") protocol(s) of the underlying 451 native protocol stack; this "CL protocol" may only serve to 452 multiplex and de-multiplex bundles to and from the underlying native 453 protocol, or it may offer additional CL-specific functionality. The 454 manner in which a CLA sends and receives bundles is, again, wholly 455 an implementation matter. The definitions of CLAs and CL protocols 456 are beyond the scope of this specification. 458 Note that the administrative element of a node's application agent 459 may itself, in some cases, function as a convergence-layer adapter. 460 That is, outgoing bundles may be "tunneled" through encapsulating 461 bundles: 463 . An outgoing bundle constitutes a byte array. This byte array 464 may, like any other, be presented to the bundle protocol agent 465 as an application data unit that is to be transmitted to some 466 endpoint. 467 . The original bundle thus forms the payload of an encapsulating 468 bundle that is forwarded using some other convergence-layer 469 protocol(s). 471 . When the encapsulating bundle is received, its payload is 472 delivered to the peer application agent administrative element, 473 which then instructs the bundle protocol agent to dispatch that 474 original bundle in the usual way. 476 The purposes for which this technique may be useful (such as cross- 477 domain security) are beyond the scope of this specification. 479 The only interface between the BPA and the application-specific 480 element of the AA is the BP service interface. But between the BPA 481 and the administrative element of the AA there is a (conceptual) 482 private control interface in addition to the BP service interface. 483 This private control interface enables the BPA and the 484 administrative element of the AA to direct each other to take action 485 under specific circumstances 487 In the case of a node that serves simply as a BP "router", the AA 488 may have no application-specific element at all. The application- 489 specific elements of other nodes' AAs may perform arbitrarily 490 complex application functions, perhaps even offering multiplexed DTN 491 communication services to a number of other applications. As with 492 the BPA, the manner in which the AA performs its functions is wholly 493 an implementation matter. 495 Singletons are the most familiar sort of endpoint, but in general 496 the endpoint notion is meant to be broader. For example, the nodes 497 in a sensor network might constitute a set of bundle nodes that 498 identify themselves by a single common endpoint ID and thus form a 499 single bundle endpoint. *Note* too that a given bundle node might 500 identify itself by multiple endpoint IDs and thus be a member of 501 multiple bundle endpoints. 503 The destination of every bundle is an endpoint, which may or may not 504 be singleton. The source of every bundle is a node, identified by 505 the endpoint ID for some singleton endpoint that contains that node. 507 The minimum reception group of an endpoint may be any one of the 508 following: (a) ALL of the nodes registered in an endpoint that is 509 permitted to contain multiple nodes (in which case forwarding to the 510 endpoint is functionally similar to "multicast" operations in the 511 Internet, though possibly very different in implementation); (b) ANY 512 N of the nodes registered in an endpoint that is permitted to 513 contain multiple nodes, where N is in the range from zero to the 514 cardinality of the endpoint; or (c) THE SOLE NODE registered in a 515 singleton endpoint (in which case forwarding to the endpoint is 516 functionally similar to "unicast" operations in the Internet). 518 The nature of the minimum reception group for a given endpoint can 519 typically be determined from the endpoint's ID. For some endpoint 520 ID "schemes", the nature of the minimum reception group is fixed - 521 in a manner that is defined by the scheme - for all endpoints 522 identified under the scheme. For other schemes, the nature of the 523 minimum reception group is indicated by some lexical feature of the 524 "scheme-specific part" of the endpoint ID, in a manner that is 525 defined by the scheme. 527 Any number of transmissions may be concurrently undertaken by the 528 bundle protocol agent of a given node. 530 When the bundle protocol agent of a node determines that a bundle 531 must be forwarded to a node (either to a node that is a member of 532 the bundle's destination endpoint or to some intermediate forwarding 533 node) in the course of completing the successful transmission of 534 that bundle, it invokes the services of a CLA in a sustained effort 535 to cause a copy of the bundle to be received by that node. 537 Upon reception, the processing of a bundle that has been received by 538 a given node depends on whether or not the receiving node is 539 registered in the bundle's destination endpoint. If it is, and if 540 the payload of the bundle is non-fragmentary (possibly as a result 541 of successful payload reassembly from fragmentary payloads, 542 including the original payload of the newly received bundle), then 543 the bundle is normally delivered to the node's application agent 544 subject to the registration characterizing the node's membership in 545 the destination endpoint. 547 Whenever, for some implementation-specific reason, a node's BPA 548 finds it impossible to immediately deliver a bundle that is 549 deliverable, delivery of the bundle has failed. In this event, the 550 delivery failure action associated with the applicable registration 551 must be taken. Delivery failure action MUST be one of the following: 553 . defer delivery of the bundle subject to this registration until 554 (a) this bundle is the least recently received of all bundles 555 currently deliverable subject to this registration and (b) 556 either the registration is polled or else the registration is 557 in the Active state; or 559 . abandon delivery of the bundle subject to this registration. 561 An additional implementation-specific delivery deferral procedure 562 MAY optionally be associated with the registration. 564 While the state of a registration is Passive, reception of a bundle 565 that is deliverable subject to this registration MUST cause delivery 566 of the bundle to be abandoned or deferred as mandated by the 567 registration's current delivery failure action; in the latter case, 568 any additional delivery deferral procedure associated with the 569 registration MUST also be performed. 571 While the state of a registration is Active, reception of a bundle 572 that is deliverable subject to this registration MUST cause the 573 bundle to be delivered automatically as soon as it is the next 574 bundle that is due for delivery according to the BPA's bundle 575 delivery scheduling policy, an implementation matter. 577 Normally only registrations' registered delivery failure actions 578 cause deliveries to be abandoned. 580 Custody of a bundle MAY be taken only if the destination of the 581 bundle is a singleton endpoint. Custody MAY be released only when 582 either (a) notification is received that some other node has 583 accepted custody of the same bundle; (b) notification is received 584 that the bundle has been delivered at the (sole) node registered in 585 the bundle's destination endpoint; (c) the current custodian chooses 586 to fragment the bundle, releasing custody of the original bundle and 587 taking custody of the fragments instead, or (d) the bundle is 588 explicitly deleted for some reason, such as lifetime expiration. 590 The custody transfer mechanism in BP provides a means of recovering 591 from data loss along the path to the destination node. When the 592 custodian of a bundle forwards that bundle it SHOULD set a 593 retransmission timer; reception of a responding custody signal of 594 any kind prior to timer expiration MUST disable that timer. Upon 595 expiration of that timer, the custodian MUST re-forward the bundle. 596 When a bundle for which custody has been taken arrives at a node 597 from which it must be forwarded, and that node determines that it 598 will forward the bundle but will not take custody, the receiving 599 node SHOULD send a "custody delegation" signal back to the custodian 600 indicating the next node to which the bundle will be forwarded 601 together with an estimate of the interval that will elapse between 602 the time the bundle was received and the time at which it will be 603 forwarded. This mechanism is intended to facilitate accurate 604 timeout interval calculation for this bundle. 606 Computation of the timeout interval for a bundle's custody transfer 607 timer (i.e., determination of the moment at which a responding 608 custody signal is expected) is an implementation matter and may be 609 dynamically responsive to changes in connectivity. In some 610 environments it may be impossible to compute this interval with 611 operationally satisfactory accuracy; in such environments the use of 612 custody transfer services is contraindicated. 614 Alternatively, when custody transfer for a given bundle is not 615 requested, data loss along the path to the destination node can be 616 minimized by utilizing reliable convergence-layer protocols between 617 neighbors on all segments of the end-to-end path. This approach may 618 make more efficient use of links than custody transfer because a 619 convergence-layer protocol may perform finer-grained retransmission 620 than custody transfer does, retransmitting only the specific 621 portions of a transmitted bundle that were not received, rather than 622 the entire bundle. However, in some environments there may be 623 segments of the end-to-end path for which no reliable convergence- 624 layer protocol is available; in such environments the use of 625 reliable convergence-layer protocols wherever possible can reduce 626 the incidence of data loss. 628 3.3. Services Offered by Bundle Protocol Agents 630 The BPA of each node is expected to provide the following services 631 to the node's application agent: 633 . commencing a registration (registering the node in an 634 endpoint); 635 . terminating a registration; 636 . switching a registration between Active and Passive states; 637 . transmitting a bundle to an identified bundle endpoint; 638 . canceling a transmission; 639 . polling a registration that is in the Passive state; 640 . delivering a received bundle. 642 4. Bundle Format 644 The format of bundles SHALL conform to the Concise Binary Object 645 Representation (CBOR [RFC7049]). 647 Each bundle SHALL be a concatenated sequence of at least two blocks, 648 represented as a CBOR indefinite-length array. The first block in 649 the sequence (the first item of the array) MUST be a primary bundle 650 block in CBOR representation as described below; the bundle MUST 651 have exactly one primary bundle block. The primary block MUST be 652 followed by one or more canonical bundle blocks (additional array 653 items) in CBOR representation as described below. The last such 654 block MUST be a payload block; the bundle MUST have exactly one 655 payload block. The last item of the array, immediately following 656 the payload block, SHALL be a CBOR "break" stop code. 658 4.1. BP Fundamental Data Structures 660 4.1.1. CRC Type 662 CRC type is an unsigned integer type code for which the following 663 values (and no others) are valid: 665 . 0 indicates "no CRC is present." 666 . 1 indicates "a CRC-16 (a.k.a., CRC-16-ANSI) is present." 667 . 2 indicates "a standard IEEE 802.3 CRC-32 is present." 669 CRC type SHALL be represented as a CBOR unsigned integer. 671 4.1.2. CRC 673 CRC SHALL be omitted from a block if and only if the block's CRC 674 type code is zero. 676 When not omitted, the CRC SHALL be represented as a CBOR unsigned 677 integer. 679 4.1.3. Bundle Processing Control Flags 681 Bundle processing control flags assert properties of the bundle as a 682 whole rather than of any particular block of the bundle. They are 683 conveyed in the primary block of the bundle. 685 The following properties are asserted by the bundle processing 686 control flags: 688 . The bundle is a fragment. (Boolean) 690 . The bundle's payload is an administrative record. (Boolean) 692 . The bundle must not be fragmented. (Boolean) 694 . Custody transfer requested for this bundle. (Boolean) 696 . The bundle's destination endpoint is a singleton. (Boolean) 698 . Acknowledgment by the user application is requested. (Boolean) 700 . Status time is requested in all status reports. (Boolean) 702 . The bundle contains a "manifest" extension block. (Boolean) 704 . Flags requesting types of status reports (all Boolean): 706 o Request reporting of bundle reception. 708 o Request reporting of custody transfer request processing. 710 o Request reporting of bundle forwarding. 712 o Request reporting of bundle delivery. 714 o Request reporting of bundle deletion. 716 If the bundle processing control flags indicate that the bundle's 717 application data unit is an administrative record, then the custody 718 transfer requested flag value must be zero and all status report 719 request flag values must be zero. 721 If the custody transfer requested flag value is 1, then the source 722 node is requesting that every receiving node accept custody of the 723 bundle. 725 If the bundle's source node is omitted (i.e., the source node ID is 726 the ID of the null endpoint, which has no members as discussed 727 below; this option enables anonymous bundle transmission), then the 728 bundle is not uniquely identifiable and all bundle protocol features 729 that rely on bundle identity must therefore be disabled: the 730 bundle's custody transfer requested flag value must be zero, the 731 "Bundle must not be fragmented" flag value must be 1, and all status 732 report request flag values must be zero. 734 The bundle processing control flags SHALL be represented as a CBOR 735 unsigned integer item containing a bit field of 16 bits indicating 736 the control flag values as follows: 738 . Bit 0 (the high-order bit, 0x8000): reserved. 739 . Bit 1 (0x4000): reserved. 740 . Bit 2 (0x2000): reserved. 741 . Bit 3(0x1000): bundle deletion status reports are requested. 742 . Bit 4(0x0800): bundle delivery status reports are requested. 743 . Bit 5(0x0400): bundle forwarding status reports are requested. 744 . Bit 6(0x0200): custody request processing status reports are 745 requested. 746 . Bit 7(0x0100): bundle reception status reports are requested. 747 . Bit 8(0x0080): bundle contains a Manifest block. 748 . Bit 9(0x0040): status time is requested in all status reports. 749 . Bit 10(0x0020): user application acknowledgement is requested. 750 . Bit 11(0x0010): destination is a singleton endpoint. 751 . Bit 12(0x0008): custody transfer is requested. 752 . Bit 13(0x0004): bundle must not be fragmented. 754 . Bit 14(0x0002): payload is an administrative record. 755 . Bit 15 (the low-order bit, 0x0001: bundle is a fragment. 757 4.1.4. Block Processing Control Flags 759 The block processing control flags assert properties of canonical 760 bundle blocks. They are conveyed in the header of the block to 761 which they pertain. 763 The following properties are asserted by the block processing 764 control flags: 766 . This block must be replicated in every fragment. (Boolean) 768 . Status report must be transmitted if this block can't be 769 processed. (Boolean) 771 . Block must be removed from the bundle if it can't be processed. 772 (Boolean) 774 . Bundle must be deleted if this block can't be processed. 775 (Boolean) 777 For each bundle whose bundle processing control flags indicate that 778 the bundle's application data unit is an administrative record, or 779 whose source node ID is the null endpoint ID as defined below, the 780 value of the "Transmit status report if block can't be processed" 781 flag in every canonical block of the bundle must be zero. 783 The block processing control flags SHALL be represented as a CBOR 784 unsigned integer item containing a bit field of 8 bits indicating 785 the control flag values as follows: 787 . Bit 0 (the high-order bit, 0x80): reserved. 788 . Bit 1 (0x40): reserved. 789 . Bit 2(0x20): reserved. 790 . Bit 3(0x10): reserved. 791 . Bit 4(0x08): bundle must be deleted if block can't be 792 processed. 793 . Bit 5(0x04): status report must be transmitted if block can't 794 be processed. 795 . Bit 6(0x02): block must be removed from bundle if it can't be 796 processed. 797 . Bit 7(the low-order bit, 0x01): block must be replicated in 798 every fragment. 800 4.1.5. Identifiers 802 4.1.5.1. Endpoint ID 804 The destinations of bundles are bundle endpoints, identified by text 805 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 806 (EID) is a Uniform Resource Identifier (URI; [URI]). As such, each 807 endpoint ID can be characterized as having this general structure: 809 < scheme name > : < scheme-specific part, or "SSP" > 811 The scheme identified by the < scheme name > in an endpoint ID is a 812 set of syntactic and semantic rules that fully explain how to parse 813 and interpret the SSP. The set of allowable schemes is effectively 814 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 815 protocol endpoint ID. 817 Note that, although endpoint IDs are URIs, implementations of the BP 818 service interface may support expression of endpoint IDs in some 819 internationalized manner (e.g., Internationalized Resource 820 Identifiers (IRIs); see [RFC3987]). 822 The endpoint ID "dtn:none" identifies the "null endpoint", the 823 endpoint that by definition never has any members. 825 Each BP endpoint ID (EID) SHALL be represented as a CBOR array 826 comprising a 2-tuple. 828 The first item of the array SHALL be the code number identifying the 829 endpoint's URI scheme [URI], as defined in the registry of URI 830 scheme code numbers for Bundle Protocol maintained by IANA as 831 described in Section 9. [URIREG]. Each URI scheme code number SHALL 832 be represented as a CBOR unsigned integer. 834 The second item of the array SHALL be the applicable CBOR 835 representation of the scheme-specific part (SSP) of the EID, defined 836 as follows: 838 . If the EID's URI scheme is "dtn" then the SSP SHALL be 839 represented as a CBOR text string unless the EID's SSP is 840 "none", in which case the SSP SHALL be represented as a CBOR 841 unsigned integer with the value zero. 842 . If the EID's URI scheme is "ipn" then the SSP SHALL be 843 represented as a CBOR array comprising a 2-tuple. The first 844 item of this array SHALL be the EID's node number represented 845 as a CBOR unsigned integer. The second item of this array 846 SHALL be the EID's service number represented as a CBOR 847 unsigned integer. 848 . Definitions of the CBOR representations of the SSPs of EIDs 849 encoded in other URI schemes are included in the specifications 850 defining those schemes. 852 4.1.5.2. Node ID 854 For many purposes of the Bundle Protocol it is important to identify 855 the node that is operative in some context. 857 As discussed in 3.1 above, nodes are distinct from endpoints; 858 specifically, an endpoint is a set of zero or more nodes. But 859 rather than define a separate namespace for node identifiers, we 860 instead use endpoint identifiers to identify nodes, subject to the 861 following restrictions: 863 . Every node MUST be a member of at least one singleton endpoint. 864 . The EID of any singleton endpoint of which a node is a member 865 MAY be used to identify that node. A "node ID" is an EID that 866 is used in this way. 867 . A node's membership in a given singleton endpoint MUST be 868 sustained at least until the nominal operation of the Bundle 869 Protocol no longer depends on the identification of that node 870 using that endpoint's ID. 872 4.1.6. DTN Time 874 A DTN time is an unsigned integer indicating a count of seconds 875 since the start of the year 2000 on the Coordinated Universal Time 876 (UTC) scale [UTC]. Each DTN time SHALL be represented as a CBOR 877 unsigned integer item. 879 4.1.7. Creation Timestamp 881 Each creation timestamp SHALL be represented as a CBOR array item 882 comprising a 2-tuple. 884 The first item of the array SHALL be a DTN time. 886 The second item of the array SHALL be the creation timestamp's 887 sequence number, represented as a CBOR unsigned integer. 889 4.1.8. Block-type-specific Data 891 Block-type-specific data in each block (other than the primary 892 block) SHALL be the applicable CBOR representation of the content of 893 the block. Details of this representation are included in the 894 specification defining the block type. 896 4.2. Bundle Representation 898 This section describes the primary block in detail and non-primary 899 blocks in general. Rules for processing these blocks appear in 900 Section 5 of this document. 902 Note that supplementary DTN protocol specifications (including, but 903 not restricted to, the Bundle Security Protocol [BPSEC]) may require 904 that BP implementations conforming to those protocols construct and 905 process additional blocks. 907 4.2.1. Bundle 909 Each bundle SHALL be represented as a CBOR indefinite-length array. 910 The first item of this array SHALL be the CBOR representation of a 911 Primary Block. Every other item of the array except the last SHALL 912 be the CBOR representation of a Canonical Block. The last item of 913 the array SHALL be a CBOR "break" stop code. 915 4.2.2. Primary Bundle Block 917 The primary bundle block contains the basic information needed to 918 forward bundles to their destinations. 920 Each primary block SHALL be represented as a CBOR array; the number 921 of elements in the array SHALL be 8 (if the bundle is not a fragment 922 and CRC type is zero) or 9 (if the bundle is not a fragment and CRC 923 type is non-zero) or 10 (if the bundle is a fragment and CRC type is 924 zero) or 11 (if the bundle is a fragment and CRC-type is non-zero). 926 The fields of the primary bundle block SHALL be as follows, listed 927 in the order in which they MUST appear: 929 Version: An unsigned integer value indicating the version of the 930 bundle protocol that constructed this block. The present document 931 describes version 7 of the bundle protocol. Version number SHALL be 932 represented as a CBOR unsigned integer item. 934 Bundle Processing Control Flags: The Bundle Processing Control Flags 935 are discussed in Section 4.1.3. above. 937 CRC Type: CRC Type codes are discussed in Section 4.1.1. above. 939 Destination EID: The Destination EID field identifies the bundle 940 endpoint that is the bundle's destination, i.e., the endpoint that 941 contains the node(s) at which the bundle is to be delivered. 943 Source node ID: The Source node ID field identifies the bundle node 944 at which the bundle was initially transmitted, except that Source 945 node ID may be the null endpoint ID in the event that the bundle's 946 source chooses to remain anonymous. 948 Report-to EID: The Report-to EID field identifies the bundle 949 endpoint to which status reports pertaining to the forwarding and 950 delivery of this bundle are to be transmitted. 952 Creation Timestamp: The creation timestamp is a pair of unsigned 953 integers that, together with the source node ID and (if the bundle 954 is a fragment) the fragment offset, serve to identify the bundle. 955 The first of these integers is the bundle's creation time, while the 956 second is the bundle's creation timestamp sequence number. Bundle 957 creation time shall be the time - expressed in seconds since the 958 start of the year 2000, on the Coordinated Universal Time (UTC) 959 scale [UTC] - at which the transmission request was received that 960 resulted in the creation of the bundle. Sequence count shall be the 961 latest value (as of the time at which that transmission request was 962 received) of a monotonically increasing positive integer counter 963 managed by the source node's bundle protocol agent that may be reset 964 to zero whenever the current time advances by one second. For nodes 965 that lack accurate clocks (that is, nodes that are not at all 966 moments able to determine the current UTC time to within 30 967 seconds), bundle creation time MUST be set to zero and the counter 968 used as the source of the bundle sequence count MUST NEVER be reset 969 to zero. In any case, a source Bundle Protocol Agent MUST NEVER 970 create two distinct bundles with the same source node ID and bundle 971 creation timestamp. The combination of source node ID and bundle 972 creation timestamp serves to identify a single transmission request, 973 enabling it to be acknowledged by the receiving application 974 (provided the source node ID is not the null endpoint ID). 976 Lifetime: The lifetime field is an unsigned integer that indicates 977 the time at which the bundle's payload will no longer be useful, 978 encoded as a number of seconds past the creation time. When a 979 bundle's age exceeds its lifetime, bundle nodes need no longer 980 retain or forward the bundle; the bundle SHOULD be deleted from the 981 network. Bundle lifetime SHALL be represented as a CBOR unsigned 982 integer item. 984 Fragment offset: If and only if the Bundle Processing Control Flags 985 of this Primary block indicate that the bundle is a fragment, 986 fragment offset SHALL be present in the primary block. Fragment 987 offset SHALL be represented as a CBOR unsigned integer indicating 988 the offset from the start of the original application data unit at 989 which the bytes comprising the payload of this bundle were located. 991 Total Application Data Unit Length: If and only if the Bundle 992 Processing Control Flags of this Primary block indicate that the 993 bundle is a fragment, total application data unit length SHALL be 994 present in the primary block. Total application data unit length 995 SHALL be represented as aCBOR unsigned integer indicating the total 996 length of the original application data unit of which this bundle's 997 payload is a part. 999 CRC: If and only if the value of the CRC type field of this Primary 1000 block is non-zero, a CRC SHALL be present in the primary block. The 1001 length and nature of the CRC SHALL be as indicated by the CRC type. 1002 The CRC SHALL be computed over the concatenation of all bytes of the 1003 primary block including the CRC field itself, which for this purpose 1004 SHALL be temporarily populated with the value zero. 1006 4.2.3. Canonical Bundle Block Format 1008 Every block other than the primary block (which blocks are termed 1009 "canonical" blocks) SHALL be represented as a CBOR array; the number 1010 of elements in the array SHALL be 6 (if CRC type is zero) or 7 1011 (otherwise). 1013 The fields of every canonical block SHALL be as follows, listed in 1014 the order in which they MUST appear: 1016 . Block type code, an unsigned integer. Bundle block type code 1 1017 indicates that the block is a bundle payload block. Block type 1018 codes 2 through 9 are explicitly reserved as noted later in 1019 this specification. Block type codes 192 through 255 are not 1020 reserved and are available for private and/or experimental use. 1021 All other block type code values are reserved for future use. 1022 . Block number, an unsigned integer. The block number uniquely 1023 identifies the block within the bundle, enabling blocks 1024 (notably bundle security protocol blocks) to explicitly 1025 reference other blocks in the same bundle. Block numbers need 1026 not be in continuous sequence, and blocks need not appear in 1027 block number sequence in the bundle. The block number of the 1028 payload block is always zero. 1029 . Block processing control flags as discussed in Section 4.1.4 1030 above. 1031 . CRC type as discussed in Section 4.1.1 above. 1033 . If and only if the value of the CRC type field of this block is 1034 non-zero, a CRC. If present, the length and nature of the CRC 1035 SHALL be as indicated by the CRC type and the CRC SHALL be 1036 computed over the concatenation of all bytes of the block 1037 including the CRC field itself, which for this purpose SHALL be 1038 temporarily populated with the value zero. 1039 . Block data length, an unsigned integer. The block data length 1040 field SHALL contain the aggregate length of all remaining 1041 fields of the block, i.e., the block-type-specific data fields. 1042 Block data length SHALL be represented as a CBOR unsigned 1043 integer item. 1044 . Block-type-specific data fields, whose nature and order are 1045 type-specific and whose aggregate length in octets is the value 1046 of the block data length field. For the Payload Block in 1047 particular (block type 1), there SHALL be exactly one block- 1048 type-specific data field, termed the "payload", which SHALL be 1049 an application data unit, or some contiguous extent thereof, 1050 represented as a CBOR byte string. 1052 4.3. Extension Blocks 1054 "Extension blocks" are all blocks other than the primary and payload 1055 blocks. Because not all extension blocks are defined in the Bundle 1056 Protocol specification (the present document), not all nodes 1057 conforming to this specification will necessarily instantiate Bundle 1058 Protocol implementations that include procedures for processing 1059 (that is, recognizing, parsing, acting on, and/or producing) all 1060 extension blocks. It is therefore possible for a node to receive a 1061 bundle that includes extension blocks that the node cannot process. 1062 The values of the block processing control flags indicate the action 1063 to be taken by the bundle protocol agent when this is the case. 1065 (Note that, while CBOR permits considerable flexibility in the 1066 encoding of bundles, this flexibility must not be interpreted as 1067 inviting increased complexity in protocol data unit structure.) 1069 The following extension blocks are defined in other DTN protocol 1070 specification documents as noted: 1072 . Block Integrity Block (block type 2) and Block Confidentiality 1073 Block (block type 3) are defined in the Bundle Security 1074 Protocol specification (work in progress). 1075 . Manifest Block (block type 4) is defined in the Manifest 1076 Extension Block specification (TBD). The manifest block 1077 identifies the blocks that were present in the bundle at the 1078 time it was created. The bundle MUST contain one (1) 1079 occurrence of this type of block if the value of the "manifest" 1080 flag in the bundle processing control flags is 1; otherwise the 1081 bundle MUST NOT contain any Manifest block. 1082 . The Flow Label Block (block type 6) is defined in the Flow 1083 Label Extension Block specification (TBD). The flow label 1084 block is intended to govern transmission of the bundle by 1085 convergence-layer adapters. 1087 The following extension blocks are defined in the current document. 1089 4.3.1. Current Custodian 1091 The Current Custodian block, block type 5, identifies a node that is 1092 known to have accepted custody of the bundle. The block-type- 1093 specific data of this block is the node ID of a custodian, which 1094 SHALL take the form of an endpoint ID represented as described in 1095 Section 4.1.5.2. above. The bundle MAY contain one or more 1096 occurrences of this type of block. 1098 4.3.2. Previous Node 1100 The Previous Node block, block type 7, identifies the node that 1101 forwarded this bundle to the local node (i.e., to the node at which 1102 the bundle currently resides); its block-type-specific data is the 1103 node ID of that forwarder node which SHALL take the form of a node 1104 ID represented as described in Section 4.1.5.2. above. If the local 1105 node is the source of the bundle, then the bundle MUST NOT contain 1106 any previous node block. Otherwise the bundle MUST contain one (1) 1107 occurrence of this type of block. If present, the previous node 1108 block MUST be the FIRST block following the primary block, as the 1109 processing of other extension blocks may depend on its value. 1111 4.3.3. Bundle Age 1113 The Bundle Age block, block type 8, contains the number of seconds 1114 that have elapsed between the time the bundle was created and time 1115 at which it was most recently forwarded. It is intended for use by 1116 nodes lacking access to an accurate clock, to aid in determining the 1117 time at which a bundle's lifetime expires. The block-type-specific 1118 data of this block is an unsigned integer containing the age of the 1119 bundle in seconds, which SHALL be represented as a CBOR unsigned 1120 integer item. (The age of the bundle is the sum of all known 1121 intervals of the bundle's residence at forwarding nodes, up to the 1122 time at which the bundle was most recently forwarded, plus the 1123 summation of signal propagation time over all episodes of 1124 transmission between forwarding nodes. Determination of these 1125 values is an implementation matter.) If the bundle's creation time 1126 is zero, then the bundle MUST contain exactly one (1) occurrence of 1127 this type of block; otherwise, the bundle MAY contain at most one 1128 (1) occurrence of this type of block. 1130 4.3.4. Hop Count 1132 The Hop Count block, block type 9, contains two unsigned integers, 1133 hop limit and hop count. A "hop" is here defined as an occasion on 1134 which a bundle was forwarded from one node to another node. The hop 1135 count block is mainly intended as a safety mechanism, a means of 1136 identifying bundles for removal from the network that can never be 1137 delivered due to a persistent forwarding error: a bundle SHOULD be 1138 deleted when its hop count exceeds its hop limit. Procedures for 1139 determining the appropriate hop limit for a block are beyond the 1140 scope of this specification. The block-type-specific data in a hop 1141 count block SHALL be represented as a CBOR array comprising a 2- 1142 tuple. The first item of this array SHALL be the bundle's hop 1143 limit, represented as a CBOR unsigned integer. The second item of 1144 this array SHALL be the bundle's hop count, represented as a CBOR 1145 unsigned integer. A bundle MAY contain at most one (1) occurrence of 1146 this type of block. 1148 5. Bundle Processing 1150 The bundle processing procedures mandated in this section and in 1151 Section 6 govern the operation of the Bundle Protocol Agent and the 1152 Application Agent administrative element of each bundle node. They 1153 are neither exhaustive nor exclusive. Supplementary DTN protocol 1154 specifications (including, but not restricted to, the Bundle 1155 Security Protocol [BPSEC]) may augment, override, or supersede the 1156 mandates of this document. 1158 5.1. Generation of Administrative Records 1160 All transmission of bundles is in response to bundle transmission 1161 requests presented by nodes' application agents. When required to 1162 "generate" an administrative record (such as a bundle status report 1163 or a custody signal), the bundle protocol agent itself is 1164 responsible for causing a new bundle to be transmitted, conveying 1165 that record. In concept, the bundle protocol agent discharges this 1166 responsibility by directing the administrative element of the node's 1167 application agent to construct the record and request its 1168 transmission as detailed in Section 6 below. In practice, the manner 1169 in which administrative record generation is accomplished is an 1170 implementation matter, provided the constraints noted in Section 6 1171 are observed. 1173 Under some circumstances, the requesting of status reports could 1174 result in an unacceptable increase in the bundle traffic in the 1175 network. For this reason, the generation of status reports is 1176 mandatory only in two cases: 1178 . the reception of a bundle containing at least one block that 1179 cannot be processed, for which the value of the "transmit 1180 status report if block could not be processed" block processing 1181 flag is 1, and 1182 . the deletion of a bundle for which custody transfer is 1183 requested. 1185 In all other cases, the decision on whether or not to generate a 1186 requested status report is left to the discretion of the bundle 1187 protocol agent. Mechanisms that could assist in making such 1188 decisions, such as pre-placed agreements authorizing the generation 1189 of status reports under specified circumstances, are beyond the 1190 scope of this specification. 1192 Notes on administrative record terminology: 1194 . A "bundle reception status report" is a bundle status report 1195 with the "reporting node received bundle" flag set to 1. 1196 . A "custody transfer status report" is a bundle status report 1197 with the "reporting node attempted custody transfer" flag set 1198 to 1. 1199 . A "bundle forwarding status report" is a bundle status report 1200 with the "reporting node forwarded the bundle" flag set to 1. 1201 . A "bundle delivery status report" is a bundle status report 1202 with the "reporting node delivered the bundle" flag set to 1. 1203 . A "bundle deletion status report" is a bundle status report 1204 with the "reporting node deleted the bundle" flag set to 1. 1205 . A "current custodian" of a bundle is a node identified in a 1206 Current Custodian extension block of that bundle. 1208 5.2. Bundle Transmission 1210 The steps in processing a bundle transmission request are: 1212 Step 1: If custody transfer is requested for this bundle 1213 transmission then the destination MUST be a singleton endpoint. If, 1214 moreover, custody acceptance by the source node is required when 1215 custody is requested (an implementation matter) but the conditions 1216 under which custody of the bundle may be accepted are not satisfied, 1217 then the request cannot be honored and all remaining steps of this 1218 procedure MUST be skipped. 1220 Step 2: Transmission of the bundle is initiated. An outbound bundle 1221 MUST be created per the parameters of the bundle transmission 1222 request, with the retention constraint "Dispatch pending". The 1223 source node ID of the bundle MUST be either the null endpoint ID, 1224 indicating that the source of the bundle is anonymous, or else the 1225 EID of a singleton endpoint whose only member is the node of which 1226 the BPA is a component. 1228 Step 3: Processing proceeds from Step 1 of Section 5.4. 1230 5.3. Bundle Dispatching 1232 The steps in dispatching a bundle are: 1234 Step 1: If the bundle's destination endpoint is an endpoint of which 1235 the node is a member, the bundle delivery procedure defined in 1236 Section 5.7 MUST be followed. 1238 Step 2: Processing proceeds from Step 1 of Section 5.4. 1240 5.4. Bundle Forwarding 1242 The steps in forwarding a bundle are: 1244 Step 1: The retention constraint "Forward pending" MUST be added to 1245 the bundle, and the bundle's "Dispatch pending" retention constraint 1246 MUST be removed. 1248 Step 2: The bundle protocol agent MUST determine whether or not 1249 forwarding is contraindicated for any of the reasons listed in 1250 Figure 4. In particular: 1252 . The bundle protocol agent MUST determine which node(s) to 1253 forward the bundle to. The bundle protocol agent MAY choose 1254 either to forward the bundle directly to its destination 1255 node(s) (if possible) or to forward the bundle to some other 1256 node(s) for further forwarding. The manner in which this 1257 decision is made may depend on the scheme name in the 1258 destination endpoint ID and/or on other state but in any case 1259 is beyond the scope of this document. If the BPA elects to 1260 forward the bundle to some other node(s) for further forwarding 1261 but finds it impossible to select any node(s) to forward the 1262 bundle to, then forwarding is contraindicated. 1263 . Provided the bundle protocol agent succeeded in selecting the 1264 node(s) to forward the bundle to, the bundle protocol agent 1265 MUST select the convergence layer adapter(s) whose services 1266 will enable the node to send the bundle to those nodes. The 1267 manner in which specific appropriate convergence layer adapters 1268 are selected is beyond the scope of this document. If the agent 1269 finds it impossible to select any appropriate convergence layer 1270 adapter(s) to use in forwarding this bundle, then forwarding is 1271 contraindicated. 1273 Step 3: If forwarding of the bundle is determined to be 1274 contraindicated for any of the reasons listed in Figure 4, then the 1275 Forwarding Contraindicated procedure defined in Section 5.4.1 MUST 1276 be followed; the remaining steps of Section 5 are skipped at this 1277 time. 1279 Step 4: If the bundle's custody transfer requested flag (in the 1280 bundle processing flags field) is set to 1, then the custody 1281 transfer procedure defined in Section 5.10 MUST be followed. 1283 Step 5: For each node selected for forwarding, the bundle protocol 1284 agent MUST invoke the services of the selected convergence layer 1285 adapter(s) in order to effect the sending of the bundle to that 1286 node. Determining the time at which the bundle protocol agent 1287 invokes convergence layer adapter services is a BPA implementation 1288 matter. Determining the time at which each convergence layer 1289 adapter subsequently responds to this service invocation by sending 1290 the bundle is a convergence-layer adapter implementation matter. 1291 Note that: 1293 . If the bundle contains a flow label extension block then that 1294 flow label value MAY identify procedures for determining the 1295 order in which convergence layer adapters must send bundles, 1296 e.g., considering bundle source when determining the order in 1297 which bundles are sent. The definition of such procedures is 1298 beyond the scope of this specification. 1299 . If the bundle has a bundle age block, then at the last possible 1300 moment before the CLA initiates conveyance of the bundle node 1301 via the CL protocol the bundle age value MUST be increased by 1302 the difference between the current time and the time at which 1303 the bundle was received (or, if the local node is the source of 1304 the bundle, created). 1306 Step 6: When all selected convergence layer adapters have informed 1307 the bundle protocol agent that they have concluded their data 1308 sending procedures with regard to this bundle: 1310 . If the "request reporting of bundle forwarding" flag in the 1311 bundle's status report request field is set to 1, then a bundle 1312 forwarding status report SHOULD be generated, destined for the 1313 bundle's report-to endpoint ID. If the bundle has the retention 1314 constraint "custody accepted" and all of the nodes to which the 1315 bundle was forwarded are known to be unable to send bundles 1316 back to this node, then the reason code on this bundle 1317 forwarding status report MUST be "forwarded over unidirectional 1318 link"; otherwise, the reason code MUST be "no additional 1319 information". 1320 . The bundle's "Forward pending" retention constraint MUST be 1321 removed. 1323 5.4.1. Forwarding Contraindicated 1325 The steps in responding to contraindication of forwarding are: 1327 Step 1: The bundle protocol agent MUST determine whether or not to 1328 declare failure in forwarding the bundle. Note: this decision is 1329 likely to be influenced by the reason for which forwarding is 1330 contraindicated. 1332 Step 2: If forwarding failure is declared, then the Forwarding 1333 Failed procedure defined in Section 5.4.2 MUST be followed. 1335 Otherwise, (a) if the bundle's custody transfer requested flag (in 1336 the bundle processing flags field) is set to 1, then the custody 1337 transfer procedure defined in Section 5.10 MUST be followed; (b) 1338 when -- at some future time - the forwarding of this bundle ceases 1339 to be contraindicated, processing proceeds from Step 5 of Section 1340 5.4. 1342 5.4.2. Forwarding Failed 1344 The steps in responding to a declaration of forwarding failure are: 1346 Step 1: If the bundle's custody transfer requested flag (in the 1347 bundle processing flags field) is set to 1, custody transfer failure 1348 must be handled. The bundle protocol agent MUST handle the custody 1349 transfer failure by generating a custody signal of type 1 (custody 1350 refusal) for the bundle, destined for the bundle's current 1351 custodian(s); the custody signal MUST contain a reason code 1352 corresponding to the reason for which forwarding was determined to 1353 be contraindicated. (Note that discarding the bundle will not delete 1354 it from the network, since each current custodian still has a copy.) 1355 In addition, if the "request reporting of custody transfer 1356 attempted" flag in the bundle's status report request field is set 1357 to 1, a custody transfer status report with the same reason code 1358 SHOULD be generated, destined for the report-to endpoint ID of the 1359 bundle. 1361 If the bundle's custody transfer requested flag (in the bundle 1362 processing flags field) is set to 0, then the bundle protocol agent 1363 MAY forward the bundle back to the node that sent it, as identified 1364 by the Previous Node block. 1366 Step 2: If the bundle's destination endpoint is an endpoint of which 1367 the node is a member, then the bundle's "Forward pending" retention 1368 constraint MUST be removed. Otherwise, the bundle MUST be deleted: 1369 the bundle deletion procedure defined in Section 5.14 MUST be 1370 followed, citing the reason for which forwarding was determined to 1371 be contraindicated. 1373 5.5. Bundle Expiration 1375 A bundle expires when the bundle's age exceeds its lifetime as 1376 specified in the primary bundle block. Bundle age MAY be determined 1377 by subtracting the bundle's creation timestamp time from the current 1378 time if (a) that timestamp time is not zero and (b) the local node's 1379 clock is known to be accurate (as discussed in section 4.5.1 above); 1380 otherwise bundle age MUST be obtained from the Bundle Age extension 1381 block. Bundle expiration MAY occur at any point in the processing 1382 of a bundle. When a bundle expires, the bundle protocol agent MUST 1383 delete the bundle for the reason "lifetime expired": the bundle 1384 deletion procedure defined in Section 5.14 MUST be followed. 1386 5.6. Bundle Reception 1388 The steps in processing a bundle that has been received from another 1389 node are: 1391 Step 1: The retention constraint "Dispatch pending" MUST be added to 1392 the bundle. 1394 Step 2: If the "request reporting of bundle reception" flag in the 1395 bundle's status report request field is set to 1, then a bundle 1396 reception status report with reason code "No additional information" 1397 SHOULD be generated, destined for the bundle's report-to endpoint 1398 ID. 1400 Step 3: For each block in the bundle that is an extension block that 1401 the bundle protocol agent cannot process: 1403 . If the block processing flags in that block indicate that a 1404 status report is requested in this event, then a bundle 1405 reception status report with reason code "Block unintelligible" 1406 SHOULD be generated, destined for the bundle's report-to 1407 endpoint ID. 1409 . If the block processing flags in that block indicate that the 1410 bundle must be deleted in this event, then the bundle protocol 1411 agent MUST delete the bundle for the reason "Block 1412 unintelligible"; the bundle deletion procedure defined in 1413 Section 5.14 MUST be followed and all remaining steps of the 1414 bundle reception procedure MUST be skipped. 1415 . If the block processing flags in that block do NOT indicate 1416 that the bundle must be deleted in this event but do indicate 1417 that the block must be discarded, then the bundle protocol 1418 agent MUST remove this block from the bundle. 1419 . If the block processing flags in that block indicate neither 1420 that the bundle must be deleted nor that that the block must be 1421 discarded, then processing continues with the next extension 1422 block that the bundle protocol agent cannot process, if any; 1423 otherwise, processing proceeds from step 4. 1425 Step 4: If the bundle's custody transfer requested flag (in the 1426 bundle processing flags field) is set to 1 and the bundle has the 1427 same source node ID, creation timestamp, and (if the bundle is a 1428 fragment) fragment offset as another bundle that (a) has not been 1429 discarded and (b) currently has the retention constraint "Custody 1430 accepted", then custody transfer redundancy MUST be handled; 1431 otherwise, processing proceeds from Step 5. The bundle protocol 1432 agent MUST handle custody transfer redundancy by generating a 1433 custody signal of type 1 (custody refusal) for this bundle with 1434 reason code "Redundant reception", destined for this bundle's 1435 current custodian, and removing this bundle's "Dispatch pending" 1436 retention constraint. 1438 Step 5: Processing proceeds from Step 1 of Section 5.3. 1440 5.7. Local Bundle Delivery 1442 The steps in processing a bundle that is destined for an endpoint of 1443 which this node is a member are: 1445 Step 1: If the received bundle is a fragment, the application data 1446 unit reassembly procedure described in Section 5.9 MUST be followed. 1447 If this procedure results in reassembly of the entire original 1448 application data unit, processing of this bundle (whose fragmentary 1449 payload has been replaced by the reassembled application data unit) 1450 proceeds from Step 2; otherwise, the retention constraint 1451 "Reassembly pending" MUST be added to the bundle and all remaining 1452 steps of this procedure MUST be skipped. 1454 Step 2: Delivery depends on the state of the registration whose 1455 endpoint ID matches that of the destination of the bundle: 1457 . If the registration is in the Active state, then the bundle 1458 MUST be delivered subject to this registration (see Section 3.1 1459 above) as soon as all previously received bundles that are 1460 deliverable subject to this registration have been delivered. 1461 . If the registration is in the Passive state, then the 1462 registration's delivery failure action MUST be taken (see 1463 Section 3.1 above). 1465 Step 3: As soon as the bundle has been delivered: 1467 . If the "request reporting of bundle delivery" flag in the 1468 bundle's status report request field is set to 1, then a bundle 1469 delivery status report SHOULD be generated, destined for the 1470 bundle's report-to endpoint ID. Note that this status report 1471 only states that the payload has been delivered to the 1472 application agent, not that the application agent has processed 1473 that payload. 1474 . If the bundle's custody transfer requested flag (in the bundle 1475 processing flags field) is set to 1, custodial delivery MUST be 1476 reported. The bundle protocol agent MUST report custodial 1477 delivery by generating a custody signal of type 0 (custody 1478 acceptance) for the bundle, destined for the bundle's current 1479 custodian(s). 1481 5.8. Bundle Fragmentation 1483 It may at times be advantageous for bundle protocol agents to reduce 1484 the sizes of bundles in order to forward them. This might be the 1485 case, for example, if a node to which a bundle is to be forwarded is 1486 accessible only via intermittent contacts and no upcoming contact is 1487 long enough to enable the forwarding of the entire bundle. 1489 The size of a bundle can be reduced by "fragmenting" the bundle. To 1490 fragment a bundle whose payload is of size M is to replace it with 1491 two "fragments" -- new bundles with the same source node ID and 1492 creation timestamp as the original bundle -- whose payloads are the 1493 first N and the last (M - N) bytes of the original bundle's payload, 1494 where 0 < N < M. Note that fragments may themselves be fragmented, 1495 so fragmentation may in effect replace the original bundle with more 1496 than two fragments. (However, there is only one 'level' of 1497 fragmentation, as in IP fragmentation.) 1499 Any bundle that has any Current Custodian extension block citing any 1500 node other than the local node MUST NOT be fragmented. This 1501 restriction aside, any bundle whose primary block's bundle 1502 processing flags do NOT indicate that it must not be fragmented MAY 1503 be fragmented at any time, for any purpose, at the discretion of the 1504 bundle protocol agent. 1506 Fragmentation SHALL be constrained as follows: 1508 . The concatenation of the payloads of all fragments produced by 1509 fragmentation MUST always be identical to the payload of the 1510 fragmented bundle (that is, the bundle that is being 1511 fragmented). Note that the payloads of fragments resulting from 1512 different fragmentation episodes, in different parts of the 1513 network, may be overlapping subsets of the fragmented bundle's 1514 payload. 1515 . The primary block of each fragment MUST differ from that of the 1516 fragmented bundle, in that the bundle processing flags of the 1517 fragment MUST indicate that the bundle is a fragment and both 1518 fragment offset and total application data unit length must be 1519 provided. Additionally, the CRC of the fragmented bundle, if 1520 any, MUST be replaced in each fragment by a new CRC computed 1521 for the primary block of that fragment. 1522 . The payload blocks of fragments will differ from that of the 1523 fragmented bundle as noted above. 1524 . If the fragmented bundle is not a fragment or is the fragment 1525 with offset zero, then all extension blocks of the fragmented 1526 bundle MUST be replicated in the fragment whose offset is zero. 1527 . Each of the fragmented bundle's extension blocks whose "Block 1528 must be replicated in every fragment" flag is set to 1 MUST be 1529 replicated in every fragment. 1530 . Beyond these rules, replication of extension blocks in the 1531 fragments is an implementation matter. 1532 . If the local node is a custodian of the fragmented bundle, then 1533 the BPA MUST release custody of the fragmented bundle before 1534 fragmentation occurs and MUST take custody of every fragment. 1536 5.9. Application Data Unit Reassembly 1538 If the concatenation -- as informed by fragment offsets and payload 1539 lengths -- of the payloads of all previously received fragments with 1540 the same source node ID and creation timestamp as this fragment, 1541 together with the payload of this fragment, forms a byte array whose 1542 length is equal to the total application data unit length in the 1543 fragment's primary block, then: 1545 . This byte array -- the reassembled application data unit -- 1546 MUST replace the payload of this fragment. 1547 . The BPA MUST take custody of each fragmentary bundle whose 1548 payload is a subset of the reassembled application data unit, 1549 for which custody transfer is requested but the BPA has not yet 1550 taken custody. 1551 . The BPA MUST then release custody of every fragment whose 1552 payload is a subset of the reassembled application data unit, 1553 for which it has taken custody. 1554 . The "Reassembly pending" retention constraint MUST be removed 1555 from every other fragment whose payload is a subset of the 1556 reassembled application data unit. 1558 Note: reassembly of application data units from fragments occurs at 1559 the nodes that are members of destination endpoints as necessary; an 1560 application data unit MAY also be reassembled at some other node on 1561 the path to the destination. 1563 5.10. Custody Transfer 1565 The decision as to whether or not to accept custody of a bundle is 1566 an implementation matter that may involve both resource and policy 1567 considerations. 1569 If the bundle protocol agent elects to accept custody of the bundle, 1570 then it must follow the custody acceptance procedure defined in 1571 Section 5.10.1. 1573 5.10.1. Custody Acceptance 1575 Procedures for acceptance of custody of a bundle are defined as 1576 follows. 1578 The retention constraint "Custody accepted" MUST be added to the 1579 bundle. 1581 If the "request reporting of custody transfer attempted" flag in the 1582 bundle's status report request field is set to 1, a custody transfer 1583 status report with reason code 0 SHOULD be generated, destined for 1584 the report-to endpoint ID of the bundle. However, if a bundle 1585 reception status report was generated for this bundle (Step 2 of 1586 Section 5.6) but has not yet been transmitted, then this report 1587 SHOULD be generated by simply turning on the "Reporting node 1588 attempted custody transfer" flag in that earlier report. 1590 The bundle protocol agent MUST generate a custody signal of type 0 1591 (custody acceptance) for the bundle, destined for the bundle's 1592 current custodian(s). 1594 The bundle protocol agent MUST assert the new current custodian for 1595 the bundle. It does so by deleting all of the bundle's existing 1596 Current Custodian extension blocks and inserting a new Current 1597 Custodian extension block whose value is the node ID of the local 1598 node. 1600 If the value of a custody transfer timer interval for this bundle 1601 can be calculated with operationally satisfactory accuracy, then the 1602 bundle protocol agent SHOULD set a custody transfer countdown timer 1603 for the bundle; upon expiration of this timer prior to expiration of 1604 the bundle itself and prior to custody transfer success for this 1605 bundle, the custody transfer failure procedure detailed in Section 1606 5.12 MUST be followed. The manner in which the countdown interval 1607 for such a timer is determined is an implementation matter. 1609 The bundle SHOULD be retained in persistent storage if possible. 1611 5.10.2. Custody Release 1613 When custody of a bundle is released, the "Custody accepted" 1614 retention constraint MUST be removed from the bundle and any custody 1615 transfer timer that has been established for this bundle SHOULD be 1616 destroyed. 1618 5.11. Custody Transfer Success 1620 Upon receipt of a custody signal of type 0 (custody acceptance) at a 1621 node that is a custodial node of the bundle identified in the 1622 custody signal, custody of the bundle MUST be released as described 1623 in Section 5.10.2. 1625 5.12. Custody Transfer Failure 1627 Custody transfer is determined to have failed at a custodial node 1628 for a given bundle when either (a) that node's custody transfer 1629 timer for that bundle (if any) expires or (b) a custody signal of 1630 type 1 (custody refusal) for that bundle is received at that node. 1632 Upon determination of custody transfer failure due to expiration of 1633 a custody transfer countdown timer, the bundle protocol agent MUST 1634 re-forward the bundle, possibly on a different route (Section 5.4). 1636 Upon determination of custody transfer failure due to reception of a 1637 custody signal of type 1 (custody refusal), the action taken by the 1638 bundle protocol agent is implementation-specific and may depend on 1639 the reason code cited for the refusal. For example, if the custody 1640 signal's reason code was "Depleted storage", the bundle protocol 1641 agent might choose to re-forward the bundle, possibly on a different 1642 route (Section 5.4). If the reason code was "Redundant reception", 1643 on the other hand, this might cause the bundle protocol agent to 1644 release custody of the bundle and to revise its algorithm for 1645 computing countdown intervals for custody transfer timers. 1647 5.13. Custody Transfer Deferral 1649 Upon receipt of a bundle for which custody transfer retransmission 1650 service has been requested, which the bundle protocol agent plans to 1651 forward but for which it elects not to accept custody, the bundle 1652 protocol agent SHOULD generate a custody signal of type 2 (custody 1653 delegation) for the bundle, destined for the bundle's current 1654 custodian(s). 1656 Custody transfer is determined to have been deferred at a custodial 1657 node for given bundle when a custody signal of type 2 (custody 1658 delegation) for that bundle is received at that node. The action 1659 taken by the bundle protocol agent in this event is implementation- 1660 specific. Notionally, this is an opportunity for the bundle 1661 protocol agent to revise its retransmission timeout interval for 1662 this bundle, based on the information provided in the custody 1663 signal: the next candidate custodian for the bundle is now known, 1664 and the minimum length of time before a custody acceptance signal 1665 will arrive can now be adjusted accordingly. 1667 5.14. Bundle Deletion 1669 The steps in deleting a bundle are: 1671 Step 1: If the retention constraint "Custody accepted" currently 1672 prevents this bundle from being discarded, then: 1674 . Custody of the bundle is released as described in Section 1675 5.10.2. 1676 . A bundle deletion status report citing the reason for deletion 1677 MUST be generated, destined for the bundle's report-to endpoint 1678 ID. 1680 Otherwise, if the "request reporting of bundle deletion" flag in the 1681 bundle's status report request field is set to 1, then a bundle 1682 deletion status report citing the reason for deletion SHOULD be 1683 generated, destined for the bundle's report-to endpoint ID. 1685 Step 2: All of the bundle's retention constraints MUST be removed. 1687 5.15. Discarding a Bundle 1689 As soon as a bundle has no remaining retention constraints it MAY be 1690 discarded, thereby releasing any persistent storage that may have 1691 been allocated to it. 1693 5.16. Canceling a Transmission 1695 When requested to cancel a specified transmission, where the bundle 1696 created upon initiation of the indicated transmission has not yet 1697 been discarded, the bundle protocol agent MUST delete that bundle 1698 for the reason "transmission cancelled". For this purpose, the 1699 procedure defined in Section 5.14 MUST be followed. 1701 6. Administrative Record Processing 1703 6.1. Administrative Records 1705 Administrative records are standard application data units that are 1706 used in providing some of the features of the Bundle Protocol. Two 1707 types of administrative records have been defined to date: bundle 1708 status reports and custody signals. Note that additional types of 1709 administrative records may be defined by supplementary DTN protocol 1710 specification documents. 1712 Every administrative record consists of: 1714 . Record type code (an unsigned integer for which valid values 1715 are as defined below). 1716 . Record content in type-specific format. 1718 Valid administrative record type codes are defined as follows: 1720 +---------+--------------------------------------------+ 1722 | Value | Meaning | 1724 +=========+============================================+ 1726 | 1 | Bundle status report. | 1728 +---------+--------------------------------------------+ 1730 | 2 | Custody signal. | 1732 +---------+--------------------------------------------+ 1733 | (other) | Reserved for future use. | 1735 +---------+--------------------------------------------+ 1737 Figure 3: Administrative Record Type Codes 1739 Each BP administrative record SHALL be represented as a CBOR array 1740 comprising a 2-tuple. 1742 The first item of the array SHALL be a record type code, which SHALL 1743 be represented as a CBOR unsigned integer. 1745 The second element of this array SHALL be the applicable CBOR 1746 representation of the content of the record. Details of the CBOR 1747 representation of administrative record types 1 and 2 are provided 1748 below. Details of the CBOR representation of other types of 1749 administrative record type are included in the specifications 1750 defining those records. 1752 6.1.1. Bundle Status Reports 1754 The transmission of "bundle status reports" under specified 1755 conditions is an option that can be invoked when transmission of a 1756 bundle is requested. These reports are intended to provide 1757 information about how bundles are progressing through the system, 1758 including notices of receipt, custody transfer, forwarding, final 1759 delivery, and deletion. They are transmitted to the Report-to 1760 endpoints of bundles. 1762 Each bundle status report SHALL be represented as a CBOR array. The 1763 number of elements in the array SHALL be either 6 (if the subject 1764 bundle is a fragment) or 4 (otherwise). 1766 The first item of the bundle status report array SHALL be bundle 1767 status information represented as a CBOR array of 5 elements. The 1768 five items of the bundle status information array shall provide 1769 information on the following five status assertions, in this order: 1771 . Reporting node received bundle. 1772 . Reporting node attempted custody transfer. When this status is 1773 asserted, a reason code value of 0 ("No additional 1774 information") SHALL indicate that custody was accepted. 1775 . Reporting node forwarded the bundle. 1776 . Reporting node delivered the bundle. 1777 . Reporting node deleted the bundle. 1779 Each item of the bundle status information array SHALL be a bundle 1780 status item represented as a CBOR array; the number of elements in 1781 each such array SHALL be either 2 (if the value of the first item of 1782 this bundle status item is 1 AND the "Report status time" flag was 1783 set to 1 in the bundle processing flags of the bundle whose status 1784 is being reported) or 1 (otherwise). The first item of the bundle 1785 status item array SHALL be a status indicator, a Boolean value 1786 indicating whether or not the corresponding bundle status is 1787 asserted, represented as a CBOR Boolean value. The second item of 1788 the bundle status item array, if present, SHALL indicate the time 1789 (as reported by the local system clock, an implementation matter) at 1790 which the indicated status was asserted for this bundle, represented 1791 as a DTN time as described in Section 4.1.6. above. 1793 The second item of the bundle status report array SHALL be the 1794 bundle status report reason code explaining the value of the status 1795 indicator, represented as a CBOR unsigned integer. Valid status 1796 report reason codes are defined in Figure 4 below but the list of 1797 status report reason codes provided here is neither exhaustive nor 1798 exclusive; supplementary DTN protocol specifications (including, but 1799 not restricted to, the Bundle Security Protocol [BPSEC]) may define 1800 additional reason codes. 1802 +---------+--------------------------------------------+ 1804 | Value | Meaning | 1806 +=========+============================================+ 1808 | 0 | No additional information. | 1810 +---------+--------------------------------------------+ 1812 | 1 | Lifetime expired. | 1814 +---------+--------------------------------------------+ 1816 | 2 | Forwarded over unidirectional link. | 1818 +---------+--------------------------------------------+ 1820 | 3 | Transmission canceled. | 1822 +---------+--------------------------------------------+ 1824 | 4 | Depleted storage. | 1825 +---------+--------------------------------------------+ 1827 | 5 | Destination endpoint ID unintelligible. | 1829 +---------+--------------------------------------------+ 1831 | 6 | No known route to destination from here. | 1833 +---------+--------------------------------------------+ 1835 | 7 | No timely contact with next node on route. | 1837 +---------+--------------------------------------------+ 1839 | 8 | Block unintelligible. | 1841 +---------+--------------------------------------------+ 1843 | (other) | Reserved for future use. | 1845 +---------+--------------------------------------------+ 1847 Figure 4: Status Report Reason Codes 1849 The third item of the bundle status report array SHALL be the source 1850 node ID identifying the source of the bundle whose status is being 1851 reported, represented as described in Section 4.1.5.2. above. 1853 The fourth item of the bundle status report array SHALL be the 1854 creation timestamp of the bundle whose status is being reported, 1855 represented as described in Section 4.1.7. above. 1857 The fifth item of the bundle status report array SHALL be present if 1858 and only if the bundle whose status is being reported contained a 1859 fragment offset. If present, it SHALL be the subject bundle's 1860 fragment offset represented as a CBOR unsigned integer item. 1862 The sixth item of the bundle status report array SHALL be present if 1863 and only if the bundle whose status is being reported contained a 1864 fragment offset. If present, it SHALL be the length of the subject 1865 bundle's payload represented as a CBOR unsigned integer item. 1867 6.1.2. Custody Signals 1869 Custody signals are administrative records that effect custody 1870 transfer operations. They are transmitted to the nodes that are the 1871 current custodians of bundles. 1873 Each custody signal SHALL be represented as a CBOR array. The number 1874 of elements in the array SHALL be 6 (if the subject bundle is a 1875 fragment) or 4 (otherwise). 1877 The first item of the custody signal array SHALL be a signal type 1878 code represented as a CBOR unsigned integer. Valid custody signal 1879 types are defined as follows: 1881 +---------+--------------------------------------------+ 1883 | Value | Meaning | 1885 +=========+============================================+ 1887 | 0 | Custody acceptance. The reporting node | 1889 | | accepted custody of the bundle. | 1891 +---------+--------------------------------------------+ 1893 | 1 | Custody refusal. The reporting node | 1895 | | refused custody of the bundle. | 1897 +---------+--------------------------------------------+ 1899 | 2 | Custody delegation: the bundle will be | 1901 | | forwarded but custody was not taken. | 1903 +---------+--------------------------------------------+ 1905 | (other) | Reserved for future use. | 1907 +---------+--------------------------------------------+ 1909 Figure 5: Custody Signal Type Codes 1911 The second item of the custody signal array SHALL be additional 1912 information amplifying the signal type code, represented as a CBOR 1913 array. The number of elements in the array SHALL be either 2 (if 1914 the signal type is 2) or 1 (otherwise). 1916 When signal type is 0 or 1, the sole item in the additional 1917 information array SHALL be a custody signal reason code, represented 1918 as a CBOR unsigned integer. Valid custody signal reason codes are 1919 defined as follows: 1921 +---------+--------------------------------------------+ 1923 | Value | Meaning | 1925 +=========+============================================+ 1927 | 0 | No additional information. | 1929 +---------+--------------------------------------------+ 1931 | 1 | Reserved for future use. | 1933 +---------+--------------------------------------------+ 1935 | 2 | Reserved for future use. | 1937 +---------+--------------------------------------------+ 1939 | 3 | Redundant (reception by a node that is a | 1941 | | custodial node for this bundle). | 1943 +---------+--------------------------------------------+ 1945 | 4 | Depleted storage. | 1947 +---------+--------------------------------------------+ 1949 | 5 | Destination endpoint ID unintelligible. | 1951 +---------+--------------------------------------------+ 1953 | 6 | No known route destination from here. | 1955 +---------+--------------------------------------------+ 1957 | 7 | No timely contact with next node on route. | 1959 +---------+--------------------------------------------+ 1961 | 8 | Block unintelligible. | 1963 +---------+--------------------------------------------+ 1965 | (other) | Reserved for future use. | 1967 +---------+--------------------------------------------+ 1968 Figure 6: Custody Signal Reason Codes 1970 When signal type is 2, the first item in the additional information 1971 array SHALL be the node ID of the node to which the reporting node 1972 anticipates forwarding the bundle, represented as described in 1973 Section 4.1.5.2. above, and the second item in this array SHALL be 1974 an estimate of the number of seconds that will have elapsed since 1975 reception of the bundle before the anticipated forwarding begins, 1976 represented as a CBOR unsigned integer. 1978 The third item of the custody signal array SHALL be the source node 1979 ID identifying the source of the bundle for which custodial activity 1980 is being reported, represented as described in Section 4.1.5.2. 1981 above. 1983 The fourth item of the custody signal array SHALL be the creation 1984 timestamp of the bundle for which custodial activity is being 1985 reported, represented as described in Section 4.1.7. above. 1987 The fifth item of the custody signal array SHALL be present if and 1988 only if the bundle for which custodial activity is being reported 1989 contained a fragment offset. If present, it SHALL be the subject 1990 bundle's fragment offset represented as a CBOR unsigned integer 1991 item. 1993 The sixth item of the custody signal array SHALL be present if and 1994 only if the bundle for which custodial activity is being reported 1995 contained a fragment offset. If present, it SHALL be the length of 1996 the subject bundle's payload represented as a CBOR unsigned integer 1997 item. 1999 6.2. Generation of Administrative Records 2001 Whenever the application agent's administrative element is directed 2002 by the bundle protocol agent to generate an administrative record 2003 with reference to some bundle, the following procedure must be 2004 followed: 2006 Step 1: The administrative record must be constructed. If the 2007 referenced bundle is a fragment, the administrative record MUST 2008 contain the fragment offset and fragment length. 2010 Step 2: A request for transmission of a bundle whose payload is this 2011 administrative record MUST be presented to the bundle protocol 2012 agent. 2014 6.3. Reception of Custody Signals 2016 For each received custody signal that has signal type zero (custody 2017 acceptance), the administrative element of the application agent 2018 MUST direct the bundle protocol agent to follow the custody transfer 2019 success procedure in Section 5.11. 2021 For each received custody signal that has signal type 1 (custody 2022 refusal), the administrative element of the application agent MUST 2023 direct the bundle protocol agent to follow the custody transfer 2024 failure procedure in Section 5.12. 2026 For each received custody signal that has signal type 2 (custody 2027 delegation), the administrative element of the application agent 2028 MUST direct the bundle protocol agent to follow the custody 2029 delegation procedure in Section 5.13. 2031 7. Services Required of the Convergence Layer 2033 7.1. The Convergence Layer 2035 The successful operation of the end-to-end bundle protocol depends 2036 on the operation of underlying protocols at what is termed the 2037 "convergence layer"; these protocols accomplish communication 2038 between nodes. A wide variety of protocols may serve this purpose, 2039 so long as each convergence layer protocol adapter provides a 2040 defined minimal set of services to the bundle protocol agent. This 2041 convergence layer service specification enumerates those services. 2043 7.2. Summary of Convergence Layer Services 2045 Each convergence layer protocol adapter is expected to provide the 2046 following services to the bundle protocol agent: 2048 . sending a bundle to a bundle node that is reachable via the 2049 convergence layer protocol; 2050 . delivering to the bundle protocol agent a bundle that was sent 2051 by a bundle node via the convergence layer protocol. 2053 The convergence layer service interface specified here is neither 2054 exhaustive nor exclusive. That is, supplementary DTN protocol 2055 specifications (including, but not restricted to, the Bundle 2056 Security Protocol [BPSEC]) may expect convergence layer adapters 2057 that serve BP implementations conforming to those protocols to 2058 provide additional services such as reporting on the transmission 2059 and/or reception progress of individual bundles (at completion 2060 and/or incrementally), retransmitting data that were lost in 2061 transit, discarding bundle-conveying data units that the convergence 2062 layer protocol determines are corrupt or inauthentic, or reporting 2063 on the integrity and/or authenticity of delivered bundles. 2065 8. Security Considerations 2067 The bundle protocol has taken security into concern from the outset 2068 of its design. It was always assumed that security services would be 2069 needed in the use of the bundle protocol. As a result, the bundle 2070 protocol security architecture and the available security services 2071 are specified in an accompanying document, the Bundle Security 2072 Protocol specification [BPSEC]; an informative overview of this 2073 architecture is provided in [SECO]. 2075 The bundle protocol has been designed with the notion that it may be 2076 run over networks with scarce resources. For example, the networks 2077 might have limited bandwidth, limited connectivity, constrained 2078 storage in relay nodes, etc. Therefore, the bundle protocol must 2079 ensure that only those entities authorized to send bundles over such 2080 constrained environments are actually allowed to do so. All 2081 unauthorized entities should be prevented from consuming valuable 2082 resources as soon as practicable. 2084 Likewise, because of the potentially high latencies and delays 2085 involved in the networks that make use of the bundle protocol, data 2086 sources should be concerned with the integrity of the data received 2087 at the intended destination(s) and may also be concerned with 2088 ensuring confidentiality of the data as it traverses the network. 2089 Without integrity, the bundle payload data might be corrupted while 2090 in transit without the destination able to detect it. Similarly, the 2091 data source can be concerned with ensuring that the data can only be 2092 used by those authorized, hence the need for confidentiality. 2094 Internal to the bundle-aware overlay network, the bundle nodes 2095 should be concerned with the authenticity of other bundle nodes as 2096 well as the preservation of bundle payload data integrity as it is 2097 forwarded between bundle nodes. 2099 As a result, bundle security is concerned with the authenticity, 2100 integrity, and confidentiality of bundles conveyed among bundle 2101 nodes. This is accomplished via the use of two independent security- 2102 specific bundle blocks, which may be used together to provide 2103 multiple bundle security services or independently of one another, 2104 depending on perceived security threats, mandated security 2105 requirements, and security policies that must be enforced. 2107 To provide end-to-end bundle authenticity and integrity, the Block 2108 Integrity Block (BIB) is used. The BIB allows any security-enabled 2109 entity along the delivery path to ensure the integrity of the 2110 bundle's payload or any other block other than a Block 2111 Confidentiality Block. 2113 To provide payload confidentiality, the use of the Block 2114 Confidentiality Block (BCB) is available. The bundle payload, or any 2115 other block aside from the primary block and the Bundle Security 2116 Protocol blocks, may be encrypted to provide end-to-end payload 2117 confidentiality/privacy. 2119 Additionally, convergence-layer protocols that ensure authenticity 2120 of communication between adjacent nodes in BP network topology 2121 SHOULD be used where available, to minimize the ability of 2122 unauthenticated nodes to introduce inauthentic traffic into the 2123 network. 2125 Bundle security MUST NOT be invalidated by forwarding nodes even 2126 though they themselves might not use the Bundle Security Protocol. 2128 In particular, while blocks MAY be added to bundles transiting 2129 intermediate nodes, removal of blocks with the 'Discard block if it 2130 can't be processed' flag set in the block processing control flags 2131 may cause security to fail. 2133 Inclusion of the Bundle Security Protocol in any Bundle Protocol 2134 implementation is RECOMMENDED. Use of the Bundle Security Protocol 2135 in Bundle Protocol operations is OPTIONAL. 2137 9. IANA Considerations 2139 The "dtn" and "ipn" URI schemes have been provisionally registered 2140 by IANA. See http://www.iana.org/assignments/uri-schemes.html for 2141 the latest details. 2143 Registries of URI scheme type numbers, extension block type numbers, 2144 and administrative record type numbers will be required. 2146 10. References 2148 10.1. Normative References 2150 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2151 Requirement Levels", BCP 14, RFC 2119, March 1997. 2153 [RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object 2154 Representation (CBOR)", RFC 7049, October 2013. 2156 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2157 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 2158 January 2005. 2160 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2161 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 2162 2015. 2164 10.2. Informative References 2166 [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 2167 4838, April 2007. 2169 [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work 2170 In Progress, October 2015. 2172 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 2173 Identifiers (IRIs)", RFC 3987, January 2005. 2175 [RFC5050] Scott, M. and S. Burleigh, "Bundle Protocol 2176 Specification", RFC 5050, November 2007. 2178 [SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay- 2179 Tolerant Networking Security Overview", Work Progress, July 2007. 2181 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 2182 Challenged Internets", SIGCOMM 2003. 2184 [TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A Tutorial", 2185 . 2187 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 2188 historical background and perspectives" in "Journees systemes de 2189 reference spatio-temporels", 2004. 2191 11. Acknowledgments 2193 This work is freely adapted from [RFC5050], which was an effort of 2194 the Delay Tolerant Networking Research Group. The following DTNRG 2195 participants contributed significant technical material and/or 2196 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 2197 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 2198 Michael Demmer of the University of California at Berkeley, Robert 2199 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 2200 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 2201 College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of 2202 Ohio University, and Howard Weiss of SPARTA, Inc. 2204 This document was prepared using 2-Word-v2.0.template.dot. 2206 12. Significant Changes from RFC 5050 2208 Points on which this draft significantly differs from RFC 5050 2209 include the following: 2211 . Clarify the difference between transmission and forwarding. 2212 . Amplify discussion of custody transfer. Move current custodian 2213 to an extension block, of which there can be multiple 2214 occurrences (possible support for the MITRE idea of multiple 2215 concurrent custodians, from several years ago); define that 2216 block in this specification. 2217 . Introduce the concept of "node ID" as functionally distinct 2218 from endpoint ID, while having the same syntax. 2219 . Restructure primary block, making it immutable. Add optional 2220 CRC. 2221 . Add optional CRCs to non-primary blocks. 2222 . Add block ID number to canonical block format (to support 2223 streamlined BSP). 2224 . Add bundle age extension block, defined in this specification. 2225 . Add previous node extension block, defined in this 2226 specification. 2227 . Add flow label extension block, *not* defined in this 2228 specification. 2229 . Add manifest extension block, *not* defined in this 2230 specification. 2231 . Add hop count extension block, defined in this specification. 2232 . Clean up a conflict between fragmentation and custody transfer 2233 that Ed Birrane pointed out. 2235 Appendix A. For More Information 2237 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 2238 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 2240 Copyright (c) 2016 IETF Trust and the persons identified as authors 2241 of the code. All rights reserved. 2243 Redistribution and use in source and binary forms, with or without 2244 modification, is permitted pursuant to, and subject to the license 2245 terms contained in, the Simplified BSD License set forth in Section 2246 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2247 (http://trustee.ietf.org/license-info). 2249 Appendix B. CDDL expression 2251 For informational purposes, Carsten Bormann has kindly provided an 2252 expression of the Bundle Protocol specification in the CBOR Data 2253 Definition Language (CDDL). That CDDL expression is presented 2254 below, somewhat edited by the authors. Note that wherever the CDDL 2255 expression is in disagreement with the textual representation of the 2256 BP specification presented in the earlier sections of this document, 2257 the textual representation rules. 2259 start = bundle 2261 dtn-time = uint 2263 creation-timestamp = [dtn-time, sequence: uint] 2265 eid-generic = [uri-code, SSP: any] 2267 uri-code = uint 2269 eid = eid-choice .within eid-generic 2271 eid-choice /= [dtn-code, SSP: bytes] 2273 dtn-code = 1 ; TBD 2275 eid-choice /= [ipn-code, SSP: [nodenum: uint, servicenum: uint]] 2277 ipn-code = 2 ; TBD 2279 bundle-control-flags = uint .bits bundleflagbits 2281 bundleflagbits = &( 2283 reserved: 15 2285 reserved: 14 2287 reserved: 13 2289 bundle-deletion-status-reports-are-requested: 12 2291 bundle-delivery-status-reports-are-requested: 11 2293 bundle-forwarding-status-reports-are-requested: 10 2295 custody-transfer-status-reports-are-requested: 9 2296 bundle-reception-status-reports-are-requested: 8 2298 bundle-contains-a-Manifest-block: 7 2300 status-time-is-requested-in-all-status-reports: 6 2302 user-application-acknowledgement-is-requested: 5 2304 destination-is-a-singleton-endpoint: 4 2306 custody-transfer-is-requested: 3 2308 bundle-must-not-be-fragmented: 2 2310 payload-is-an-administrative-record: 1 2312 bundle-is-a-fragment: 0 2314 ) 2316 crc = uint 2318 block-control-flags = uint .bits blockflagbits 2320 blockflagbits = &( 2322 reserved: 7 2324 reserved: 6 2326 reserved: 5 2328 reserved: 4 2330 bundle-must-be-deleted-if-block-cannot-be-processed: 3 2332 status-report-must-be-transmitted-if-block-cannot-be-processed: 2 2334 block-must-be-removed-from-bundle-if-it-cannot-be-processed: 1 2336 block-must-be-replicated-in-every-fragment: 0 2338 ) 2340 bundle = [primary-block, *extension-block, payload-block] 2342 primary-block = [ 2343 version: 7, 2345 bundle-control-flags, 2347 crc-type: uint, 2349 destination: eid, 2351 source-node: eid, 2353 report-to: eid, 2355 creation-timestamp, 2357 lifetime: uint, 2359 ? fragment-offset: uint, 2361 ? total-application-data-length: uint, 2363 ? crc, 2365 ] 2367 canonical-block-generic = [ 2369 block-type-code: uint, 2371 canonical-block-common, 2373 content: any 2375 ] 2377 canonical-block-common = ( 2379 block-number: uint, 2381 block-control-flags, 2383 crc-type: uint, 2385 ? crc, 2387 ) 2389 canonical-block = canonical-block-choice .within canonical-block- 2390 generic 2392 canonical-block-choice /= payload-block 2394 payload-block = [1, canonical-block-common, adu-extent: payload] 2396 payload = bytes / bytes .cbor admin-record 2398 canonical-block-choice /= extension-block 2400 extension-block = extension-block-choice .within canonical-block 2402 extension-block-choice /= current-custodian-block 2404 current-custodian-block = [5, canonical-block-common, eid] 2406 extension-block-choice /= previous-node-block 2408 previous-node-block = [7, canonical-block-common, eid] 2410 extension-block-choice /= bundle-age-block 2412 bundle-age-block = [8, canonical-block-common, bundle-age: uint] 2414 extension-block-choice /= hop-count-block 2416 hop-count-block = [9, canonical-block-common, 2418 [hop-limit: uint, 2420 hop-count: uint]] 2422 admin-record-generic = [record-type: uint, any] 2424 admin-record = admin-record-choice .within admin-record-generic 2426 admin-record-choice /= bundle-status-report 2428 bundle-status-report = [1, [bundle-status-information, 2430 bundle-status-reason: uint, 2432 admin-common]] 2434 admin-common = ( 2435 source-node: eid, 2437 creation-timestamp, 2439 ? fragment-offset: uint, 2441 ? payload-length: uint) 2443 bundle-status-information = [ 2445 reporting-node-received-bundle: bundle-status-item, 2447 reporting-node-attempted-custody-transfer: bundle-status-item, 2449 reporting-node-forwarded-the-bundle: bundle-status-item, 2451 reporting-node-delivered-the-bundle: bundle-status-item, 2453 reporting-node-deleted-the-bundle: bundle-status-item, 2455 ] 2457 bundle-status-item = ( 2459 asserted: Boolean, 2461 ? time-of-assertion: dtn-time) 2463 admin-record-choice /= custody-signal 2465 custody-signal = [2, [custody-signal-type-code: uint, 2467 custody-signal-information, 2469 admin-common]] 2471 custody-signal-information = custody-reason-code: uint / delegation- 2472 information 2474 delegation-information = ( 2476 next-hop-node: eid, 2478 seconds-until-forwarding: uint) 2480 Authors' Addresses 2482 Scott Burleigh 2483 Jet Propulsion Laboratory, California Institute of Technology 2484 4800 Oak Grove Dr. 2485 Pasadena, CA 91109-8099 2486 US 2487 Phone: +1 818 393 3353 2488 Email: Scott.Burleigh@jpl.nasa.gov 2490 Kevin Fall 2491 Carnegie Mellon University / Software Engineering Institute 2492 4500 Fifth Avenue 2493 Pittsburgh, PA 15213 2494 US 2495 Phone: +1 412 268 3304 2496 Email: kfall@cmu.edu 2498 Edward J. Birrane 2499 Johns Hopkins University Applied Physics Laboratory 2500 11100 Johns Hopkins Rd 2501 Laurel, MD 20723 2502 US 2503 Phone: +1 443 778 7423 2504 Email: Edward.Birrane@jhuapl.edu