idnits 2.17.1 draft-ietf-dtn-bpbis-05.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 (September 7, 2016) is 2789 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: March 2017 Carnegie Mellon University / SEI 5 E. Birrane 6 APL, Johns Hopkins University 7 September 7, 2016 9 Bundle Protocol 10 draft-ietf-dtn-bpbis-05.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 March 11, 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...............15 65 4. Bundle Format.................................................15 66 4.1. BP Fundamental Data Structures...........................15 67 4.1.1. CRC Type............................................15 68 4.1.2. CRC.................................................16 69 4.1.3. Bundle Processing Control Flags.....................16 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........................................20 74 4.1.6. DTN Time............................................20 75 4.1.7. Creation Timestamp..................................20 76 4.1.8. Fragment ID.........................................20 77 4.1.9. Block-type-specific Data............................21 78 4.2. Bundle Representation....................................21 79 4.2.1. Bundle..............................................21 80 4.2.2. Primary Bundle Block................................21 81 4.2.3. Canonical Bundle Block Format.......................24 82 4.3. Extension Blocks.........................................26 83 4.3.1. Current Custodian...................................26 84 4.3.2. Previous Node.......................................27 85 4.3.3. Bundle Age..........................................27 86 4.3.4. Hop Count...........................................27 87 5. Bundle Processing.............................................28 88 5.1. Generation of Administrative Records.....................28 89 5.2. Bundle Transmission......................................29 90 5.3. Bundle Dispatching.......................................29 91 5.4. Bundle Forwarding........................................30 92 5.4.1. Forwarding Contraindicated..........................31 93 5.4.2. Forwarding Failed...................................32 94 5.5. Bundle Expiration........................................32 95 5.6. Bundle Reception.........................................33 96 5.7. Local Bundle Delivery....................................34 97 5.8. Bundle Fragmentation.....................................35 98 5.9. Application Data Unit Reassembly.........................36 99 5.10. Custody Transfer........................................37 100 5.10.1. Custody Acceptance.................................37 101 5.10.2. Custody Release....................................38 102 5.11. Custody Transfer Success................................38 103 5.12. Custody Transfer Failure................................38 104 5.13. Custody Transfer Deferral...............................38 105 5.14. Bundle Deletion.........................................39 106 5.15. Discarding a Bundle.....................................39 107 5.16. Canceling a Transmission................................39 108 6. Administrative Record Processing..............................40 109 6.1. Administrative Records...................................40 110 6.1.1. Bundle Status Reports...............................41 111 6.1.2. Custody Signals.....................................43 112 6.2. Generation of Administrative Records.....................46 113 6.3. Reception of Custody Signals.............................46 114 7. Services Required of the Convergence Layer....................47 115 7.1. The Convergence Layer....................................47 116 7.2. Summary of Convergence Layer Services....................47 117 8. Security Considerations.......................................48 118 9. IANA Considerations...........................................49 119 10. References...................................................49 120 10.1. Normative References....................................49 121 10.2. Informative References..................................50 122 11. Acknowledgments..............................................50 123 12. Significant Changes from RFC 5050............................51 124 Appendix A. For More Information.................................52 126 1. Introduction 128 Since the publication of the Bundle Protocol Specification 129 (Experimental RFC 5050[RFC5050]) in 2007, the Delay-Tolerant 130 Networking Bundle Protocol has been implemented in multiple 131 programming languages and deployed to a wide variety of computing 132 platforms for a wide range of successful exercises. This 133 implementation and deployment experience has demonstrated the 134 general utility of the protocol for challenged network operations. 136 It has also, as expected, identified opportunities for making the 137 protocol simpler, more capable, and easier to use. The present 138 document, standardizing the Bundle Protocol (BP), is adapted from 139 RFC 5050 in that context. 141 This document describes version 7 of BP. 143 Delay Tolerant Networking is a network architecture providing 144 communications in and/or through highly stressed environments. 145 Stressed networking environments include those with intermittent 146 connectivity, large and/or variable delays, and high bit error 147 rates. To provide its services, BP may be viewed as sitting at the 148 application layer of some number of constituent networks, forming a 149 store-carry-forward overlay network. Key capabilities of BP 150 include: 152 . Custodial forwarding 153 . Ability to cope with intermittent connectivity, including cases 154 where the sender and receiver are not concurrently present in 155 the network 156 . Ability to take advantage of scheduled, predicted, and 157 opportunistic connectivity, whether bidirectional or 158 unidirectional, in addition to continuous connectivity 159 . Late binding of overlay network endpoint identifiers to 160 underlying constituent network addresses 162 For descriptions of these capabilities and the rationale for the DTN 163 architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial- 164 level overview of DTN concepts. 166 BP's location within the standard protocol stack is as shown in 167 Figure 1. BP uses underlying "native" transport and/or network 168 protocols for communications within a given constituent network. 170 The interface between the bundle protocol and a specific underlying 171 protocol is termed a "convergence layer adapter". 173 Figure 1 shows three distinct transport and network protocols 174 (denoted T1/N1, T2/N2, and T3/N3). 176 +-----------+ +-----------+ 177 | BP app | | BP app | 178 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 179 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 180 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 181 | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | 182 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 183 | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | 184 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 185 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 186 +-----------+ +-------------+ +-------------+ +-----------+ 187 | | | | 188 |<---- A network ---->| |<---- A network ---->| 189 | | | | 191 Figure 1: The Bundle Protocol in the Protocol Stack Model 193 This document describes the format of the protocol data units 194 (called "bundles") passed between entities participating in BP 195 communications. 197 The entities are referred to as "bundle nodes". This document does 198 not address: 200 . Operations in the convergence layer adapters that bundle nodes 201 use to transport data through specific types of internets. 202 (However, the document does discuss the services that must be 203 provided by each adapter at the convergence layer.) 204 . The bundle route computation algorithm. 205 . Mechanisms for populating the routing or forwarding information 206 bases of bundle nodes. 207 . The mechanisms for securing bundles en route. 208 . The mechanisms for managing bundle nodes. 210 2. Conventions used in this document 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 214 document are to be interpreted as described in RFC-2119 [RFC2119]. 216 In this document, these words will appear with that interpretation 217 only when in ALL CAPS. Lower case uses of these words are not to be 218 interpreted as carrying RFC-2119 significance. 220 3. Service Description 222 3.1. Definitions 224 Bundle - A bundle is a protocol data unit of BP, so named because 225 negotiation of the parameters of a data exchange may be impractical 226 in a delay-tolerant network: it is often better practice to "bundle" 227 with a unit of data all metadata that might be needed in order to 228 make the data immediately usable when delivered to applications. 229 Each bundle comprises a sequence of two or more "blocks" of protocol 230 data, which serve various purposes. 232 Block - A bundle protocol block is one of the protocol data 233 structures that together constitute a well-formed bundle. 235 Bundle payload - A bundle payload (or simply "payload") is the 236 application data whose conveyance to the bundle's destination is the 237 purpose for the transmission of a given bundle; it is the content of 238 the bundle's payload block. The terms "bundle content", "bundle 239 payload", and "payload" are used interchangeably in this document. 241 Partial payload - A partial payload is a payload that comprises 242 either the first N bytes or the last N bytes of some other payload 243 of length M, such that 0 < N < M. 245 Fragment - A fragment is a bundle whose payload block contains a 246 partial payload. 248 Bundle node - A bundle node (or, in the context of this document, 249 simply a "node") is any entity that can send and/or receive bundles. 250 Each bundle node has three conceptual components, defined below, as 251 shown in Figure 2: a "bundle protocol agent", a set of zero or more 252 "convergence layer adapters", and an "application agent". 254 +-----------------------------------------------------------+ 255 |Node | 256 | | 257 | +-------------------------------------------------------+ | 258 | |Application Agent | | 259 | | | | 260 | | +--------------------------+ +----------------------+ | | 261 | | |Administrative element | |Application-specific | | | 262 | | | | |element | | | 263 | | | | | | | | 264 | | +--------------------------+ +----------------------+ | | 265 | | ^ ^ | | 266 | | Admin|records Application|data | | 267 | | | | | | 268 | +----------------v--------------------------v-----------+ | 269 | ^ | 270 | | ADUs | 271 | | | 272 | +-----------------------------v-------------------------+ | 273 | |Bundle Protocol Agent | | 274 | | | | 275 | | | | 276 | +-------------------------------------------------------+ | 277 | ^ ^ ^ | 278 | | Bundles | Bundles Bundles | | 279 | | | | | 280 | +------v-----+ +-----v------+ +-----v-----+ | 281 | |CLA 1 | |CLA 2 | |CLA n | | 282 | | | | | . . . | | | 283 | | | | | | | | 284 +-+------------+-----+------------+-----------+-----------+-+ 285 ^ ^ ^ 286 CL1|PDUs CL2|PDUs CLn|PDUs 287 | | | 288 +------v-----+ +-----v------+ +-----v-----+ 289 Network 1 Network 2 Network n 291 Figure 2: Components of a BP Node 293 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 294 the node component that offers the BP services and executes the 295 procedures of the bundle protocol. 297 Convergence layer adapter - A convergence layer adapter (CLA) is a 298 node component that sends and receives bundles on behalf of the BPA, 299 utilizing the services of some 'native' protocol stack that is 300 supported in one of the networks within which the node is 301 functionally located. 303 Application agent - The application agent (AA) of a node is the node 304 component that utilizes the BP services to effect communication for 305 some user purpose. The application agent in turn has two elements, 306 an administrative element and an application-specific element. 308 Application-specific element - The application-specific element of 309 an AA is the node component that constructs, requests transmission 310 of, accepts delivery of, and processes units of user application 311 data. 313 Administrative element - The administrative element of an AA is the 314 node component that constructs and requests transmission of 315 administrative records (defined below), including status reports and 316 custody signals, and accepts delivery of and processes any custody 317 signals that the node receives. 319 Administrative record - A BP administrative record is an application 320 data unit that is exchanged between the administrative elements of 321 nodes' application agents for some BP administrative purpose. The 322 formats of some fundamental administrative records (and of no other 323 application data units) are defined in this specification. 325 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 326 of zero or more bundle nodes that all identify themselves for BP 327 purposes by some common identifier, called a "bundle endpoint ID" 328 (or, in this document, simply "endpoint ID"; endpoint IDs are 329 described in detail in Section 4.4.1 below). 331 Singleton endpoint - A singleton endpoint is an endpoint that always 332 contains exactly one member. 334 Registration - A registration is the state machine characterizing a 335 given node's membership in a given endpoint. Any single 336 registration has an associated delivery failure action as defined 337 below and must at any time be in one of two states: Active or 338 Passive. 340 Delivery - A bundle is considered to have been delivered at a node 341 subject to a registration as soon as the application data unit that 342 is the payload of the bundle, together with any relevant metadata 343 (an implementation matter), has been presented to the node's 344 application agent in a manner consistent with the state of that 345 registration. 347 Deliverability - A bundle is considered "deliverable" subject to a 348 registration if and only if (a) the bundle's destination endpoint is 349 the endpoint with which the registration is associated, (b) the 350 bundle has not yet been delivered subject to this registration, and 351 (c) the bundle has not yet been "abandoned" (as defined below) 352 subject to this registration. 354 Abandonment - To abandon a bundle subject to some registration is to 355 assert that the bundle is not deliverable subject to that 356 registration. 358 Delivery failure action - The delivery failure action of a 359 registration is the action that is to be taken when a bundle that is 360 "deliverable" subject to that registration is received at a time 361 when the registration is in the Passive state. 363 Destination - The destination of a bundle is the endpoint comprising 364 the node(s) at which the bundle is to be delivered (as defined 365 below). 367 Minimum reception group - The minimum reception group of an endpoint 368 is the minimum number of members of the endpoint (nodes) at which 369 the bundle must have been delivered in order for the bundle to be 370 considered delivered to the endpoint. 372 Transmission - A transmission is an attempt by a node's BPA to cause 373 copies of a bundle to be delivered at all nodes in the minimum 374 reception group of some endpoint (the bundle's destination) in 375 response to a transmission request issued by the node's application 376 agent. 378 Forwarding - To forward a bundle to a node is to invoke the services 379 of a CLA in a sustained effort to cause a copy of the bundle to be 380 received by that node. 382 Discarding - To discard a bundle is to cease all operations on the 383 bundle and functionally erase all references to it. The specific 384 procedures by which this is accomplished are an implementation 385 matter. 387 Retention constraint - A retention constraint is an element of the 388 state of a bundle that prevents the bundle from being discarded. 389 That is, a bundle cannot be discarded while it has any retention 390 constraints. 392 Deletion - To delete a bundle is to remove unconditionally all of 393 the bundle's retention constraints, enabling the bundle to be 394 discarded. 396 Custodian - A custodian of a bundle is a node that has determined 397 that it will retain a copy of that bundle for an indefinite period 398 of time, forwarding and possibly re-forwarding the bundle as 399 appropriate, until it detects one of the conditions under which it 400 may cease being a custodian of that bundle (discussed later). 402 Taking custody - To take custody of a bundle is to become a 403 custodian of that bundle. 405 Accepting custody - To accept custody of a bundle is to take custody 406 of the bundle, mark the bundle in such a way as to indicate this 407 custodianship to nodes that subsequently receive copies of the 408 bundle, and announce this custodianship to all current custodians of 409 the bundle. 411 Refusing custody - To "refuse custody" of a bundle is to notify all 412 current custodians of that bundle that an opportunity to take 413 custody of the bundle has been declined. 415 Releasing custody - To release custody of a bundle is to cease to be 416 a custodian of the bundle. 418 3.2. Discussion of BP concepts 420 Multiple instances of the same bundle (the same unit of DTN protocol 421 data) might exist concurrently in different parts of a network -- 422 possibly differing in some blocks -- in the memory local to one or 423 more bundle nodes and/or in transit between nodes. In the context of 424 the operation of a bundle node, a bundle is an instance (copy), in 425 that node's local memory, of some bundle that is in the network. 427 The payload for a bundle forwarded in response to a bundle 428 transmission request is the application data unit whose location is 429 provided as a parameter to that request. The payload for a bundle 430 forwarded in response to reception of a bundle is the payload of the 431 received bundle. 433 In the most familiar case, a bundle node is instantiated as a single 434 process running on a general-purpose computer, but in general the 435 definition is meant to be broader: a bundle node might alternatively 436 be a thread, an object in an object-oriented operating system, a 437 special-purpose hardware device, etc. 439 The manner in which the functions of the BPA are performed is wholly 440 an implementation matter. For example, BPA functionality might be 441 coded into each node individually; it might be implemented as a 442 shared library that is used in common by any number of bundle nodes 443 on a single computer; it might be implemented as a daemon whose 444 services are invoked via inter-process or network communication by 445 any number of bundle nodes on one or more computers; it might be 446 implemented in hardware. 448 Every CLA implements its own thin layer of protocol, interposed 449 between BP and the (usually "top") protocol(s) of the underlying 450 native protocol stack; this "CL protocol" may only serve to 451 multiplex and de-multiplex bundles to and from the underlying native 452 protocol, or it may offer additional CL-specific functionality. The 453 manner in which a CLA sends and receives bundles is, again, wholly 454 an implementation matter. The definitions of CLAs and CL protocols 455 are beyond the scope of this specification. 457 Note that the administrative element of a node's application agent 458 may itself, in some cases, function as a convergence-layer adapter. 459 That is, outgoing bundles may be "tunneled" through encapsulating 460 bundles: 462 . An outgoing bundle constitutes a byte array. This byte array 463 may, like any other, be presented to the bundle protocol agent 464 as an application data unit that is to be transmitted to some 465 endpoint. 466 . The original bundle thus forms the payload of an encapsulating 467 bundle that is forwarded using some other convergence-layer 468 protocol(s). 470 . When the encapsulating bundle is received, its payload is 471 delivered to the peer application agent administrative element, 472 which then instructs the bundle protocol agent to dispatch that 473 original bundle in the usual way. 475 The purposes for which this technique may be useful (such as cross- 476 domain security) are beyond the scope of this specification. 478 The only interface between the BPA and the application-specific 479 element of the AA is the BP service interface. But between the BPA 480 and the administrative element of the AA there is a (conceptual) 481 private control interface in addition to the BP service interface. 482 This private control interface enables the BPA and the 483 administrative element of the AA to direct each other to take action 484 under specific circumstances 486 In the case of a node that serves simply as a BP "router", the AA 487 may have no application-specific element at all. The application- 488 specific elements of other nodes' AAs may perform arbitrarily 489 complex application functions, perhaps even offering multiplexed DTN 490 communication services to a number of other applications. As with 491 the BPA, the manner in which the AA performs its functions is wholly 492 an implementation matter. 494 Singletons are the most familiar sort of endpoint, but in general 495 the endpoint notion is meant to be broader. For example, the nodes 496 in a sensor network might constitute a set of bundle nodes that 497 identify themselves by a single common endpoint ID and thus form a 498 single bundle endpoint. *Note* too that a given bundle node might 499 identify itself by multiple endpoint IDs and thus be a member of 500 multiple bundle endpoints. 502 The destination of every bundle is an endpoint, which may or may not 503 be singleton. The source of every bundle is a node, identified by 504 the endpoint ID for some singleton endpoint that contains that node. 506 The minimum reception group of an endpoint may be any one of the 507 following: (a) ALL of the nodes registered in an endpoint that is 508 permitted to contain multiple nodes (in which case forwarding to the 509 endpoint is functionally similar to "multicast" operations in the 510 Internet, though possibly very different in implementation); (b) ANY 511 N of the nodes registered in an endpoint that is permitted to 512 contain multiple nodes, where N is in the range from zero to the 513 cardinality of the endpoint; or (c) THE SOLE NODE registered in a 514 singleton endpoint (in which case forwarding to the endpoint is 515 functionally similar to "unicast" operations in the Internet). 517 The nature of the minimum reception group for a given endpoint can 518 typically be determined from the endpoint's ID. For some endpoint 519 ID "schemes", the nature of the minimum reception group is fixed - 520 in a manner that is defined by the scheme - for all endpoints 521 identified under the scheme. For other schemes, the nature of the 522 minimum reception group is indicated by some lexical feature of the 523 "scheme-specific part" of the endpoint ID, in a manner that is 524 defined by the scheme. 526 Any number of transmissions may be concurrently undertaken by the 527 bundle protocol agent of a given node. 529 When the bundle protocol agent of a node determines that a bundle 530 must be forwarded to a node (either to a node that is a member of 531 the bundle's destination endpoint or to some intermediate forwarding 532 node) in the course of completing the successful transmission of 533 that bundle, it invokes the services of a CLA in a sustained effort 534 to cause a copy of the bundle to be received by that node. 536 Upon reception, the processing of a bundle that has been received by 537 a given node depends on whether or not the receiving node is 538 registered in the bundle's destination endpoint. If it is, and if 539 the payload of the bundle is non-fragmentary (possibly as a result 540 of successful payload reassembly from fragmentary payloads, 541 including the original payload of the newly received bundle), then 542 the bundle is normally delivered to the node's application agent 543 subject to the registration characterizing the node's membership in 544 the destination endpoint. 546 Whenever, for some implementation-specific reason, a node's BPA 547 finds it impossible to immediately deliver a bundle that is 548 deliverable, delivery of the bundle has failed. In this event, the 549 delivery failure action associated with the applicable registration 550 must be taken. Delivery failure action MUST be one of the following: 552 . defer delivery of the bundle subject to this registration until 553 (a) this bundle is the least recently received of all bundles 554 currently deliverable subject to this registration and (b) 555 either the registration is polled or else the registration is 556 in the Active state; or 558 . abandon delivery of the bundle subject to this registration. 560 An additional implementation-specific delivery deferral procedure 561 MAY optionally be associated with the registration. 563 While the state of a registration is Passive, reception of a bundle 564 that is deliverable subject to this registration MUST cause delivery 565 of the bundle to be abandoned or deferred as mandated by the 566 registration's current delivery failure action; in the latter case, 567 any additional delivery deferral procedure associated with the 568 registration MUST also be performed. 570 While the state of a registration is Active, reception of a bundle 571 that is deliverable subject to this registration MUST cause the 572 bundle to be delivered automatically as soon as it is the next 573 bundle that is due for delivery according to the BPA's bundle 574 delivery scheduling policy, an implementation matter. 576 Normally only registrations' registered delivery failure actions 577 cause deliveries to be abandoned. 579 Custody of a bundle MAY be taken only if the destination of the 580 bundle is a singleton endpoint. Custody MAY be released only when 581 either (a) notification is received that some other node has 582 accepted custody of the same bundle; (b) notification is received 583 that the bundle has been delivered at the (sole) node registered in 584 the bundle's destination endpoint; (c) the current custodian chooses 585 to fragment the bundle, releasing custody of the original bundle and 586 taking custody of the fragments instead, or (d) the bundle is 587 explicitly deleted for some reason, such as lifetime expiration. 589 The custody transfer mechanism in BP comprises two services. For 590 each bundle either one of the two services, or neither, or both may 591 be requested. 593 The "retransmission" service of the custody transfer mechanism 594 provides a means of recovering from data loss along the path to the 595 destination node. When the custodian of a bundle forwards that 596 bundle it SHOULD set a retransmission timer; reception of a 597 responding custody signal of any kind prior to timer expiration MUST 598 disable that timer. Upon expiration of that timer, the custodian 599 MUST re-forward the bundle. When a bundle for which custody has 600 been taken and retransmission service has been requested arrives at 601 a node from which it must be forwarded, and that node determines 602 that it will forward the bundle but will not take custody, the 603 receiving node SHOULD send a "custody delegation" signal back to the 604 custodian indicating the next node to which the bundle will be 605 forwarded together with an estimate of the interval that will elapse 606 between the time the bundle was received and the time at which it 607 will be forwarded. This mechanism is intended to facilitate 608 accurate timeout interval calculation for this bundle. 610 The "rerouting" service of the custody transfer mechanism provides a 611 means of optimizing recovery from forwarding failures. When the 612 custodian of a bundle forwards that bundle it SHOULD set a rerouting 613 timer; reception of a responding custody signal of any kind prior to 614 timer expiration MUST disable that timer. Upon expiration of that 615 timer, the custodian MUST re-forward the bundle. When a bundle for 616 which custody has been taken and rerouting service has been 617 requested arrives at a node from which it must be forwarded, but 618 that node determines that it will not forward the bundle (and 619 therefore must not take custody), the receiving node SHOULD send a 620 custody refusal signal to the current custodian node, alerting the 621 custodian node to a forwarding anomaly on this route. 623 When both the retransmission and rerouting services of custody 624 transfer are requested for some bundle, a single custody transfer 625 timer SHOULD be shared by both services. Expiration of that timer 626 has the same effect - re-forwarding of the bundle - regardless of 627 the services requested. 629 Computation of the timeout interval for a bundle's custody transfer 630 timer (i.e., determination of the moment at which a responding 631 custody signal is expected) is an implementation matter and may be 632 dynamically responsive to changes in connectivity. In some 633 environments it may be impossible to compute this interval with 634 operationally satisfactory accuracy; in such environments the use of 635 custody transfer services is contraindicated. 637 Alternatively, when the custody transfer services for a given bundle 638 are not requested: 640 . Data loss along the path to the destination node can be 641 minimized by utilizing reliable convergence-layer protocols 642 between neighbors on all segments of the end-to-end path. This 643 approach may make more efficient use of links than custody 644 transfer because a convergence-layer protocol may perform 645 finer-grained retransmission than custody transfer does, 646 retransmitting only the specific portions of a transmitted 647 bundle that were not received, rather than the entire bundle. 648 However, in some environments there may be segments of the end- 649 to-end path for which no reliable convergence-layer protocol is 650 available; in such environments the use of reliable 651 convergence-layer protocols wherever possible can minimize the 652 incidence of data loss. 653 . Recovery from a forwarding failure can be accomplished by 654 "returning" the bundle back toward some node for forwarding 655 along some other path in the network. 657 3.3. Services Offered by Bundle Protocol Agents 659 The BPA of each node is expected to provide the following services 660 to the node's application agent: 662 . commencing a registration (registering the node in an 663 endpoint); 664 . terminating a registration; 665 . switching a registration between Active and Passive states; 666 . transmitting a bundle to an identified bundle endpoint; 667 . canceling a transmission; 668 . polling a registration that is in the Passive state; 669 . delivering a received bundle. 671 4. Bundle Format 673 The format of bundles SHALL conform to the Concise Binary Object 674 Representation (CBOR [RFC7049]). 676 Each bundle SHALL be a concatenated sequence of at least two blocks, 677 represented as a CBOR indefinite-length array (major type 4 with 678 additional info 31). The first block in the sequence (the first 679 item of the array) MUST be a primary bundle block in CBOR 680 representation as described below; the bundle MUST have exactly one 681 primary bundle block. The primary block MUST be followed by one or 682 more canonical bundle blocks (additional array items) in CBOR 683 representation as described below. The last such block MUST be a 684 payload block; the bundle MUST have exactly one payload block. The 685 last item of the array, immediately following the payload block, 686 SHALL be a CBOR "break" stop code (major type 7 with additional 687 information 31). 689 4.1. BP Fundamental Data Structures 691 4.1.1. CRC Type 693 CRC type is an unsigned integer type code for which the following 694 values (and no others) are valid: 696 . 0 indicates "no CRC is present." 697 . 1 indicates "a CRC-16 (a.k.a., CRC-16-ANSI) is present." 698 . 2 indicates "a standard IEEE 802.3 CRC-32 is present." 700 CRC type SHALL be represented as a CBOR unsigned integer. 702 4.1.2. CRC 704 CRC SHALL be omitted from a block if and only if the block's CRC 705 type code is zero. 707 When not omitted, the CRC SHALL be represented as a CBOR unsigned 708 integer. 710 4.1.3. Bundle Processing Control Flags 712 Bundle processing control flags assert properties of the bundle as a 713 whole rather than of any particular block of the bundle. They are 714 conveyed in the primary block of the bundle. 716 The following properties are asserted by the bundle processing 717 control flags: 719 . The bundle is a fragment. (Boolean) 721 . The bundle's payload is an administrative record. (Boolean) 723 . The bundle must not be fragmented. (Boolean) 725 . Custody transfer retransmission service requested for this 726 bundle. (Boolean) 728 . Custody transfer rerouting service requested for this bundle. 729 (Boolean) 731 . The bundle's destination endpoint is a singleton. (Boolean) 733 . Acknowledgment by the user application is requested. (Boolean) 735 . Status time is requested in all status reports. (Boolean) 737 . The bundle contains a "manifest" extension block. (Boolean) 739 . Flags requesting types of status reports (all Boolean): 741 o Request reporting of bundle reception. 743 o Request reporting of custody acceptance. 745 o Request reporting of bundle forwarding. 747 o Request reporting of bundle delivery. 749 o Request reporting of bundle deletion. 751 If the bundle processing control flags indicate that the bundle's 752 application data unit is an administrative record, then both custody 753 transfer service requested flags values must be zero and all status 754 report request flag values must be zero. 756 If either or both custody transfer service requested flags are 1, 757 then the source node is requesting that every receiving node accept 758 custody of the bundle. 760 If the bundle's source node is omitted (i.e., the source node ID is 761 the ID of the null endpoint, which has no members as discussed 762 below; this option enables anonymous bundle transmission), then the 763 bundle is not uniquely identifiable and all bundle protocol features 764 that rely on bundle identity must therefore be disabled: both of the 765 bundle's custody transfer service requested flag values must be 766 zero, the "Bundle must not be fragmented" flag value must be 1, and 767 all status report request flag values must be zero. 769 The bundle processing control flags SHALL be represented as a CBOR 770 unsigned integer item with additional info 25; the 16-bit unsigned 771 integer following the item type byte SHALL be a bit field indicating 772 the control flag values as follows: 774 . Bit 0 (the high-order bit, 0x8000): reserved. 775 . Bit 1 (0x4000): reserved. 776 . Bit 2(0x2000): bundle deletion status reports are requested. 777 . Bit 3(0x1000): bundle delivery status reports are requested. 778 . Bit 4(0x0800): bundle forwarding status reports are requested. 779 . Bit 5(0x0400): custody acceptance status reports are requested. 780 . Bit 6(0x0200): bundle reception status reports are requested. 781 . Bit 7(0x0100): bundle contains a Manifest block. 782 . Bit 8(0x0080): status time is requested in all status reports. 783 . Bit 9(0x0040): user application acknowledgement is requested. 784 . Bit 10(0x0020): destination is a singleton endpoint. 785 . Bit 11(0x0010): custody transfer rerouting is requested. 786 . Bit 12(0x0008): custody transfer retransmission is requested. 787 . Bit 13(0x0004): bundle must not be fragmented. 788 . Bit 14(0x0002): payload is an administrative record. 789 . Bit 15 (the low-order bit, 0x0001: bundle is a fragment. 791 4.1.4. Block Processing Control Flags 793 The block processing control flags assert properties of canonical 794 bundle blocks. They are conveyed in the header of the block to 795 which they pertain. 797 The following properties are asserted by the block processing 798 control flags: 800 . This block must be replicated in every fragment. (Boolean) 802 . Status report must be transmitted if this block can't be 803 processed. (Boolean) 805 . Block must be removed from the bundle if it can't be processed. 806 (Boolean) 808 . Bundle must be deleted if this block can't be processed. 809 (Boolean) 811 For each bundle whose bundle processing control flags indicate that 812 the bundle's application data unit is an administrative record, or 813 whose source node ID is the null endpoint ID as defined below, the 814 value of the "Transmit status report if block can't be processed" 815 flag in every canonical block of the bundle must be zero. 817 The block processing control flags SHALL be represented as a CBOR 818 unsigned integer item with additional info 24; the 8-bit unsigned 819 integer following the item type byte SHALL be a bit field indicating 820 the control flag values as follows: 822 . Bit 0 (the high-order bit, 0x80): reserved. 823 . Bit 1 (0x40): reserved. 824 . Bit 2(0x20): reserved. 825 . Bit 3(0x10): reserved. 826 . Bit 4(0x08): bundle must be deleted if block can't be 827 processed. 828 . Bit 5(0x04): status report must be transmitted if block can't 829 be processed. 830 . Bit 6(0x02): block must be removed from bundle if it can't be 831 processed. 832 . Bit 7(the low-order bit, 0x01): block must be replicated in 833 every fragment. 835 4.1.5. Identifiers 837 4.1.5.1. Endpoint ID 839 The destinations of bundles are bundle endpoints, identified by text 840 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 841 (EID) is a Uniform Resource Identifier (URI; [URI]). As such, each 842 endpoint ID can be characterized as having this general structure: 844 < scheme name > : < scheme-specific part, or "SSP" > 846 The scheme identified by the < scheme name > in an endpoint ID is a 847 set of syntactic and semantic rules that fully explain how to parse 848 and interpret the SSP. The set of allowable schemes is effectively 849 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 850 protocol endpoint ID. 852 Note that, although endpoint IDs are URIs, implementations of the BP 853 service interface may support expression of endpoint IDs in some 854 internationalized manner (e.g., Internationalized Resource 855 Identifiers (IRIs); see [RFC3987]). 857 The endpoint ID "dtn:none" identifies the "null endpoint", the 858 endpoint that by definition never has any members. 860 Each BP endpoint ID (EID) SHALL be represented as a CBOR array with 861 additional info 2, indicating that the item is a 2-tuple. 863 The first item of the array SHALL be the code number identifying the 864 endpoint's URI scheme [URI], as defined in the registry of URI 865 scheme code numbers for Bundle Protocol maintained by IANA as 866 described in Section Error! Reference source not found. [URIREG]. 867 Each URI scheme code number SHALL be represented as a CBOR unsigned 868 integer. 870 The second item of the array SHALL be the applicable CBOR 871 representation of the scheme-specific part (SSP) of the EID, defined 872 as follows: 874 . If the EID's URI scheme is "dtn" then the SSP SHALL be 875 represented as a CBOR text string unless the EID's SSP is 876 "none", in which case the SSP SHALL be represented as a CBOR 877 unsigned integer with the value zero. 878 . If the EID's URI scheme is "ipn" then the SSP SHALL be 879 represented as a CBOR array with additional info 2, indicating 880 that the item is a 2-tuple. The first item of this array SHALL 881 be the EID's node number represented as a CBOR unsigned 882 integer. The second item of this array SHALL be the EID's 883 service number represented as a CBOR unsigned integer. 884 . Definitions of the CBOR representations of the SSPs of EIDs 885 encoded in other URI schemes are included in the specifications 886 defining those schemes. 888 4.1.5.2. Node ID 890 For many purposes of the Bundle Protocol it is important to identify 891 the node that is operative in some context. 893 As discussed in 3.1 above, nodes are distinct from endpoints; 894 specifically, an endpoint is a set of zero or more nodes. But 895 rather than define a separate namespace for node identifiers, we 896 instead use endpoint identifiers to identify nodes, subject to the 897 following restrictions: 899 . Every node MUST be a member of at least one singleton endpoint. 900 . The EID of any singleton endpoint of which a node is a member 901 MAY be used to identify that node. A "node ID" is an EID that 902 is used in this way. 903 . A node's membership in a given singleton endpoint MUST be 904 sustained at least until the nominal operation of the Bundle 905 Protocol no longer depends on the identification of that node 906 using that endpoint's ID. 908 4.1.6. DTN Time 910 A DTN time is an unsigned integer indicating a count of seconds 911 since the start of the year 2000 on the Coordinated Universal Time 912 (UTC) scale [UTC]. Each DTN time SHALL be represented as a CBOR 913 unsigned integer item. 915 4.1.7. Creation Timestamp 917 Each creation timestamp SHALL be represented as a CBOR array item 918 with additional info 2, indicating that the item is a 2-tuple. 920 The first item of the array SHALL be a DTN time. 922 The second item of the array SHALL be the creation timestamp's 923 sequence number, represented as a CBOR unsigned integer. 925 4.1.8. Fragment ID 927 Fragment ID SHALL be omitted from the primary block if and only if 928 the value of the "bundle is a fragment" flag in the bundle 929 processing control flags is zero. 931 Otherwise, the bundle's fragment ID SHALL be represented as a CBOR 932 array with additional info 2, indicating that the item is a 2-tuple. 933 The first item of this array SHALL be the fragment offset of the 934 bundle's payload, represented as a CBOR unsigned integer. The 935 second item of this array SHALL be the total (original) application 936 data unit length, represented as a CBOR unsigned integer. 938 4.1.9. Block-type-specific Data 940 Block-type-specific data in each block (other than the primary 941 block) SHALL be the applicable CBOR representation of the content of 942 the block. Details of this representation are included in the 943 specification defining the block type. 945 4.2. Bundle Representation 947 This section describes the primary block in detail and non-primary 948 blocks in general. Rules for processing these blocks appear in 949 Section 5 of this document. 951 Note that supplementary DTN protocol specifications (including, but 952 not restricted to, the Bundle Security Protocol [BPSEC]) may require 953 that BP implementations conforming to those protocols construct and 954 process additional blocks. 956 4.2.1. Bundle 958 Each bundle SHALL be represented as a CBOR indefinite-length array 959 (major type 4 with additional info 31). The first item of this 960 array SHALL be the CBOR representation of a Primary Block. Every 961 other item of the array except the last SHALL be the CBOR 962 representation of a Canonical Block. The last item of the array 963 SHALL be a CBOR "break" stop code (major type 7 with additional 964 information 31). 966 4.2.2. Primary Bundle Block 968 The primary bundle block contains the basic information needed to 969 forward bundles to their destinations. 971 Each primary block SHALL be represented as a CBOR array (major type 972 4) with additional info either 8 (if the bundle is not a fragment 973 and CRC type is zero) or 9 (if the bundle is a fragment or CRC type 974 is non-zero, but not both) or 10 (if the bundle is a fragment and 975 CRC-type is non-zero). The items of this array SHALL be as 976 indicated in Table 1, appearing in the order shown in this table. 978 +-------------+-----------------+---------------------------------+ 979 | | Item Type Byte | Content Bytes | 980 | | | | 981 | | Major | | 982 | | Item | Add'l | | 983 | | Type | Info | | 984 | Item | 3 bits | 5 bits | Size | Value | 985 +=============+========+========+======+==========================+ 986 | version | 0 | 7 | n/a | n/a | 987 +-------------+--------+--------+------+--------------------------+ 988 | bundle | See Section 4.1.3. above | 989 | processing | | | | | 990 | control | | | | | 991 | flags | | | | | 992 +-------------+--------+--------+------+--------------------------+ 993 | CRC type | 0 | type | n/a | n/a | 994 | | | code | | | 995 +-------------+--------+--------+------+--------------------------+ 996 | destination | See Section 4.1.5.1. above | 997 | EID | | | | | 998 +-------------+--------+--------+------+--------------------------+ 999 | source node | See Section 4.1.5.2. above | 1000 | ID | | | | | 1001 +-------------+--------+--------+------+--------------------------+ 1002 | report-to | See Section 4.1.5.1. above | 1003 | EID | | | | | 1004 +-------------+--------+--------+------+--------------------------+ 1005 | creation | See Section 4.1.7. above | 1006 | timestamp | | | | | 1007 +-------------+--------+--------+------+--------------------------+ 1008 | lifetime | 0 | as required to contain value | 1009 +-------------+--------+--------+------+--------------------------+ 1010 | fragment ID | See Section 4.1.8. above | 1011 +-------------+--------+--------+------+--------------------------+ 1012 | CRC | See Section 4.1.2. above | 1013 +-------------+--------+--------+------+--------------------------+ 1015 Table 1: Primary Block Data Items 1017 The fields of the primary bundle block are: 1019 Version: An unsigned integer value indicating the version of the 1020 bundle protocol that constructed this block. The present document 1021 describes version 7 of the bundle protocol. Version number SHALL be 1022 represented as a CBOR unsigned integer item. 1024 Bundle Processing Control Flags: The Bundle Processing Control Flags 1025 are discussed in Section 4.1.3. above. 1027 CRC Type: CRC Type codes are discussed in Section 4.1.1. above. 1029 Destination EID: The Destination EID field identifies the bundle 1030 endpoint that is the bundle's destination, i.e., the endpoint that 1031 contains the node(s) at which the bundle is to be delivered. 1033 Source node ID: The Source node ID field identifies the bundle node 1034 at which the bundle was initially transmitted, except that Source 1035 node ID may be the null endpoint ID in the event that the bundle's 1036 source chooses to remain anonymous. 1038 Report-to EID: The Report-to EID field identifies the bundle 1039 endpoint to which status reports pertaining to the forwarding and 1040 delivery of this bundle are to be transmitted. 1042 Creation Timestamp: The creation timestamp is a pair of unsigned 1043 integers that, together with the source node ID and (if the bundle 1044 is a fragment) the fragment offset and payload length, serve to 1045 identify the bundle. The first of these integers is the bundle's 1046 creation time, while the second is the bundle's creation timestamp 1047 sequence number. Bundle creation time shall be the time - expressed 1048 in seconds since the start of the year 2000, on the Coordinated 1049 Universal Time (UTC) scale [UTC] - at which the transmission request 1050 was received that resulted in the creation of the bundle. Sequence 1051 count shall be the latest value (as of the time at which that 1052 transmission request was received) of a monotonically increasing 1053 positive integer counter managed by the source node's bundle 1054 protocol agent that may be reset to zero whenever the current time 1055 advances by one second. For nodes that lack accurate clocks (that 1056 is, nodes that are not at all moments able to determine the current 1057 UTC time to within 30 seconds), bundle creation time MUST be set to 1058 zero and the counter used as the source of the bundle sequence count 1059 MUST NEVER be reset to zero. In any case, a source Bundle Protocol 1060 Agent MUST NEVER create two distinct bundles with the same source 1061 node ID and bundle creation timestamp. The combination of source 1062 node ID and bundle creation timestamp serves to identify a single 1063 transmission request, enabling it to be acknowledged by the 1064 receiving application (provided the source node ID is not the null 1065 endpoint ID). 1067 Lifetime: The lifetime field is an unsigned integer that indicates 1068 the time at which the bundle's payload will no longer be useful, 1069 encoded as a number of seconds past the creation time. When a 1070 bundle's age exceeds its lifetime, bundle nodes need no longer 1071 retain or forward the bundle; the bundle SHOULD be deleted from the 1072 network. Bundle lifetime SHALL be represented as a CBOR unsigned 1073 integer item. 1075 Fragment ID: If and only if the Bundle Processing Control Flags of 1076 this Primary block indicate that the bundle is a fragment, the 1077 Fragment ID field as discussed in 4.1.8. above SHALL be present in 1078 the primary block. Fragment offset in the Fragment ID SHALL be an 1079 unsigned integer indicating the offset from the start of the 1080 original application data unit at which the bytes comprising the 1081 payload of this bundle were located. Total Application Data Unit 1082 Length in the Fragment ID SHALL be an unsigned integer indicating 1083 the total length of the original application data unit of which this 1084 bundle's payload is a part. 1086 CRC: If and only if the value of the CRC type field of this Primary 1087 block is non-zero, a CRC SHALL be present in the primary block. The 1088 length and nature of the CRC SHALL be as indicated by the CRC type. 1089 The CRC SHALL be computed over the concatenation of all bytes of the 1090 primary block including the CRC field itself, which for this purpose 1091 SHALL be temporarily populated with the value zero. 1093 4.2.3. Canonical Bundle Block Format 1095 Every block other than the primary block (which blocks are termed 1096 "canonical" blocks) SHALL be represented as a CBOR array (major type 1097 4) with additional info either 5 (if CRC type is zero) or 6 1098 (otherwise). The items of this array SHALL be as indicated in Table 1099 2, appearing in the order shown in this table. 1101 +-------------+-----------------+---------------------------------+ 1102 | | Item Type Byte | Content Bytes | 1103 | | | | 1104 | | Major | | 1105 | | Item | Add'l | | 1106 | | Type | Info | | 1107 | Item | 3 bits | 5 bits | Size | Value | 1108 +=============+========+========+======+==========================+ 1109 | block type | 0 | as required to contain value | 1110 | code | | | | | 1111 +-------------+--------+--------+------+--------------------------+ 1112 | block number| 0 | as required to contain value | 1113 +-------------+--------+--------+------+--------------------------+ 1114 | block | See Section 4.1.4. above | 1115 | processing | | | | | 1116 | control | | | | | 1117 | flags | | | | | 1118 +-------------+--------+--------+------+--------------------------+ 1119 | CRC type | 0 | type | n/a | n/a | 1120 | | | code | | | 1121 +-------------+--------+--------+------+--------------------------+ 1122 | CRC | See Section 4.1.2. above | 1123 +-------------+--------+--------+------+--------------------------+ 1124 | block data | 0 | as required to contain value | 1125 | length | | | | | 1126 +-------------+--------+--------+------+--------------------------+ 1127 | block-type- | See Section 4.1.9. above | 1128 | specific | | | | | 1129 | data | | | | | 1130 +-------------+--------+--------+------+--------------------------+ 1132 Table 2: Canonical Block Data Items 1134 Every canonical block SHALL comprise the following fields: 1136 . Block type code, an unsigned integer. Bundle block type code 1 1137 indicates that the block is a bundle payload block. Block type 1138 codes 2 through 9 are explicitly reserved as noted later in 1139 this specification. Block type codes 192 through 255 are not 1140 reserved and are available for private and/or experimental use. 1141 All other block type code values are reserved for future use. 1142 . Block number, an unsigned integer. The block number uniquely 1143 identifies the block within the bundle, enabling blocks 1144 (notably bundle security protocol blocks) to explicitly 1145 reference other blocks in the same bundle. Block numbers need 1146 not be in continuous sequence, and blocks need not appear in 1147 block number sequence in the bundle. The block number of the 1148 payload block is always zero. 1149 . Block processing control flags as discussed in Section 4.1.4 1150 above. 1151 . CRC type as discussed in Section 4.1.1 above. 1152 . If and only if the value of the CRC type field of this block is 1153 non-zero, a CRC. If present, the length and nature of the CRC 1154 SHALL be as indicated by the CRC type and the CRC SHALL be 1155 computed over the concatenation of all bytes of the block 1156 including the CRC field itself, which for this purpose SHALL be 1157 temporarily populated with the value zero. 1158 . Block data length, an unsigned integer. The block data length 1159 field SHALL contain the aggregate length of all remaining 1160 fields of the block, i.e., the block-type-specific data fields. 1161 Block data length SHALL be represented as a CBOR unsigned 1162 integer item. 1163 . Block-type-specific data fields, whose nature and order are 1164 type-specific and whose aggregate length in octets is the value 1165 of the block data length field. For the Payload Block in 1166 particular (block type 1), there SHALL be exactly one block- 1167 type-specific data field, termed the "payload", which SHALL be 1168 an application data unit, or some contiguous extent thereof, 1169 represented as a CBOR byte string (major type 2). 1171 4.3. Extension Blocks 1173 "Extension blocks" are all blocks other than the primary and payload 1174 blocks. Because not all extension blocks are defined in the Bundle 1175 Protocol specification (the present document), not all nodes 1176 conforming to this specification will necessarily instantiate Bundle 1177 Protocol implementations that include procedures for processing 1178 (that is, recognizing, parsing, acting on, and/or producing) all 1179 extension blocks. It is therefore possible for a node to receive a 1180 bundle that includes extension blocks that the node cannot process. 1181 The values of the block processing control flags indicate the action 1182 to be taken by the bundle protocol agent when this is the case. 1184 The following extension blocks are defined in other DTN protocol 1185 specification documents as noted: 1187 . Block Integrity Block (block type 2) and Block Confidentiality 1188 Block (block type 3) are defined in the Bundle Security 1189 Protocol specification (work in progress). 1190 . Manifest Block (block type 4) is defined in the Manifest 1191 Extension Block specification (TBD). The manifest block 1192 identifies the blocks that were present in the bundle at the 1193 time it was created. The bundle MUST contain one (1) 1194 occurrence of this type of block if the value of the "manifest" 1195 flag in the bundle processing control flags is 1; otherwise the 1196 bundle MUST NOT contain any Manifest block. 1197 . The Flow Label Block (block type 6) is defined in the Flow 1198 Label Extension Block specification (TBD). The flow label 1199 block is intended to govern transmission of the bundle by 1200 convergence-layer adapters. 1202 The following extension blocks are defined in the current document. 1204 4.3.1. Current Custodian 1206 The Current Custodian block, block type 5, identifies a node that is 1207 known to have accepted custody of the bundle. The block-type- 1208 specific data of this block is the node ID of a custodian, which 1209 SHALL take the form of an endpoint ID represented as described in 1210 Section 4.1.5.2. above. The bundle MAY contain one or more 1211 occurrences of this type of block. 1213 4.3.2. Previous Node 1215 The Previous Node block, block type 7, identifies the node that 1216 forwarded this bundle to the local node (i.e., to the node at which 1217 the bundle currently resides); its block-type-specific data is the 1218 node ID of that forwarder node which SHALL take the form of a node 1219 ID represented as described in Section 4.1.5.2. above. If the local 1220 node is the source of the bundle, then the bundle MUST NOT contain 1221 any previous node block. Otherwise the bundle MUST contain one (1) 1222 occurrence of this type of block. If present, the previous node 1223 block MUST be the FIRST block following the primary block, as the 1224 processing of other extension blocks may depend on its value. 1226 4.3.3. Bundle Age 1228 The Bundle Age block, block type 8, contains the number of seconds 1229 that have elapsed between the time the bundle was created and time 1230 at which it was most recently forwarded. It is intended for use by 1231 nodes lacking access to an accurate clock, to aid in determining the 1232 time at which a bundle's lifetime expires. The block-type-specific 1233 data of this block is an unsigned integer containing the age of the 1234 bundle in seconds, which SHALL be represented as a CBOR unsigned 1235 integer item. (The age of the bundle is the sum of all known 1236 intervals of the bundle's residence at forwarding nodes, up to the 1237 time at which the bundle was most recently forwarded, plus the 1238 summation of signal propagation time over all episodes of 1239 transmission between forwarding nodes. Determination of these 1240 values is an implementation matter.) If the bundle's creation time 1241 is zero, then the bundle MUST contain exactly one (1) occurrence of 1242 this type of block; otherwise, the bundle MAY contain at most one 1243 (1) occurrence of this type of block. 1245 4.3.4. Hop Count 1247 The Hop Count block, block type 9, contains two unsigned integers, 1248 hop limit and hop count. A "hop" is here defined as an occasion on 1249 which a bundle was forwarded from one node to another node. The hop 1250 count block is mainly intended as a safety mechanism, a means of 1251 identifying bundles for removal from the network that can never be 1252 delivered due to a persistent forwarding error: a bundle SHOULD be 1253 deleted when its hop count exceeds its hop limit. Procedures for 1254 determining the appropriate hop limit for a block are beyond the 1255 scope of this specification. The block-type-specific data in a hop 1256 count block SHALL be represented as a CBOR array (major type 4) with 1257 additional info 2, indicating that the item is a 2-tuple. The first 1258 item of this array SHALL be the bundle's hop limit, represented as a 1259 CBOR unsigned integer. The second item of this array SHALL be the 1260 bundle's hop count, represented as a CBOR unsigned integer. A bundle 1261 MAY contain at most one (1) occurrence of this type of block. 1263 5. Bundle Processing 1265 The bundle processing procedures mandated in this section and in 1266 Section 6 govern the operation of the Bundle Protocol Agent and the 1267 Application Agent administrative element of each bundle node. They 1268 are neither exhaustive nor exclusive. Supplementary DTN protocol 1269 specifications (including, but not restricted to, the Bundle 1270 Security Protocol [BPSEC]) may augment, override, or supersede the 1271 mandates of this document. 1273 5.1. Generation of Administrative Records 1275 All transmission of bundles is in response to bundle transmission 1276 requests presented by nodes' application agents. When required to 1277 "generate" an administrative record (such as a bundle status report 1278 or a custody signal), the bundle protocol agent itself is 1279 responsible for causing a new bundle to be transmitted, conveying 1280 that record. In concept, the bundle protocol agent discharges this 1281 responsibility by directing the administrative element of the node's 1282 application agent to construct the record and request its 1283 transmission as detailed in Section 6 below. In practice, the manner 1284 in which administrative record generation is accomplished is an 1285 implementation matter, provided the constraints noted in Section 6 1286 are observed. 1288 Under some circumstances, the requesting of status reports could 1289 result in an unacceptable increase in the bundle traffic in the 1290 network. For this reason, the generation of status reports is 1291 mandatory only in two cases: 1293 . the reception of a bundle containing at least one block that 1294 cannot be processed, for which the value of the "transmit 1295 status report if block could not be processed" block processing 1296 flag is 1, and 1297 . the deletion of a bundle for which either custody transfer 1298 service is requested. 1300 In all other cases, the decision on whether or not to generate a 1301 requested status report is left to the discretion of the bundle 1302 protocol agent. Mechanisms that could assist in making such 1303 decisions, such as pre-placed agreements authorizing the generation 1304 of status reports under specified circumstances, are beyond the 1305 scope of this specification. 1307 Notes on administrative record terminology: 1309 . A "bundle reception status report" is a bundle status report 1310 with the "reporting node received bundle" flag set to 1. 1311 . A "custody acceptance status report" is a bundle status report 1312 with the "reporting node accepted custody of bundle" flag set 1313 to 1. 1314 . A "bundle forwarding status report" is a bundle status report 1315 with the "reporting node forwarded the bundle" flag set to 1. 1316 . A "bundle delivery status report" is a bundle status report 1317 with the "reporting node delivered the bundle" flag set to 1. 1318 . A "bundle deletion status report" is a bundle status report 1319 with the "reporting node deleted the bundle" flag set to 1. 1320 . "Custody transfer is requested" means that either or both of 1321 the custody transfer services are requested for this bundle. 1322 . A "current custodian" of a bundle is a node identified in a 1323 Current Custodian extension block of that bundle. 1325 5.2. Bundle Transmission 1327 The steps in processing a bundle transmission request are: 1329 Step 1: If custody transfer is requested for this bundle 1330 transmission then the destination MUST be a singleton endpoint. If, 1331 moreover, custody acceptance by the source node is required when 1332 custody is requested (an implementation matter) but the conditions 1333 under which custody of the bundle may be accepted are not satisfied, 1334 then the request cannot be honored and all remaining steps of this 1335 procedure MUST be skipped. 1337 Step 2: Transmission of the bundle is initiated. An outbound bundle 1338 MUST be created per the parameters of the bundle transmission 1339 request, with the retention constraint "Dispatch pending". The 1340 source node ID of the bundle MUST be either the null endpoint ID, 1341 indicating that the source of the bundle is anonymous, or else the 1342 EID of a singleton endpoint whose only member is the node of which 1343 the BPA is a component. 1345 Step 3: Processing proceeds from Step 1 of Section 5.4. 1347 5.3. Bundle Dispatching 1349 The steps in dispatching a bundle are: 1351 Step 1: If the bundle's destination endpoint is an endpoint of which 1352 the node is a member, the bundle delivery procedure defined in 1353 Section 5.7 MUST be followed. 1355 Step 2: Processing proceeds from Step 1 of Section 5.4. 1357 5.4. Bundle Forwarding 1359 The steps in forwarding a bundle are: 1361 Step 1: The retention constraint "Forward pending" MUST be added to 1362 the bundle, and the bundle's "Dispatch pending" retention constraint 1363 MUST be removed. 1365 Step 2: The bundle protocol agent MUST determine whether or not 1366 forwarding is contraindicated for any of the reasons listed in 1367 Figure 4. In particular: 1369 . The bundle protocol agent MUST determine which node(s) to 1370 forward the bundle to. The bundle protocol agent MAY choose 1371 either to forward the bundle directly to its destination 1372 node(s) (if possible) or to forward the bundle to some other 1373 node(s) for further forwarding. The manner in which this 1374 decision is made may depend on the scheme name in the 1375 destination endpoint ID and/or on other state but in any case 1376 is beyond the scope of this document. If the BPA elects to 1377 forward the bundle to some other node(s) for further forwarding 1378 but finds it impossible to select any node(s) to forward the 1379 bundle to, then forwarding is contraindicated. 1380 . Provided the bundle protocol agent succeeded in selecting the 1381 node(s) to forward the bundle to, the bundle protocol agent 1382 MUST select the convergence layer adapter(s) whose services 1383 will enable the node to send the bundle to those nodes. The 1384 manner in which specific appropriate convergence layer adapters 1385 are selected is beyond the scope of this document. If the agent 1386 finds it impossible to select any appropriate convergence layer 1387 adapter(s) to use in forwarding this bundle, then forwarding is 1388 contraindicated. 1390 Step 3: If forwarding of the bundle is determined to be 1391 contraindicated for any of the reasons listed in Figure 4, then the 1392 Forwarding Contraindicated procedure defined in Section 5.4.1 MUST 1393 be followed; the remaining steps of Section 5 are skipped at this 1394 time. 1396 Step 4: If either or both of the bundle's custody transfer service 1397 requested flags (in the bundle processing flags field) are set to 1, 1398 then the custody transfer procedure defined in Section 5.10 MUST be 1399 followed. 1401 Step 5: For each node selected for forwarding, the bundle protocol 1402 agent MUST invoke the services of the selected convergence layer 1403 adapter(s) in order to effect the sending of the bundle to that 1404 node. Determining the time at which the bundle protocol agent 1405 invokes convergence layer adapter services is a BPA implementation 1406 matter. Determining the time at which each convergence layer 1407 adapter subsequently responds to this service invocation by sending 1408 the bundle is a convergence-layer adapter implementation matter. 1409 Note that: 1411 . If the bundle contains a flow label extension block then that 1412 flow label value MAY identify procedures for determining the 1413 order in which convergence layer adapters must send bundles, 1414 e.g., considering bundle source when determining the order in 1415 which bundles are sent. The definition of such procedures is 1416 beyond the scope of this specification. 1417 . If the bundle has a bundle age block, then at the last possible 1418 moment before the CLA initiates conveyance of the bundle node 1419 via the CL protocol the bundle age value MUST be increased by 1420 the difference between the current time and the time at which 1421 the bundle was received (or, if the local node is the source of 1422 the bundle, created). 1424 Step 6: When all selected convergence layer adapters have informed 1425 the bundle protocol agent that they have concluded their data 1426 sending procedures with regard to this bundle: 1428 . If the "request reporting of bundle forwarding" flag in the 1429 bundle's status report request field is set to 1, then a bundle 1430 forwarding status report SHOULD be generated, destined for the 1431 bundle's report-to endpoint ID. If the bundle has the retention 1432 constraint "custody accepted" and all of the nodes to which the 1433 bundle was forwarded are known to be unable to send bundles 1434 back to this node, then the reason code on this bundle 1435 forwarding status report MUST be "forwarded over unidirectional 1436 link"; otherwise, the reason code MUST be "no additional 1437 information". 1438 . The bundle's "Forward pending" retention constraint MUST be 1439 removed. 1441 5.4.1. Forwarding Contraindicated 1443 The steps in responding to contraindication of forwarding are: 1445 Step 1: The bundle protocol agent MUST determine whether or not to 1446 declare failure in forwarding the bundle. Note: this decision is 1447 likely to be influenced by the reason for which forwarding is 1448 contraindicated. 1450 Step 2: If forwarding failure is declared, then the Forwarding 1451 Failed procedure defined in Section 5.4.2 MUST be followed. 1453 Otherwise, (a) if either or both of the bundle's custody transfer 1454 requested flags (in the bundle processing flags field) are set to 1, 1455 then the custody transfer procedure defined in Section 5.10 MUST be 1456 followed; (b) when -- at some future time - the forwarding of this 1457 bundle ceases to be contraindicated, processing proceeds from Step 5 1458 of Section 5.4. 1460 5.4.2. Forwarding Failed 1462 The steps in responding to a declaration of forwarding failure are: 1464 Step 1: If the bundle's custody transfer rerouting service requested 1465 flag (in the bundle processing flags field) is set to 1, custody 1466 transfer failure must be handled. The bundle protocol agent MUST 1467 handle the custody transfer failure by generating a custody signal 1468 of type 1 (custody refusal) for the bundle, destined for the 1469 bundle's current custodian(s); the custody signal MUST contain a 1470 reason code corresponding to the reason for which forwarding was 1471 determined to be contraindicated. (Note that discarding the bundle 1472 will not delete it from the network, since each current custodian 1473 still has a copy.) 1475 If the bundle's custody transfer rerouting service requested flag 1476 (in the bundle processing flags field) is set to 0, then the bundle 1477 protocol agent MAY forward the bundle back to the node that sent it, 1478 as identified by the Previous Node block. 1480 Step 2: If the bundle's destination endpoint is an endpoint of which 1481 the node is a member, then the bundle's "Forward pending" retention 1482 constraint MUST be removed. Otherwise, the bundle MUST be deleted: 1483 the bundle deletion procedure defined in Section 5.14 MUST be 1484 followed, citing the reason for which forwarding was determined to 1485 be contraindicated. 1487 5.5. Bundle Expiration 1489 A bundle expires when the bundle's age exceeds its lifetime as 1490 specified in the primary bundle block. Bundle age MAY be determined 1491 by subtracting the bundle's creation timestamp time from the current 1492 time if (a) that timestamp time is not zero and (b) the local node's 1493 clock is known to be accurate (as discussed in section 4.5.1 above); 1494 otherwise bundle age MUST be obtained from the Bundle Age extension 1495 block. Bundle expiration MAY occur at any point in the processing 1496 of a bundle. When a bundle expires, the bundle protocol agent MUST 1497 delete the bundle for the reason "lifetime expired": the bundle 1498 deletion procedure defined in Section 5.14 MUST be followed. 1500 5.6. Bundle Reception 1502 The steps in processing a bundle that has been received from another 1503 node are: 1505 Step 1: The retention constraint "Dispatch pending" MUST be added to 1506 the bundle. 1508 Step 2: If the "request reporting of bundle reception" flag in the 1509 bundle's status report request field is set to 1, then a bundle 1510 reception status report with reason code "No additional information" 1511 SHOULD be generated, destined for the bundle's report-to endpoint 1512 ID. 1514 Step 3: For each block in the bundle that is an extension block that 1515 the bundle protocol agent cannot process: 1517 . If the block processing flags in that block indicate that a 1518 status report is requested in this event, then a bundle 1519 reception status report with reason code "Block unintelligible" 1520 SHOULD be generated, destined for the bundle's report-to 1521 endpoint ID. 1522 . If the block processing flags in that block indicate that the 1523 bundle must be deleted in this event, then the bundle protocol 1524 agent MUST delete the bundle for the reason "Block 1525 unintelligible"; the bundle deletion procedure defined in 1526 Section 5.14 MUST be followed and all remaining steps of the 1527 bundle reception procedure MUST be skipped. 1528 . If the block processing flags in that block do NOT indicate 1529 that the bundle must be deleted in this event but do indicate 1530 that the block must be discarded, then the bundle protocol 1531 agent MUST remove this block from the bundle. 1532 . If the block processing flags in that block indicate neither 1533 that the bundle must be deleted nor that that the block must be 1534 discarded, then processing continues with the next extension 1535 block that the bundle protocol agent cannot process, if any; 1536 otherwise, processing proceeds from step 4. 1538 Step 4: If the bundle's custody transfer rerouting service requested 1539 flag (in the bundle processing flags field) is set to 1 and the 1540 bundle has the same source node ID, creation timestamp, and (if the 1541 bundle is a fragment) fragment offset and payload length as another 1542 bundle that (a) has not been discarded and (b) currently has the 1543 retention constraint "Custody accepted", custody transfer redundancy 1544 MUST be handled; otherwise, processing proceeds from Step 5. The 1545 bundle protocol agent MUST handle custody transfer redundancy by 1546 generating a custody signal of type 1 (custody refusal) for this 1547 bundle with reason code "Redundant reception", destined for this 1548 bundle's current custodian, and removing this bundle's "Dispatch 1549 pending" retention constraint. 1551 Step 5: Processing proceeds from Step 1 of Section 5.3. 1553 5.7. Local Bundle Delivery 1555 The steps in processing a bundle that is destined for an endpoint of 1556 which this node is a member are: 1558 Step 1: If the received bundle is a fragment, the application data 1559 unit reassembly procedure described in Section 5.9 MUST be followed. 1560 If this procedure results in reassembly of the entire original 1561 application data unit, processing of this bundle (whose fragmentary 1562 payload has been replaced by the reassembled application data unit) 1563 proceeds from Step 2; otherwise, the retention constraint 1564 "Reassembly pending" MUST be added to the bundle and all remaining 1565 steps of this procedure MUST be skipped. 1567 Step 2: Delivery depends on the state of the registration whose 1568 endpoint ID matches that of the destination of the bundle: 1570 . If the registration is in the Active state, then the bundle 1571 MUST be delivered subject to this registration (see Section 3.1 1572 above) as soon as all previously received bundles that are 1573 deliverable subject to this registration have been delivered. 1574 . If the registration is in the Passive state, then the 1575 registration's delivery failure action MUST be taken (see 1576 Section 3.1 above). 1578 Step 3: As soon as the bundle has been delivered: 1580 . If the "request reporting of bundle delivery" flag in the 1581 bundle's status report request field is set to 1, then a bundle 1582 delivery status report SHOULD be generated, destined for the 1583 bundle's report-to endpoint ID. Note that this status report 1584 only states that the payload has been delivered to the 1585 application agent, not that the application agent has processed 1586 that payload. 1588 . If either or both of the bundle's custody transfer service 1589 requested flags (in the bundle processing flags field) are set 1590 to 1, custodial delivery MUST be reported. The bundle protocol 1591 agent MUST report custodial delivery by generating a custody 1592 signal of type 0 (custody acceptance) for the bundle, destined 1593 for the bundle's current custodian(s). 1595 5.8. Bundle Fragmentation 1597 It may at times be advantageous for bundle protocol agents to reduce 1598 the sizes of bundles in order to forward them. This might be the 1599 case, for example, if a node to which a bundle is to be forwarded is 1600 accessible only via intermittent contacts and no upcoming contact is 1601 long enough to enable the forwarding of the entire bundle. 1603 The size of a bundle can be reduced by "fragmenting" the bundle. To 1604 fragment a bundle whose payload is of size M is to replace it with 1605 two "fragments" -- new bundles with the same source node ID and 1606 creation timestamp as the original bundle -- whose payloads are the 1607 first N and the last (M - N) bytes of the original bundle's payload, 1608 where 0 < N < M. Note that fragments may themselves be fragmented, 1609 so fragmentation may in effect replace the original bundle with more 1610 than two fragments. (However, there is only one 'level' of 1611 fragmentation, as in IP fragmentation.) 1613 Any bundle that has any Current Custodian extension block citing any 1614 node other than the local node MUST NOT be fragmented. This 1615 restriction aside, any bundle whose primary block's bundle 1616 processing flags do NOT indicate that it must not be fragmented MAY 1617 be fragmented at any time, for any purpose, at the discretion of the 1618 bundle protocol agent. 1620 Fragmentation SHALL be constrained as follows: 1622 . The concatenation of the payloads of all fragments produced by 1623 fragmentation MUST always be identical to the payload of the 1624 fragmented bundle (that is, the bundle that is being 1625 fragmented). Note that the payloads of fragments resulting from 1626 different fragmentation episodes, in different parts of the 1627 network, may be overlapping subsets of the fragmented bundle's 1628 payload. 1629 . The primary block of each fragment MUST differ from that of the 1630 fragmented bundle, in that the bundle processing flags of the 1631 fragment MUST indicate that the bundle is a fragment and both 1632 fragment offset and total application data unit length must be 1633 provided. Additionally, the CRC of the fragmented bundle, if 1634 any, MUST be replaced in each fragment by a new CRC computed 1635 for the primary block of that fragment. 1636 . The payload blocks of fragments will differ from that of the 1637 fragmented bundle as noted above. 1638 . If the fragmented bundle is not a fragment or is the fragment 1639 with offset zero, then all extension blocks of the fragmented 1640 bundle MUST be replicated in the fragment whose offset is zero. 1641 . Each of the fragmented bundle's extension blocks whose "Block 1642 must be replicated in every fragment" flag is set to 1 MUST be 1643 replicated in every fragment. 1644 . Beyond these rules, replication of extension blocks in the 1645 fragments is an implementation matter. 1646 . If the local node is a custodian of the fragmented bundle, then 1647 the BPA MUST release custody of the fragmented bundle before 1648 fragmentation occurs and MUST take custody of every fragment. 1650 5.9. Application Data Unit Reassembly 1652 If the concatenation -- as informed by fragment offsets and payload 1653 lengths -- of the payloads of all previously received fragments with 1654 the same source node ID and creation timestamp as this fragment, 1655 together with the payload of this fragment, forms a byte array whose 1656 length is equal to the total application data unit length in the 1657 fragment's primary block, then: 1659 . This byte array -- the reassembled application data unit -- 1660 MUST replace the payload of this fragment. 1661 . The BPA MUST take custody of each fragmentary bundle whose 1662 payload is a subset of the reassembled application data unit, 1663 for which custody transfer is requested but the BPA has not yet 1664 taken custody. 1665 . The BPA MUST then release custody of every fragment whose 1666 payload is a subset of the reassembled application data unit, 1667 for which it has taken custody. 1668 . The "Reassembly pending" retention constraint MUST be removed 1669 from every other fragment whose payload is a subset of the 1670 reassembled application data unit. 1672 Note: reassembly of application data units from fragments occurs at 1673 the nodes that are members of destination endpoints as necessary; an 1674 application data unit MAY also be reassembled at some other node on 1675 the path to the destination. 1677 5.10. Custody Transfer 1679 The decision as to whether or not to accept custody of a bundle is 1680 an implementation matter that may involve both resource and policy 1681 considerations. 1683 If the bundle protocol agent elects to accept custody of the bundle, 1684 then it must follow the custody acceptance procedure defined in 1685 Section 5.10.1. 1687 5.10.1. Custody Acceptance 1689 Procedures for acceptance of custody of a bundle are defined as 1690 follows. 1692 The retention constraint "Custody accepted" MUST be added to the 1693 bundle. 1695 If the "request reporting of custody acceptance" flag in the 1696 bundle's status report request field is set to 1, a custody 1697 acceptance status report SHOULD be generated, destined for the 1698 report-to endpoint ID of the bundle. However, if a bundle reception 1699 status report was generated for this bundle (Step 2 of Section 5.6) 1700 but has not yet been transmitted, then this report SHOULD be 1701 generated by simply turning on the "Reporting node accepted custody 1702 of bundle" flag in that earlier report. 1704 The bundle protocol agent MUST generate a custody signal of type 0 1705 (custody acceptance) for the bundle, destined for the bundle's 1706 current custodian(s). 1708 The bundle protocol agent MUST assert the new current custodian for 1709 the bundle. It does so by deleting all of the bundle's existing 1710 Current Custodian extension blocks and inserting a new Current 1711 Custodian extension block whose value is the node ID of the local 1712 node. 1714 If the value of a custody transfer timer interval for this bundle 1715 can be calculated with operationally satisfactory accuracy, the 1716 bundle protocol agent SHOULD set a custody transfer countdown timer 1717 for the bundle; upon expiration of this timer prior to expiration of 1718 the bundle itself and prior to custody transfer success for this 1719 bundle, the custody transfer failure procedure detailed in Section 1720 5.12 MUST be followed. The manner in which the countdown interval 1721 for such a timer is determined is an implementation matter. 1723 The bundle SHOULD be retained in persistent storage if possible. 1725 5.10.2. Custody Release 1727 When custody of a bundle is released, the "Custody accepted" 1728 retention constraint MUST be removed from the bundle and any custody 1729 transfer timer that has been established for this bundle SHOULD be 1730 destroyed. 1732 5.11. Custody Transfer Success 1734 Upon receipt of a custody signal of type 0 (custody acceptance) at a 1735 node that is a custodial node of the bundle identified in the 1736 custody signal, custody of the bundle MUST be released as described 1737 in Section 5.10.2. 1739 5.12. Custody Transfer Failure 1741 Custody transfer is determined to have failed at a custodial node 1742 for a given bundle when either (a) that node's custody transfer 1743 timer for that bundle (if any) expires or (b) a custody signal of 1744 type 1 (custody refusal) for that bundle is received at that node. 1746 Upon determination of custody transfer failure due to expiration of 1747 a custody transfer countdown timer, the bundle protocol agent MUST 1748 re-forward the bundle, possibly on a different route (Section 5.4). 1750 Upon determination of custody transfer failure due to reception of a 1751 custody signal of type 1 (custody refusal), the action taken by the 1752 bundle protocol agent is implementation-specific and may depend on 1753 the reason code cited for the refusal. For example, if the custody 1754 signal's reason code was "Depleted storage", the bundle protocol 1755 agent might choose to re-forward the bundle, possibly on a different 1756 route (Section 5.4). If the reason code was "Redundant reception", 1757 on the other hand, this might cause the bundle protocol agent to 1758 release custody of the bundle and to revise its algorithm for 1759 computing countdown intervals for custody transfer timers. 1761 5.13. Custody Transfer Deferral 1763 Upon receipt of a bundle for which custody transfer retransmission 1764 service has been requested, which the bundle protocol agent plans to 1765 forward but for which it elects not to accept custody, the bundle 1766 protocol agent SHOULD generate a custody signal of type 2 (custody 1767 delegation) for the bundle, destined for the bundle's current 1768 custodian(s). 1770 Custody transfer is determined to have been deferred at a custodial 1771 node for given bundle when a custody signal of type 2 (custody 1772 delegation) for that bundle is received at that node. The action 1773 taken by the bundle protocol agent in this event is implementation- 1774 specific. Notionally, this is an opportunity for the bundle 1775 protocol agent to revise its retransmission timeout interval for 1776 this bundle, based on the information provided in the custody 1777 signal: the next candidate custodian for the bundle is now known, 1778 and the minimum length of time before a custody acceptance signal 1779 will arrive can now be adjusted accordingly. 1781 5.14. Bundle Deletion 1783 The steps in deleting a bundle are: 1785 Step 1: If the retention constraint "Custody accepted" currently 1786 prevents this bundle from being discarded, then: 1788 . Custody of the bundle is released as described in Section 1789 5.10.2. 1790 . A bundle deletion status report citing the reason for deletion 1791 MUST be generated, destined for the bundle's report-to endpoint 1792 ID. 1794 Otherwise, if the "request reporting of bundle deletion" flag in the 1795 bundle's status report request field is set to 1, then a bundle 1796 deletion status report citing the reason for deletion SHOULD be 1797 generated, destined for the bundle's report-to endpoint ID. 1799 Step 2: All of the bundle's retention constraints MUST be removed. 1801 5.15. Discarding a Bundle 1803 As soon as a bundle has no remaining retention constraints it MAY be 1804 discarded, thereby releasing any persistent storage that may have 1805 been allocated to it. 1807 5.16. Canceling a Transmission 1809 When requested to cancel a specified transmission, where the bundle 1810 created upon initiation of the indicated transmission has not yet 1811 been discarded, the bundle protocol agent MUST delete that bundle 1812 for the reason "transmission cancelled". For this purpose, the 1813 procedure defined in Section 5.14 MUST be followed. 1815 6. Administrative Record Processing 1817 6.1. Administrative Records 1819 Administrative records are standard application data units that are 1820 used in providing some of the features of the Bundle Protocol. Two 1821 types of administrative records have been defined to date: bundle 1822 status reports and custody signals. Note that additional types of 1823 administrative records may be defined by supplementary DTN protocol 1824 specification documents. 1826 Every administrative record consists of: 1828 . Record type code (an unsigned integer for which valid values 1829 are as defined below). 1830 . Record content in type-specific format. 1832 Valid administrative record type codes are defined as follows: 1834 +---------+--------------------------------------------+ 1836 | Value | Meaning | 1838 +=========+============================================+ 1840 | 1 | Bundle status report. | 1842 +---------+--------------------------------------------+ 1844 | 2 | Custody signal. | 1846 +---------+--------------------------------------------+ 1848 | (other) | Reserved for future use. | 1850 +---------+--------------------------------------------+ 1852 Figure 3: Administrative Record Type Codes 1854 Each BP administrative record SHALL be represented as a CBOR array 1855 (major type 4) with additional info 2 indicating that the item is a 1856 2-tuple. 1858 The first item of the array SHALL be a record type code, which SHALL 1859 be represented as a CBOR unsigned integer. 1861 The second element of this array SHALL be the applicable CBOR 1862 representation of the content of the record. Details of the CBOR 1863 representation of administrative record types 1 and 2 are provided 1864 below. Details of the CBOR representation of other types of 1865 administrative record type are included in the specifications 1866 defining those records. 1868 6.1.1. Bundle Status Reports 1870 The transmission of "bundle status reports" under specified 1871 conditions is an option that can be invoked when transmission of a 1872 bundle is requested. These reports are intended to provide 1873 information about how bundles are progressing through the system, 1874 including notices of receipt, custody transfer, forwarding, final 1875 delivery, and deletion. They are transmitted to the Report-to 1876 endpoints of bundles. 1878 Each bundle status report SHALL be represented as a CBOR array 1879 (major type 4) with additional info either 6 (if the subject bundle 1880 is a fragment) or 4 (otherwise). 1882 The first item of the bundle status report array SHALL be bundle 1883 status information represented as a CBOR array (major type 4) with 1884 additional info 5. The five items of the bundle status information 1885 array shall provide information on the following five status 1886 assertions, in this order: 1888 . Reporting node received bundle. 1889 . Reporting node accepted custody of bundle. 1890 . Reporting node forwarded the bundle. 1891 . Reporting node delivered the bundle. 1892 . Reporting node deleted the bundle. 1894 Each item of the bundle status information array SHALL be a bundle 1895 status item represented as a CBOR array (major type 4) with 1896 additional info either 2 (if the value of the first item of this 1897 bundle status item is 1 AND the "Report status time" flag was set to 1898 1 in the bundle processing flags of the bundle whose status is being 1899 reported) or 1 (otherwise). The first item of the bundle status 1900 item array SHALL be a Boolean value, indicating whether or not the 1901 corresponding bundle status is asserted, represented as a CBOR 1902 unsigned integer. The second item of the bundle status item array, 1903 if present, SHALL indicate the time (as reported by the local system 1904 clock, an implementation matter) at which the indicated condition 1905 became true for this bundle, represented as a DTN time as described 1906 in Section 4.1.6. above. 1908 The second item of the bundle status report array SHALL be the 1909 bundle status report reason code explaining the values of the status 1910 flags, represented as a CBOR unsigned integer. Valid status report 1911 reason codes are defined in Figure 4 below but the list of status 1912 report reason codes provided here is neither exhaustive nor 1913 exclusive; supplementary DTN protocol specifications (including, but 1914 not restricted to, the Bundle Security Protocol [BPSEC]) may define 1915 additional reason codes. 1917 +---------+--------------------------------------------+ 1919 | Value | Meaning | 1921 +=========+============================================+ 1923 | 0 | No additional information. | 1925 +---------+--------------------------------------------+ 1927 | 1 | Lifetime expired. | 1929 +---------+--------------------------------------------+ 1931 | 2 | Forwarded over unidirectional link. | 1933 +---------+--------------------------------------------+ 1935 | 3 | Transmission canceled. | 1937 +---------+--------------------------------------------+ 1939 | 4 | Depleted storage. | 1941 +---------+--------------------------------------------+ 1943 | 5 | Destination endpoint ID unintelligible. | 1945 +---------+--------------------------------------------+ 1947 | 6 | No known route to destination from here. | 1949 +---------+--------------------------------------------+ 1951 | 7 | No timely contact with next node on route. | 1953 +---------+--------------------------------------------+ 1954 | 8 | Block unintelligible. | 1956 +---------+--------------------------------------------+ 1958 | (other) | Reserved for future use. | 1960 +---------+--------------------------------------------+ 1962 Figure 4: Status Report Reason Codes 1964 The third item of the bundle status report array SHALL be the source 1965 node ID identifying the source of the bundle whose status is being 1966 reported, represented as described in Section 4.1.5.2. above. 1968 The fourth item of the bundle status report array SHALL be the 1969 creation timestamp of the bundle whose status is being reported, 1970 represented as described in Section 4.1.7. above. 1972 The fifth item of the bundle status report array SHALL be present if 1973 and only if the bundle whose status is being reported contained a 1974 fragment ID. If present, it SHALL be the subject bundle's fragment 1975 ID represented as described in Section 4.1.8. above. 1977 The sixth item of the bundle status report array SHALL be present if 1978 and only if the bundle whose status is being reported contained a 1979 fragment ID. If present, it SHALL be the length of the subject 1980 bundle's payload represented as a CBOR unsigned integer item. 1982 6.1.2. Custody Signals 1984 Custody signals are administrative records that effect custody 1985 transfer operations. They are transmitted to the nodes that are the 1986 current custodians of bundles. 1988 Each custody signal SHALL be represented as a CBOR array (major type 1989 4) with additional info either 6 (if the subject bundle is a 1990 fragment) or 4 (otherwise). 1992 The first item of the custody signal array SHALL be a signal type 1993 code represented as a CBOR unsigned integer. Valid custody signal 1994 types are defined as follows: 1996 +---------+--------------------------------------------+ 1998 | Value | Meaning | 2000 +=========+============================================+ 2001 | 0 | Custody acceptance. The reporting node | 2003 | | commits to supporting the requested custody| 2005 | | transfer service(s). | 2007 +---------+--------------------------------------------+ 2009 | 1 | Custody refusal. Applicable only when | 2011 | | rerouting service is requested. 2013 +---------+--------------------------------------------+ 2015 | 2 | Custody delegation: the bundle will be | 2017 | | forwarded but custody was not taken. | 2019 | | Applicable only when retransmission | 2021 | | service is requested. | 2023 +---------+--------------------------------------------+ 2025 | (other) | Reserved for future use. | 2027 +---------+--------------------------------------------+ 2029 Figure 5: Custody Signal Type Codes 2031 The second item of the custody signal array SHALL be additional 2032 information amplifying the signal type code, represented as a CBOR 2033 array (major type 4) with additional info either 2 (if the signal 2034 type is 2) or 1 (otherwise). 2036 When signal type is 0 or 1, the sole item in the additional 2037 information array SHALL be a custody signal reason code, represented 2038 as a CBOR unsigned integer. Valid custody signal reason codes are 2039 defined as follows: 2041 +---------+--------------------------------------------+ 2043 | Value | Meaning | 2045 +=========+============================================+ 2047 | 0 | No additional information. | 2048 +---------+--------------------------------------------+ 2050 | 1 | Reserved for future use. | 2052 +---------+--------------------------------------------+ 2054 | 2 | Reserved for future use. | 2056 +---------+--------------------------------------------+ 2058 | 3 | Redundant (reception by a node that is a | 2060 | | custodial node for this bundle). | 2062 +---------+--------------------------------------------+ 2064 | 4 | Depleted storage. | 2066 +---------+--------------------------------------------+ 2068 | 5 | Destination endpoint ID unintelligible. | 2070 +---------+--------------------------------------------+ 2072 | 6 | No known route destination from here. | 2074 +---------+--------------------------------------------+ 2076 | 7 | No timely contact with next node on route. | 2078 +---------+--------------------------------------------+ 2080 | 8 | Block unintelligible. | 2082 +---------+--------------------------------------------+ 2084 | (other) | Reserved for future use. | 2086 +---------+--------------------------------------------+ 2088 Figure 6: Custody Signal Reason Codes 2090 When signal type is 2, the first item in the additional information 2091 array SHALL be the node ID of the node to which the reporting node 2092 anticipates forwarding the bundle, represented as described in 2093 Section 4.1.5.2. above, and the second item in this array SHALL be 2094 an estimate of the number of seconds that will have elapsed since 2095 reception of the bundle before the anticipated forwarding begins, 2096 represented as a CBOR unsigned integer. 2098 The third item of the custody signal array SHALL be the source node 2099 ID identifying the source of the bundle for which custodial activity 2100 is being reported, represented as described in Section 4.1.5.2. 2101 above. 2103 The fourth item of the custody signal array SHALL be the creation 2104 timestamp of the bundle for which custodial activity is being 2105 reported, represented as described in Section 4.1.7. above. 2107 The fifth item of the custody signal array SHALL be present if and 2108 only if the bundle for which custodial activity is being reported 2109 contained a fragment ID. If present, it SHALL be the subject 2110 bundle's fragment ID represented as described in Section 4.1.8. 2111 above. 2113 The sixth item of the custody signal array SHALL be present if and 2114 only if the bundle for which custodial activity is being reported 2115 contained a fragment ID. If present, it SHALL be the length of the 2116 subject bundle's payload represented as a CBOR unsigned integer 2117 item. 2119 6.2. Generation of Administrative Records 2121 Whenever the application agent's administrative element is directed 2122 by the bundle protocol agent to generate an administrative record 2123 with reference to some bundle, the following procedure must be 2124 followed: 2126 Step 1: The administrative record must be constructed. If the 2127 referenced bundle is a fragment, the administrative record MUST 2128 contain the fragment ID and fragment length. 2130 Step 2: A request for transmission of a bundle whose payload is this 2131 administrative record MUST be presented to the bundle protocol 2132 agent. 2134 6.3. Reception of Custody Signals 2136 For each received custody signal that has signal type zero (custody 2137 acceptance), the administrative element of the application agent 2138 MUST direct the bundle protocol agent to follow the custody transfer 2139 success procedure in Section 5.11. 2141 For each received custody signal that has signal type 1 (custody 2142 refusal), the administrative element of the application agent MUST 2143 direct the bundle protocol agent to follow the custody transfer 2144 failure procedure in Section 5.12. 2146 For each received custody signal that has signal type 2 (custody 2147 delegation), the administrative element of the application agent 2148 MUST direct the bundle protocol agent to follow the custody 2149 delegation procedure in Section 5.13. 2151 7. Services Required of the Convergence Layer 2153 7.1. The Convergence Layer 2155 The successful operation of the end-to-end bundle protocol depends 2156 on the operation of underlying protocols at what is termed the 2157 "convergence layer"; these protocols accomplish communication 2158 between nodes. A wide variety of protocols may serve this purpose, 2159 so long as each convergence layer protocol adapter provides a 2160 defined minimal set of services to the bundle protocol agent. This 2161 convergence layer service specification enumerates those services. 2163 7.2. Summary of Convergence Layer Services 2165 Each convergence layer protocol adapter is expected to provide the 2166 following services to the bundle protocol agent: 2168 . sending a bundle to a bundle node that is reachable via the 2169 convergence layer protocol; 2170 . delivering to the bundle protocol agent a bundle that was sent 2171 by a bundle node via the convergence layer protocol. 2173 The convergence layer service interface specified here is neither 2174 exhaustive nor exclusive. That is, supplementary DTN protocol 2175 specifications (including, but not restricted to, the Bundle 2176 Security Protocol [BPSEC]) may expect convergence layer adapters 2177 that serve BP implementations conforming to those protocols to 2178 provide additional services such as reporting on the transmission 2179 and/or reception progress of individual bundles (at completion 2180 and/or incrementally), retransmitting data that were lost in 2181 transit, discarding bundle-conveying data units that the convergence 2182 layer protocol determines are corrupt or inauthentic, or reporting 2183 on the integrity and/or authenticity of delivered bundles. 2185 8. Security Considerations 2187 The bundle protocol has taken security into concern from the outset 2188 of its design. It was always assumed that security services would be 2189 needed in the use of the bundle protocol. As a result, the bundle 2190 protocol security architecture and the available security services 2191 are specified in an accompanying document, the Bundle Security 2192 Protocol specification [BPSEC]; an informative overview of this 2193 architecture is provided in [SECO]. 2195 The bundle protocol has been designed with the notion that it may be 2196 run over networks with scarce resources. For example, the networks 2197 might have limited bandwidth, limited connectivity, constrained 2198 storage in relay nodes, etc. Therefore, the bundle protocol must 2199 ensure that only those entities authorized to send bundles over such 2200 constrained environments are actually allowed to do so. All 2201 unauthorized entities should be prevented from consuming valuable 2202 resources as soon as practicable. 2204 Likewise, because of the potentially high latencies and delays 2205 involved in the networks that make use of the bundle protocol, data 2206 sources should be concerned with the integrity of the data received 2207 at the intended destination(s) and may also be concerned with 2208 ensuring confidentiality of the data as it traverses the network. 2209 Without integrity, the bundle payload data might be corrupted while 2210 in transit without the destination able to detect it. Similarly, the 2211 data source can be concerned with ensuring that the data can only be 2212 used by those authorized, hence the need for confidentiality. 2214 Internal to the bundle-aware overlay network, the bundle nodes 2215 should be concerned with the authenticity of other bundle nodes as 2216 well as the preservation of bundle payload data integrity as it is 2217 forwarded between bundle nodes. 2219 As a result, bundle security is concerned with the authenticity, 2220 integrity, and confidentiality of bundles conveyed among bundle 2221 nodes. This is accomplished via the use of two independent security- 2222 specific bundle blocks, which may be used together to provide 2223 multiple bundle security services or independently of one another, 2224 depending on perceived security threats, mandated security 2225 requirements, and security policies that must be enforced. 2227 To provide end-to-end bundle authenticity and integrity, the Block 2228 Integrity Block (BIB) is used. The BIB allows any security-enabled 2229 entity along the delivery path to ensure the integrity of the 2230 bundle's payload or any other block other than a Block 2231 Confidentiality Block. 2233 To provide payload confidentiality, the use of the Block 2234 Confidentiality Block (BCB) is available. The bundle payload, or any 2235 other block aside from the primary block and the Bundle Security 2236 Protocol blocks, may be encrypted to provide end-to-end payload 2237 confidentiality/privacy. 2239 Additionally, convergence-layer protocols that ensure authenticity 2240 of communication between adjacent nodes in BP network topology 2241 SHOULD be used where available, to minimize the ability of 2242 unauthenticated nodes to introduce inauthentic traffic into the 2243 network. 2245 Bundle security MUST NOT be invalidated by forwarding nodes even 2246 though they themselves might not use the Bundle Security Protocol. 2248 In particular, while blocks MAY be added to bundles transiting 2249 intermediate nodes, removal of blocks with the 'Discard block if it 2250 can't be processed' flag set in the block processing control flags 2251 may cause security to fail. 2253 Inclusion of the Bundle Security Protocol in any Bundle Protocol 2254 implementation is RECOMMENDED. Use of the Bundle Security Protocol 2255 in Bundle Protocol operations is OPTIONAL. 2257 9. IANA Considerations 2259 The "dtn" and "ipn" URI schemes have been provisionally registered 2260 by IANA. See http://www.iana.org/assignments/uri-schemes.html for 2261 the latest details. 2263 Registries of URI scheme type numbers, extension block type numbers, 2264 and administrative record type numbers will be required. 2266 10. References 2268 10.1. Normative References 2270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2271 Requirement Levels", BCP 14, RFC 2119, March 1997. 2273 [RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object 2274 Representation (CBOR)", RFC 7049, October 2013. 2276 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2277 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 2278 January 2005. 2280 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2281 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 2282 2015. 2284 10.2. Informative References 2286 [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 2287 4838, April 2007. 2289 [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work 2290 In Progress, October 2015. 2292 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 2293 Identifiers (IRIs)", RFC 3987, January 2005. 2295 [RFC5050] Scott, M. and S. Burleigh, "Bundle Protocol 2296 Specification", RFC 5050, November 2007. 2298 [SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay- 2299 Tolerant Networking Security Overview", Work Progress, July 2007. 2301 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 2302 Challenged Internets", SIGCOMM 2003. 2304 [TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A Tutorial", 2305 . 2307 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 2308 historical background and perspectives" in "Journees systemes de 2309 reference spatio-temporels", 2004. 2311 11. Acknowledgments 2313 This work is freely adapted from [RFC5050], which was an effort of 2314 the Delay Tolerant Networking Research Group. The following DTNRG 2315 participants contributed significant technical material and/or 2316 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 2317 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 2318 Michael Demmer of the University of California at Berkeley, Robert 2319 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 2320 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 2321 College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of 2322 Ohio University, and Howard Weiss of SPARTA, Inc. 2324 This document was prepared using 2-Word-v2.0.template.dot. 2326 12. Significant Changes from RFC 5050 2328 Points on which this draft significantly differs from RFC 5050 2329 include the following: 2331 . Clarify the difference between transmission and forwarding. 2332 . Amplify discussion of custody transfer. Move current custodian 2333 to an extension block, of which there can be multiple 2334 occurrences (possible support for the MITRE idea of multiple 2335 concurrent custodians, from several years ago); define that 2336 block in this specification. 2337 . Introduce the concept of "node ID" as functionally distinct 2338 from endpoint ID, while having the same syntax. 2339 . Restructure primary block, making it immutable. Add optional 2340 CRC. 2341 . Add optional CRCs to non-primary blocks. 2342 . Add block ID number to canonical block format (to support 2343 streamlined BSP). 2344 . Add bundle age extension block, defined in this specification. 2345 . Add previous node extension block, defined in this 2346 specification. 2347 . Add flow label extension block, *not* defined in this 2348 specification. 2349 . Add manifest extension block, *not* defined in this 2350 specification. 2351 . Add hop count extension block, defined in this specification. 2352 . Clean up a conflict between fragmentation and custody transfer 2353 that Ed Birrane pointed out. 2355 Appendix A. For More Information 2357 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 2358 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 2360 Copyright (c) 2016 IETF Trust and the persons identified as authors 2361 of the code. All rights reserved. 2363 Redistribution and use in source and binary forms, with or without 2364 modification, is permitted pursuant to, and subject to the license 2365 terms contained in, the Simplified BSD License set forth in Section 2366 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2367 (http://trustee.ietf.org/license-info). 2369 Authors' Addresses 2371 Scott Burleigh 2372 Jet Propulsion Laboratory, California Institute of Technology 2373 4800 Oak Grove Dr. 2374 Pasadena, CA 91109-8099 2375 US 2376 Phone: +1 818 393 3353 2377 Email: Scott.Burleigh@jpl.nasa.gov 2379 Kevin Fall 2380 Carnegie Mellon University / Software Engineering Institute 2381 4500 Fifth Avenue 2382 Pittsburgh, PA 15213 2383 US 2384 Phone: +1 412 268 3304 2385 Email: kfall@cmu.edu 2387 Edward J. Birrane 2388 Johns Hopkins University Applied Physics Laboratory 2389 11100 Johns Hopkins Rd 2390 Laurel, MD 20723 2391 US 2392 Phone: +1 443 778 7423 2393 Email: Edward.Birrane@jhuapl.edu