idnits 2.17.1 draft-ietf-dtn-bpbis-04.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 (July 5, 2016) is 2853 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) No issues found here. Summary: 0 errors (**), 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: January 2017 Carnegie Mellon University / SEI 5 E. Birrane 6 APL, Johns Hopkins University 7 July 5, 2016 9 Bundle Protocol 10 draft-ietf-dtn-bpbis-04.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 January 6, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 This Internet Draft presents a specification for Bundle Protocol, 53 adapted from the experimental Bundle Protocol specification 54 developed by the Delay-Tolerant Networking Research group of the 55 Internet Research Task Force and documented in RFC 5050. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Conventions used in this document..............................5 61 3. Service Description............................................5 62 3.1. Definitions...............................................5 63 3.2. Discussion of BP concepts.................................9 64 3.3. Services Offered by Bundle Protocol Agents...............14 65 4. Bundle Format.................................................14 66 4.1. CRC Type.................................................15 67 4.2. Bundle Processing Control Flags..........................15 68 4.3. Block Processing Control Flags...........................16 69 4.4. Identifiers..............................................17 70 4.4.1. Endpoint ID.........................................17 71 4.4.2. Node ID.............................................17 72 4.5. Contents of Bundle Blocks................................18 73 4.5.1. Primary Bundle Block................................18 74 4.5.2. Canonical Bundle Block Format.......................20 75 4.6. Extension Blocks.........................................21 76 4.6.1. Current Custodian...................................21 77 4.6.2. Previous Node.......................................21 78 4.6.3. Bundle Age..........................................22 79 4.6.4. Hop Count...........................................22 80 5. Bundle Processing.............................................22 81 5.1. Generation of Administrative Records.....................23 82 5.2. Bundle Transmission......................................24 83 5.3. Bundle Dispatching.......................................24 84 5.4. Bundle Forwarding........................................24 85 5.4.1. Forwarding Contraindicated..........................26 86 5.4.2. Forwarding Failed...................................27 87 5.5. Bundle Expiration........................................27 88 5.6. Bundle Reception.........................................28 89 5.7. Local Bundle Delivery....................................29 90 5.8. Bundle Fragmentation.....................................30 91 5.9. Application Data Unit Reassembly.........................31 92 5.10. Custody Transfer........................................31 93 5.10.1. Custody Acceptance.................................32 94 5.10.2. Custody Release....................................32 95 5.11. Custody Transfer Success................................33 96 5.12. Custody Transfer Failure................................33 97 5.13. Bundle Deletion.........................................33 98 5.14. Discarding a Bundle.....................................34 99 5.15. Canceling a Transmission................................34 100 6. Administrative Record Processing..............................34 101 6.1. Administrative Records...................................34 102 6.1.1. Bundle Status Reports...............................35 103 6.1.2. Custody Signals.....................................37 104 6.2. Generation of Administrative Records.....................38 105 6.3. Reception of Custody Signals.............................39 106 7. Services Required of the Convergence Layer....................39 107 7.1. The Convergence Layer....................................39 108 7.2. Summary of Convergence Layer Services....................39 109 8. Security Considerations.......................................40 110 9. IANA Considerations...........................................41 111 10. References...................................................42 112 10.1. Normative References....................................42 113 10.2. Informative References..................................42 114 11. Acknowledgments..............................................42 115 12. Significant Changes from RFC 5050............................43 116 Appendix A. For More Information.................................44 118 1. Introduction 120 Since the publication of the Bundle Protocol Specification 121 (Experimental RFC 5050[RFC5050]) in 2007, the Delay-Tolerant 122 Networking Bundle Protocol has been implemented in multiple 123 programming languages and deployed to a wide variety of computing 124 platforms for a wide range of successful exercises. This 125 implementation and deployment experience has demonstrated the 126 general utility of the protocol for challenged network operations. 128 It has also, as expected, identified opportunities for making the 129 protocol simpler, more capable, and easier to use. The present 130 document, standardizing the Bundle Protocol (BP), is adapted from 131 RFC 5050 in that context. 133 This document describes version 7 of BP. 135 Delay Tolerant Networking is a network architecture providing 136 communications in and/or through highly stressed environments. 137 Stressed networking environments include those with intermittent 138 connectivity, large and/or variable delays, and high bit error 139 rates. To provide its services, BP may be viewed as sitting at the 140 application layer of some number of constituent networks, forming a 141 store-carry-forward overlay network. Key capabilities of BP 142 include: 144 . Custodial forwarding 145 . Ability to cope with intermittent connectivity, including cases 146 where the sender and receiver are not concurrently present in 147 the network 148 . Ability to take advantage of scheduled, predicted, and 149 opportunistic connectivity, whether bidirectional or 150 unidirectional, in addition to continuous connectivity 151 . Late binding of overlay network endpoint identifiers to 152 underlying constituent network addresses 154 For descriptions of these capabilities and the rationale for the DTN 155 architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial- 156 level overview of DTN concepts. 158 BP's location within the standard protocol stack is as shown in 159 Figure 1. BP uses underlying "native" transport and/or network 160 protocols for communications within a given constituent network. 162 The interface between the bundle protocol and a specific underlying 163 protocol is termed a "convergence layer adapter". 165 Figure 1 shows three distinct transport and network protocols 166 (denoted T1/N1, T2/N2, and T3/N3). 168 +-----------+ +-----------+ 169 | BP app | | BP app | 170 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 171 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 172 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 173 | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | 174 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 175 | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | 176 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 177 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 178 +-----------+ +-------------+ +-------------+ +-----------+ 179 | | | | 180 |<---- A network ---->| |<---- A network ---->| 181 | | | | 183 Figure 1: The Bundle Protocol in the Protocol Stack Model 185 This document describes the protocol data units (called "bundles") 186 passed between entities participating in BP communications. 188 The entities are referred to as "bundle nodes". This document does 189 not address: 191 . Operations in the convergence layer adapters that bundle nodes 192 use to transport data through specific types of internets. 193 (However, the document does discuss the services that must be 194 provided by each adapter at the convergence layer.) 195 . The bundle route computation algorithm. 196 . Mechanisms for populating the routing or forwarding information 197 bases of bundle nodes. 198 . The mechanisms for securing bundles en route. 199 . The mechanisms for managing bundle nodes. 201 2. Conventions used in this document 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in RFC-2119 [RFC2119]. 207 In this document, these words will appear with that interpretation 208 only when in ALL CAPS. Lower case uses of these words are not to be 209 interpreted as carrying RFC-2119 significance. 211 3. Service Description 213 3.1. Definitions 215 Bundle - A bundle is a protocol data unit of BP, so named because 216 negotiation of the parameters of a data exchange may be impractical 217 in a delay-tolerant network: it is often better practice to "bundle" 218 with a unit of data all metadata that might be needed in order to 219 make the data immediately usable when delivered to applications. 220 Each bundle comprises a sequence of two or more "blocks" of protocol 221 data, which serve various purposes. 223 Block - A bundle protocol block is one of the protocol data 224 structures that together constitute a well-formed bundle. 226 Bundle payload - A bundle payload (or simply "payload") is the 227 application data whose conveyance to the bundle's destination is the 228 purpose for the transmission of a given bundle; it is the content of 229 the bundle's payload block. The terms "bundle content", "bundle 230 payload", and "payload" are used interchangeably in this document. 232 Partial payload - A partial payload is a payload that comprises 233 either the first N bytes or the last N bytes of some other payload 234 of length M, such that 0 < N < M. 236 Fragment - A fragment is a bundle whose payload block contains a 237 partial payload. 239 Bundle node - A bundle node (or, in the context of this document, 240 simply a "node") is any entity that can send and/or receive bundles. 241 Each bundle node has three conceptual components, defined below, as 242 shown in Figure 2: a "bundle protocol agent", a set of zero or more 243 "convergence layer adapters", and an "application agent". 245 +-----------------------------------------------------------+ 246 |Node | 247 | | 248 | +-------------------------------------------------------+ | 249 | |Application Agent | | 250 | | | | 251 | | +--------------------------+ +----------------------+ | | 252 | | |Administrative element | |Application-specific | | | 253 | | | | |element | | | 254 | | | | | | | | 255 | | +--------------------------+ +----------------------+ | | 256 | | ^ ^ | | 257 | | Admin|records Application|data | | 258 | | | | | | 259 | +----------------v--------------------------v-----------+ | 260 | ^ | 261 | | ADUs | 262 | | | 263 | +-----------------------------v-------------------------+ | 264 | |Bundle Protocol Agent | | 265 | | | | 266 | | | | 267 | +-------------------------------------------------------+ | 268 | ^ ^ ^ | 269 | | Bundles | Bundles Bundles | | 270 | | | | | 271 | +------v-----+ +-----v------+ +-----v-----+ | 272 | |CLA 1 | |CLA 2 | |CLA n | | 273 | | | | | . . . | | | 274 | | | | | | | | 275 +-+------------+-----+------------+-----------+-----------+-+ 276 ^ ^ ^ 277 CL1|PDUs CL2|PDUs CLn|PDUs 278 | | | 279 +------v-----+ +-----v------+ +-----v-----+ 280 Network 1 Network 2 Network n 282 Figure 2: Components of a BP Node 284 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 285 the node component that offers the BP services and executes the 286 procedures of the bundle protocol. 288 Convergence layer adapter - A convergence layer adapter (CLA) is a 289 node component that sends and receives bundles on behalf of the BPA, 290 utilizing the services of some 'native' protocol stack that is 291 supported in one of the networks within which the node is 292 functionally located. 294 Application agent - The application agent (AA) of a node is the node 295 component that utilizes the BP services to effect communication for 296 some user purpose. The application agent in turn has two elements, 297 an administrative element and an application-specific element. 299 Application-specific element - The application-specific element of 300 an AA is the node component that constructs, requests transmission 301 of, accepts delivery of, and processes units of user application 302 data. 304 Administrative element - The administrative element of an AA is the 305 node component that constructs and requests transmission of 306 administrative records (defined below), including status reports and 307 custody signals, and accepts delivery of and processes any custody 308 signals that the node receives. 310 Administrative record - A BP administrative record is an application 311 data unit that is exchanged between the administrative elements of 312 nodes' application agents for some BP administrative purpose. The 313 formats of some fundamental administrative records (and of no other 314 application data units) are defined in this specification. 316 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 317 of zero or more bundle nodes that all identify themselves for BP 318 purposes by some common identifier, called a "bundle endpoint ID" 319 (or, in this document, simply "endpoint ID"; endpoint IDs are 320 described in detail in Section 4.3.1 below). 322 Singleton endpoint - A singleton endpoint is an endpoint that always 323 contains exactly one member. 325 Registration - A registration is the state machine characterizing a 326 given node's membership in a given endpoint. Any single 327 registration has an associated delivery failure action as defined 328 below and must at any time be in one of two states: Active or 329 Passive. 331 Delivery - A bundle is considered to have been delivered at a node 332 subject to a registration as soon as the application data unit that 333 is the payload of the bundle, together with any relevant metadata 334 (an implementation matter), has been presented to the node's 335 application agent in a manner consistent with the state of that 336 registration. 338 Deliverability - A bundle is considered "deliverable" subject to a 339 registration if and only if (a) the bundle's destination endpoint is 340 the endpoint with which the registration is associated, (b) the 341 bundle has not yet been delivered subject to this registration, and 342 (c) the bundle has not yet been "abandoned" (as defined below) 343 subject to this registration. 345 Abandonment - To abandon a bundle subject to some registration is to 346 assert that the bundle is not deliverable subject to that 347 registration. 349 Delivery failure action - The delivery failure action of a 350 registration is the action that is to be taken when a bundle that is 351 "deliverable" subject to that registration is received at a time 352 when the registration is in the Passive state. 354 Destination - The destination of a bundle is the endpoint comprising 355 the node(s) at which the bundle is to be delivered (as defined 356 below). 358 Minimum reception group - The minimum reception group of an endpoint 359 is the minimum number of members of the endpoint (nodes) at which 360 the bundle must have been delivered in order for the bundle to be 361 considered delivered to the endpoint. 363 Transmission - A transmission is an attempt by a node's BPA to cause 364 copies of a bundle to be delivered at all nodes in the minimum 365 reception group of some endpoint (the bundle's destination) in 366 response to a transmission request issued by the node's application 367 agent. 369 Forwarding - To forward a bundle to a node is to invoke the services 370 of a CLA in a sustained effort to cause a copy of the bundle to be 371 received by that node. 373 Discarding - To discard a bundle is to cease all operations on the 374 bundle and functionally erase all references to it. The specific 375 procedures by which this is accomplished are an implementation 376 matter. 378 Retention constraint - A retention constraint is an element of the 379 state of a bundle that prevents the bundle from being discarded. 380 That is, a bundle cannot be discarded while it has any retention 381 constraints. 383 Deletion - To delete a bundle is to remove unconditionally all of 384 the bundle's retention constraints, enabling the bundle to be 385 discarded. 387 Custodian - A custodian of a bundle is a node that has determined 388 that it will retain a copy of that bundle for an indefinite period 389 of time, forwarding and possibly re-forwarding the bundle as 390 appropriate, until it detects one of the conditions under which it 391 may cease being a custodian of that bundle (discussed later). 393 Taking custody - To take custody of a bundle is to become a 394 custodian of that bundle. 396 Accepting custody - To accept custody of a bundle is to take custody 397 of the bundle, mark the bundle in such a way as to indicate this 398 custodianship to nodes that subsequently receive copies of the 399 bundle, and announce this custodianship to all current custodians of 400 the bundle. 402 Refusing custody - To "refuse custody" of a bundle is to notify all 403 current custodians of that bundle that an opportunity to take 404 custody of the bundle has been declined. 406 Releasing custody - To release custody of a bundle is to cease to be 407 a custodian of the bundle. 409 3.2. Discussion of BP concepts 411 Multiple instances of the same bundle (the same unit of DTN protocol 412 data) might exist concurrently in different parts of a network -- 413 possibly in different representations and/or differing in some 414 blocks -- in the memory local to one or more bundle nodes and/or in 415 transit between nodes. In the context of the operation of a bundle 416 node, a bundle is an instance (copy), in that node's local memory, 417 of some bundle that is in the network. 419 The payload for a bundle forwarded in response to a bundle 420 transmission request is the application data unit whose location is 421 provided as a parameter to that request. The payload for a bundle 422 forwarded in response to reception of a bundle is the payload of the 423 received bundle. 425 In the most familiar case, a bundle node is instantiated as a single 426 process running on a general-purpose computer, but in general the 427 definition is meant to be broader: a bundle node might alternatively 428 be a thread, an object in an object-oriented operating system, a 429 special-purpose hardware device, etc. 431 The manner in which the functions of the BPA are performed is wholly 432 an implementation matter. For example, BPA functionality might be 433 coded into each node individually; it might be implemented as a 434 shared library that is used in common by any number of bundle nodes 435 on a single computer; it might be implemented as a daemon whose 436 services are invoked via inter-process or network communication by 437 any number of bundle nodes on one or more computers; it might be 438 implemented in hardware. 440 Every CLA implements its own thin layer of protocol, interposed 441 between BP and the (usually "top") protocol(s) of the underlying 442 native protocol stack; this "CL protocol" may only serve to 443 multiplex and de-multiplex bundles to and from the underlying native 444 protocol, or it may offer additional CL-specific functionality. The 445 manner in which a CLA sends and receives bundles is, again, wholly 446 an implementation matter. The definitions of CLAs and CL protocols 447 are beyond the scope of this specification. 449 Note that the administrative element of a node's application agent 450 may itself, in some cases, function as a convergence-layer adapter. 451 That is, outgoing bundles may be "tunneled" through encapsulating 452 bundles: 454 . An outgoing bundle that has been encoded in some documented 455 representation constitutes a byte array. This byte array may, 456 like any other, be presented to the bundle protocol agent as an 457 application data unit that is to be transmitted to some 458 endpoint. 459 . The original encoded bundle thus forms the payload of an 460 encapsulating bundle that is forwarded using some other 461 convergence-layer protocol(s). 462 . When the encapsulating bundle is received, its payload is 463 delivered to the peer application agent administrative element, 464 which then instructs the bundle protocol agent to dispatch that 465 original encoded bundle in the usual way. 467 The purposes for which this technique may be useful (such as cross- 468 domain security) are beyond the scope of this specification. 470 The only interface between the BPA and the application-specific 471 element of the AA is the BP service interface. But between the BPA 472 and the administrative element of the AA there is a (conceptual) 473 private control interface in addition to the BP service interface. 474 This private control interface enables the BPA and the 475 administrative element of the AA to direct each other to take action 476 under specific circumstances 478 In the case of a node that serves simply as a BP "router", the AA 479 may have no application-specific element at all. The application- 480 specific elements of other nodes' AAs may perform arbitrarily 481 complex application functions, perhaps even offering multiplexed DTN 482 communication services to a number of other applications. As with 483 the BPA, the manner in which the AA performs its functions is wholly 484 an implementation matter. 486 Singletons are the most familiar sort of endpoint, but in general 487 the endpoint notion is meant to be broader. For example, the nodes 488 in a sensor network might constitute a set of bundle nodes that 489 identify themselves by a single common endpoint ID and thus form a 490 single bundle endpoint. *Note* too that a given bundle node might 491 identify itself by multiple endpoint IDs and thus be a member of 492 multiple bundle endpoints. 494 The destination of every bundle is an endpoint, which may or may not 495 be singleton. The source of every bundle is a node, identified by 496 the endpoint ID for some singleton endpoint that contains that node. 498 The minimum reception group of an endpoint may be any one of the 499 following: (a) ALL of the nodes registered in an endpoint that is 500 permitted to contain multiple nodes (in which case forwarding to the 501 endpoint is functionally similar to "multicast" operations in the 502 Internet, though possibly very different in implementation); (b) ANY 503 N of the nodes registered in an endpoint that is permitted to 504 contain multiple nodes, where N is in the range from zero to the 505 cardinality of the endpoint; or (c) THE SOLE NODE registered in a 506 singleton endpoint (in which case forwarding to the endpoint is 507 functionally similar to "unicast" operations in the Internet). 509 The nature of the minimum reception group for a given endpoint can 510 typically be determined from the endpoint's ID. For some endpoint 511 ID "schemes", the nature of the minimum reception group is fixed - 512 in a manner that is defined by the scheme - for all endpoints 513 identified under the scheme. For other schemes, the nature of the 514 minimum reception group is indicated by some lexical feature of the 515 "scheme-specific part" of the endpoint ID, in a manner that is 516 defined by the scheme. 518 Any number of transmissions may be concurrently undertaken by the 519 bundle protocol agent of a given node. 521 When the bundle protocol agent of a node determines that a bundle 522 must be forwarded to a node (either to a node that is a member of 523 the bundle's destination endpoint or to some intermediate forwarding 524 node) in the course of completing the successful transmission of 525 that bundle, it invokes the services of a CLA in a sustained effort 526 to cause a copy of the bundle to be received by that node. 528 Upon reception, the processing of a bundle that has been received by 529 a given node depends on whether or not the receiving node is 530 registered in the bundle's destination endpoint. If it is, and if 531 the payload of the bundle is non-fragmentary (possibly as a result 532 of successful payload reassembly from fragmentary payloads, 533 including the original payload of the newly received bundle), then 534 the bundle is normally delivered to the node's application agent 535 subject to the registration characterizing the node's membership in 536 the destination endpoint. 538 Whenever, for some implementation-specific reason, a node's BPA 539 finds it impossible to immediately deliver a bundle that is 540 deliverable, delivery of the bundle has failed. In this event, the 541 delivery failure action associated with the applicable registration 542 must be taken. Delivery failure action MUST be one of the following: 544 . defer delivery of the bundle subject to this registration until 545 (a) this bundle is the least recently received of all bundles 546 currently deliverable subject to this registration and (b) 547 either the registration is polled or else the registration is 548 in the Active state; or 550 . abandon delivery of the bundle subject to this registration. 552 An additional implementation-specific delivery deferral procedure 553 MAY optionally be associated with the registration. 555 While the state of a registration is Passive, reception of a bundle 556 that is deliverable subject to this registration MUST cause delivery 557 of the bundle to be abandoned or deferred as mandated by the 558 registration's current delivery failure action; in the latter case, 559 any additional delivery deferral procedure associated with the 560 registration MUST also be performed. 562 While the state of a registration is Active, reception of a bundle 563 that is deliverable subject to this registration MUST cause the 564 bundle to be delivered automatically as soon as it is the next 565 bundle that is due for delivery according to the BPA's bundle 566 delivery scheduling policy, an implementation matter. 568 Normally only registrations' registered delivery failure actions 569 cause deliveries to be abandoned. 571 Custody of a bundle MAY be taken only if the destination of the 572 bundle is a singleton endpoint. Custody MAY be released only when 573 either (a) notification is received that some other node has 574 accepted custody of the same bundle; (b) notification is received 575 that the bundle has been delivered at the (sole) node registered in 576 the bundle's destination endpoint; (c) the current custodian chooses 577 to fragment the bundle, releasing custody of the original bundle and 578 taking custody of the fragments instead, or (d) the bundle is 579 explicitly deleted for some reason, such as lifetime expiration. 581 The custody transfer mechanism in BP serves two purposes. 583 First, it provides a means of ensuring bundle delivery at the 584 destination node. When the custodian of a bundle forwards that 585 bundle it SHOULD set a retransmission timer; upon expiration of that 586 timer, absent reception of a responding custody acceptance or 587 refusal signal from a downstream node, the custodian MUST re-forward 588 the bundle. Computation of the timeout interval for a bundle's 589 custodial retransmission timer (i.e., determination of the moment at 590 which a responding custody signal is expected) is an implementation 591 matter and may be dynamically responsive to changes in connectivity. 592 In some environments it may be impossible to compute this interval 593 with operationally satisfactory accuracy; in such environments the 594 use of custody transfer to ensure bundle delivery at the destination 595 node is contraindicated. 597 Second, it provides a means of optimizing recovery from forwarding 598 failures. When a bundle for which custody has been taken arrives at 599 a node from which it must be forwarded, but forwarding is 600 impossible, the receiving node SHOULD send a custody refusal signal 601 to the current custodian node, causing the custodian to re-forward 602 the bundle on a different path. 604 Alternatively, when custody transfer for a given bundle is not 605 requested: 607 . Delivery of the bundle at the destination node can be ensured 608 by utilizing reliable convergence-layer protocols between 609 neighbors on all segments of the end-to-end path. This 610 approach may make more efficient use of links than custody 611 transfer because a convergence-layer protocol may perform 612 finer-grained retransmission than custody transfer does, 613 retransmitting only the specific portions of a transmitted 614 bundle that were not received, rather than the entire bundle. 615 However, in some environments there may be segments of the end- 616 to-end path for which no reliable convergence-layer protocol is 617 available; in such environments the use of reliable 618 convergence-layer protocols wherever possible can minimize the 619 incidence of data loss but bundle delivery at the destination 620 node cannot be ensured. 621 . Recovery from a forwarding failure can be accomplished by 622 "returning" the bundle back toward some node for forwarding 623 along some other path in the network. 625 3.3. Services Offered by Bundle Protocol Agents 627 The BPA of each node is expected to provide the following services 628 to the node's application agent: 630 . commencing a registration (registering the node in an 631 endpoint); 632 . terminating a registration; 633 . switching a registration between Active and Passive states; 634 . transmitting a bundle to an identified bundle endpoint; 635 . canceling a transmission; 636 . polling a registration that is in the Passive state; 637 . delivering a received bundle. 639 4. Bundle Format 641 NOTE that only the abstract structures of blocks are defined here. 642 The specific bitstream that is emitted when a CLA sends a bundle 643 will be dictated by the applicable bundle representation 644 specification to which the sending and receiving nodes conform, an 645 implementation matter. Support for alternative bitstream 646 representations of bundles is intended to enable BP to operate in as 647 wide a range of application environments as possible, with 648 interoperability enabled at gateways by straightforward mechanical 649 translation between representations. It is important to note that 650 not all BP implementations are required to implement all bundle 651 representation specifications. The BP implementations used to 652 instantiate nodes in a given network must be chosen with care in 653 order for every node to be able to exchange bundles with every other 654 node. Bundle representation specifications are beyond the scope of 655 this document. 657 Each bundle SHALL be a concatenated sequence of at least two blocks. 658 The first block in the sequence MUST be a primary bundle block, and 659 the bundle MUST have exactly one primary bundle block. Additional 660 bundle protocol blocks of other types MAY follow the primary block 661 to support extensions to the bundle protocol, such as the Bundle 662 Security Protocol [BPSEC]. Exactly one of the blocks in the sequence 663 MUST be a payload block, and the payload block MUST be the last 664 block in the sequence. 666 4.1. CRC Type 668 CRC type is an unsigned integer type code for which the following 669 values (and no others) are valid: 671 . 0 indicates "no CRC is present." 672 . 1 indicates "a CRC-16 (a.k.a., CRC-16-ANSI) is present." 673 . 2 indicates "a CRC-32 is present." 675 4.2. Bundle Processing Control Flags 677 Bundle processing control flags assert properties of the bundle as a 678 whole rather than of any particular block of the bundle. They are 679 conveyed in the primary block of the bundle. 681 The following properties are asserted by the bundle processing 682 control flags: 684 . The bundle is a fragment. (Boolean) 686 . The bundle's payload is an administrative record. (Boolean) 688 . The bundle must not be fragmented. (Boolean) 690 . Custody transfer is requested for this bundle. (Boolean) 692 . The bundle's destination endpoint is a singleton. (Boolean) 694 . Acknowledgment by the user application is requested. (Boolean) 696 . Status time is requested in all status reports. (Boolean) 698 . The bundle contains a "manifest" extension block. (Boolean) 700 . Flags requesting types of status reports (all Boolean): 702 o Request reporting of bundle reception. 704 o Request reporting of custody acceptance. 706 o Request reporting of bundle forwarding. 708 o Request reporting of bundle delivery. 710 o Request reporting of bundle deletion. 712 If the bundle processing control flags indicate that the bundle's 713 application data unit is an administrative record, then the custody 714 transfer requested flag value must be zero and all status report 715 request flag values must be zero. 717 If the custody transfer requested flag is 1, then the source node is 718 requesting that every receiving node accept custody of the bundle. 720 If the bundle's source node is omitted (i.e., the source node ID is 721 the ID of the null endpoint, which has no members as discussed 722 below; this option enables anonymous bundle transmission), then the 723 bundle is not uniquely identifiable and all bundle protocol features 724 that rely on bundle identity must therefore be disabled: the 725 bundle's custody transfer requested flag value must be zero, the 726 "Bundle must not be fragmented" flag value must be 1, and all status 727 report request flag values must be zero. 729 4.3. Block Processing Control Flags 731 The block processing control flags assert properties of individual 732 bundle blocks other than the primary block. They are conveyed in 733 the header of the block to which they pertain. 735 The following properties are asserted by the block processing 736 control flags: 738 . This block must be replicated in every fragment. (Boolean) 740 . Status report must be transmitted if this block can't be 741 processed. (Boolean) 743 . Block must be removed from the bundle if it can't be processed. 744 (Boolean) 746 . Bundle must be deleted if this block can't be processed. 747 (Boolean) 749 For each bundle whose bundle processing control flags indicate that 750 the bundle's application data unit is an administrative record, or 751 whose source node ID is the null endpoint ID, the value of the 752 "Transmit status report if block can't be processed" flag in every 753 block of the bundle other than the primary block must be zero. 755 4.4. Identifiers 757 4.4.1. Endpoint ID 759 The destinations of bundles are bundle endpoints, identified by text 760 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 761 (EID) conveyed in any bundle block takes the form of a Uniform 762 Resource Identifier (URI; [URI]). As such, each endpoint ID can be 763 characterized as having this general structure: 765 < scheme name > : < scheme-specific part, or "SSP" > 767 The scheme identified by the < scheme name > in an endpoint ID is a 768 set of syntactic and semantic rules that fully explain how to parse 769 and interpret the SSP. The set of allowable schemes is effectively 770 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 771 protocol endpoint ID. 773 Note that, although endpoint IDs are URIs, implementations of the BP 774 service interface may support expression of endpoint IDs in some 775 internationalized manner (e.g., Internationalized Resource 776 Identifiers (IRIs); see [RFC3987]). 778 Note also that the representation of an EID in the bitstream that is 779 emitted when a CLA sends a bundle will be dictated by the applicable 780 bundle representation specification to which the sending and 781 receiving nodes conform, an implementation matter. 783 The endpoint ID "dtn:none" identifies the "null endpoint", the 784 endpoint that by definition never has any members. 786 4.4.2. Node ID 788 For many purposes of the Bundle Protocol it is important to identify 789 the node that is operative in some context. 791 As discussed in 3.1 above, nodes are distinct from endpoints; 792 specifically, an endpoint is a set of zero or more nodes. But 793 rather than define a separate namespace for node identifiers, we 794 instead use endpoint identifiers to identify nodes, subject to the 795 following restrictions: 797 . Every node MUST be a member of at least one singleton endpoint. 799 . The EID of any singleton endpoint of which a node is a member 800 MAY be used to identify that node. A "node ID" is an EID that 801 is used in this way. 802 . A node's membership in a given singleton endpoint MUST be 803 sustained at least until the nominal operation of the Bundle 804 Protocol no longer depends on the identification of that node 805 using that endpoint's ID. 807 4.5. Contents of Bundle Blocks 809 This section describes the contents of the primary block in detail 810 and the contents of all non-primary blocks in general. Rules for 811 processing these blocks appear in Section 5 of this document. 813 Note that supplementary DTN protocol specifications (including, but 814 not restricted to, the Bundle Security Protocol [BPSEC]) may require 815 that BP implementations conforming to those protocols construct and 816 process additional blocks. 818 4.5.1. Primary Bundle Block 820 The primary bundle block contains the basic information needed to 821 forward bundles to their destinations. The fields of the primary 822 bundle block are: 824 Version: An unsigned integer value indicating the version of the 825 bundle protocol that constructed this block. The present document 826 describes version 7 of the bundle protocol. 828 Bundle Processing Control Flags: The Bundle Processing Control Flags 829 are discussed in Section 4.2 above. 831 CRC Type: CRC Type codes are discussed in Section 4.1 above. 833 Destination EID: The Destination EID field identifies the bundle 834 endpoint that is the bundle's destination, i.e., the endpoint that 835 contains the node(s) at which the bundle is to be delivered. 837 Source node ID: The Source node ID field identifies the bundle node 838 at which the bundle was initially transmitted, except that Source 839 node ID may be the null endpoint ID in the event that the bundle's 840 source chooses to remain anonymous. 842 Report-to EID: The Report-to EID field identifies the bundle 843 endpoint to which status reports pertaining to the forwarding and 844 delivery of this bundle are to be transmitted. 846 Creation Timestamp: The creation timestamp is a pair of unsigned 847 integers that, together with the source node ID and (if the bundle 848 is a fragment) the fragment offset and payload length, serve to 849 identify the bundle. The first of these integers is the bundle's 850 creation time, while the second is the bundle's creation timestamp 851 sequence number. Bundle creation time is the time - expressed in 852 seconds since the start of the year 2000, on the Coordinated 853 Universal Time (UTC) scale [UTC] - at which the transmission request 854 was received that resulted in the creation of the bundle. Sequence 855 count is the latest value (as of the time at which that transmission 856 request was received) of a monotonically increasing positive integer 857 counter managed by the source node's bundle protocol agent that may 858 be reset to zero whenever the current time advances by one second. 859 For nodes that lack accurate clocks (that is, nodes that are not at 860 all moments able to determine the current UTC time to within 30 861 seconds), bundle creation time MUST be set to zero and the counter 862 used as the source of the bundle sequence count MUST NEVER be reset 863 to zero. In any case, a source Bundle Protocol Agent must never 864 create two distinct bundles with the same source node ID and bundle 865 creation timestamp. The combination of source node ID and bundle 866 creation timestamp serves to identify a single transmission request, 867 enabling it to be acknowledged by the receiving application 868 (provided the source node ID is not the null endpoint ID). 870 Lifetime: The lifetime field is an unsigned integer that indicates 871 the time at which the bundle's payload will no longer be useful, 872 encoded as a number of seconds past the creation time. When a 873 bundle's age exceeds its lifetime, bundle nodes need no longer 874 retain or forward the bundle; the bundle SHOULD be deleted from the 875 network. 877 Fragment Offset: If the Bundle Processing Control Flags of this 878 Primary block indicate that the bundle is a fragment, then the 879 Fragment Offset field SHALL be an unsigned integer indicating the 880 offset from the start of the original application data unit at which 881 the bytes comprising the payload of this bundle were located. If 882 not, then the Fragment Offset field SHALL be omitted from the block. 884 Total Application Data Unit Length: If the Bundle Processing Control 885 Flags of this Primary block indicate that the bundle is a fragment, 886 then the Total Application Data Unit Length field SHALL be an 887 unsigned integer indicating the total length of the original 888 application data unit of which this bundle's payload is a part. If 889 not, then the Total Application Data Unit Length field SHALL be 890 omitted from the block. 892 If and only if the value of the CRC type field of this Primary block 893 is non-zero, a CRC SHALL be present in the primary block. The 894 length and nature of the CRC SHALL be as indicated by the CRC type. 895 The CRC SHALL be computed over the concatenation of all bytes of the 896 primary block including the CRC field itself, which for this purpose 897 is temporarily populated with the value zero. 899 4.5.2. Canonical Bundle Block Format 901 Every bundle block of every type other than the primary bundle block 902 SHALL comprise the following fields: 904 . Block type code, an unsigned integer. Bundle block type code 1 905 indicates that the block is a bundle payload block. Block type 906 codes 2 through 9 are explicitly reserved as noted later in 907 this specification. Block type codes 192 through 255 are not 908 reserved and are available for private and/or experimental use. 909 All other block type code values are reserved for future use. 910 . Block number, an unsigned integer. The block number uniquely 911 identifies the block within the bundle, enabling blocks 912 (notably bundle security protocol blocks) to explicitly 913 reference other blocks in the same bundle. Block numbers need 914 not be in continuous sequence, and blocks need not appear in 915 block number sequence in the bundle. The block number of the 916 payload block is always zero. 917 . Block processing control flags as discussed in Section 4.3 918 above. 919 . CRC type as discussed in Section 4.1 above. 920 . If and only if the value of the CRC type field of this block is 921 non-zero, a CRC. If present, the length and nature of the CRC 922 SHALL be as indicated by the CRC type and the CRC SHALL be 923 computed over the concatenation of all bytes of the block 924 including the CRC field itself, which for this purpose is 925 temporarily populated with the value zero. 926 . Block data length, an unsigned integer. The block data length 927 field SHALL contain the aggregate length of all remaining 928 fields of the block, i.e., the block-type-specific data fields. 929 . Block-type-specific data fields, whose nature and order are 930 type-specific and whose aggregate length in octets is the value 931 of the block data length field. For the Payload Block in 932 particular (block type 1), there SHALL be exactly one block- 933 type-specific data field, the "payload", i.e., the application 934 data carried by this bundle. 936 4.6. Extension Blocks 938 "Extension blocks" are all blocks other than the primary and payload 939 blocks. Because not all extension blocks are defined in the Bundle 940 Protocol specification (the present document), not all nodes 941 conforming to this specification will necessarily instantiate Bundle 942 Protocol implementations that include procedures for processing 943 (that is, recognizing, parsing, acting on, and/or producing) all 944 extension blocks. It is therefore possible for a node to receive a 945 bundle that includes extension blocks that the node cannot process. 946 The values of the block processing control flags indicate the action 947 to be taken by the bundle protocol agent when this is the case. 949 The following extension blocks are defined in other DTN protocol 950 specification documents as noted: 952 . Block Integrity Block (block type 2) and Block Confidentiality 953 Block (block type 3) are defined in the Bundle Security 954 Protocol specification (work in progress). 955 . Manifest Block (block type 4) is defined in the Manifest 956 Extension Block specification (TBD). The manifest block 957 identifies the blocks that were present in the bundle at the 958 time it was created. The bundle MUST contain one (1) 959 occurrence of this type of block if the value of the "manifest" 960 flag in the bundle processing control flags is 1; otherwise the 961 bundle MUST NOT contain any Manifest block. 962 . The Flow Label Block (block type 6) is defined in the Flow 963 Label Extension Block specification (TBD). The flow label 964 block is intended to govern transmission of the bundle by 965 convergence-layer adapters. 967 The following extension blocks are defined in the current document. 969 4.6.1. Current Custodian 971 The Current Custodian block, block type 5, identifies a node that is 972 known to have accepted custody of the bundle. The block-type- 973 specific data of this block is the node ID of a custodian. The 974 bundle MAY contain one or more occurrences of this type of block. 976 4.6.2. Previous Node 978 The Previous Node block, block type 7, identifies the node that 979 forwarded this bundle to the local node (i.e., to the node at which 980 the bundle currently resides); its block-type-specific data is the 981 node ID of that forwarder node. If the local node is the source of 982 the bundle, then the bundle MUST NOT contain any previous node 983 block. Otherwise the bundle MUST contain one (1) occurrence of this 984 type of block. If present, the previous node block MUST be the 985 FIRST block following the primary block, as the processing of other 986 extension blocks may depend on its value. 988 4.6.3. Bundle Age 990 The Bundle Age block, block type 8, contains the number of seconds 991 that have elapsed between the time the bundle was created and time 992 at which it was most recently forwarded. It is intended for use by 993 nodes lacking access to an accurate clock, to aid in determining the 994 time at which a bundle's lifetime expires. The block-type-specific 995 data of this block is an unsigned integer containing the age of the 996 bundle in seconds. (The age of the bundle is the sum of all known 997 intervals of the bundle's residence at forwarding nodes, up to the 998 time at which the bundle was most recently forwarded, plus the 999 summation of signal propagation time over all episodes of 1000 transmission between forwarding nodes. Determination of these 1001 values is an implementation matter.) If the bundle's creation time 1002 is zero, then the bundle MUST contain exactly one (1) occurrence of 1003 this type of block; otherwise, the bundle MAY contain at most one 1004 (1) occurrence of this type of block. 1006 4.6.4. Hop Count 1008 The Hop Count block, block type 9, contains two unsigned integers, 1009 hop limit and hop count. A "hop" is here defined as an occasion on 1010 which a bundle was forwarded from one node to another node. The hop 1011 count block is mainly intended as a safety mechanism, a means of 1012 identifying bundles for removal from the network that can never be 1013 delivered due to a persistent forwarding error: a bundle SHOULD be 1014 deleted when its hop count exceeds its hop limit. Procedures for 1015 determining the appropriate hop limit for a block are beyond the 1016 scope of this specification. A bundle MAY contain at most one (1) 1017 occurrence of this type of block. 1019 5. Bundle Processing 1021 The bundle processing procedures mandated in this section and in 1022 Section 6 govern the operation of the Bundle Protocol Agent and the 1023 Application Agent administrative element of each bundle node. They 1024 are neither exhaustive nor exclusive. Supplementary DTN protocol 1025 specifications (including, but not restricted to, the Bundle 1026 Security Protocol [BPSEC]) may augment, override, or supersede the 1027 mandates of this document. 1029 5.1. Generation of Administrative Records 1031 All transmission of bundles is in response to bundle transmission 1032 requests presented by nodes' application agents. When required to 1033 "generate" an administrative record (such as a bundle status report 1034 or a custody signal), the bundle protocol agent itself is 1035 responsible for causing a new bundle to be transmitted, conveying 1036 that record. In concept, the bundle protocol agent discharges this 1037 responsibility by directing the administrative element of the node's 1038 application agent to construct the record and request its 1039 transmission as detailed in Section 6 below. In practice, the manner 1040 in which administrative record generation is accomplished is an 1041 implementation matter, provided the constraints noted in Section 6 1042 are observed. 1044 Under some circumstances, the requesting of status reports could 1045 result in an unacceptable increase in the bundle traffic in the 1046 network. For this reason, the generation of status reports is 1047 mandatory only in two cases: 1049 . the reception of a bundle containing at least one block that 1050 cannot be processed, for which the value of the "transmit 1051 status report if block could not be processed" block processing 1052 flag is 1, and 1053 . the deletion of a bundle for which custody transfer is 1054 requested. 1056 In all other cases, the decision on whether or not to generate a 1057 requested status report is left to the discretion of the bundle 1058 protocol agent. Mechanisms that could assist in making such 1059 decisions, such as pre-placed agreements authorizing the generation 1060 of status reports under specified circumstances, are beyond the 1061 scope of this specification. 1063 Notes on administrative record terminology: 1065 . A "bundle reception status report" is a bundle status report 1066 with the "reporting node received bundle" flag set to 1. 1067 . A "custody acceptance status report" is a bundle status report 1068 with the "reporting node accepted custody of bundle" flag set 1069 to 1. 1070 . A "bundle forwarding status report" is a bundle status report 1071 with the "reporting node forwarded the bundle" flag set to 1. 1072 . A "bundle delivery status report" is a bundle status report 1073 with the "reporting node delivered the bundle" flag set to 1. 1074 . A "bundle deletion status report" is a bundle status report 1075 with the "reporting node deleted the bundle" flag set to 1. 1077 . A "Succeeded" custody signal is a custody signal with the 1078 "custody transfer succeeded" flag set to 1. 1079 . A "Failed" custody signal is a custody signal with the "custody 1080 transfer succeeded" flag set to zero. 1081 . A "current custodian" of a bundle is a node identified in a 1082 Current Custodian extension block of that bundle. 1084 5.2. Bundle Transmission 1086 The steps in processing a bundle transmission request are: 1088 Step 1: If custody transfer is requested for this bundle 1089 transmission then the destination MUST be a singleton endpoint. If, 1090 moreover, custody acceptance by the source node is required when 1091 custody is requested (an implementation matter) but the conditions 1092 under which custody of the bundle may be accepted are not satisfied, 1093 then the request cannot be honored and all remaining steps of this 1094 procedure MUST be skipped. 1096 Step 2: Transmission of the bundle is initiated. An outbound bundle 1097 MUST be created per the parameters of the bundle transmission 1098 request, with the retention constraint "Dispatch pending". The 1099 source node ID of the bundle MUST be either the null endpoint ID, 1100 indicating that the source of the bundle is anonymous, or else the 1101 EID of a singleton endpoint whose only member is the node of which 1102 the BPA is a component. 1104 Step 3: Processing proceeds from Step 1 of Section 5.4. 1106 5.3. Bundle Dispatching 1108 The steps in dispatching a bundle are: 1110 Step 1: If the bundle's destination endpoint is an endpoint of which 1111 the node is a member, the bundle delivery procedure defined in 1112 Section 5.7 MUST be followed. 1114 Step 2: Processing proceeds from Step 1 of Section 5.4. 1116 5.4. Bundle Forwarding 1118 The steps in forwarding a bundle are: 1120 Step 1: The retention constraint "Forward pending" MUST be added to 1121 the bundle, and the bundle's "Dispatch pending" retention constraint 1122 MUST be removed. 1124 Step 2: The bundle protocol agent MUST determine whether or not 1125 forwarding is contraindicated for any of the reasons listed in 1126 Figure 4. In particular: 1128 . The bundle protocol agent MUST determine which node(s) to 1129 forward the bundle to. The bundle protocol agent MAY choose 1130 either to forward the bundle directly to its destination 1131 node(s) (if possible) or to forward the bundle to some other 1132 node(s) for further forwarding. The manner in which this 1133 decision is made may depend on the scheme name in the 1134 destination endpoint ID and/or on other state but in any case 1135 is beyond the scope of this document. If the BPA elects to 1136 forward the bundle to some other node(s) for further forwarding 1137 but finds it impossible to select any node(s) to forward the 1138 bundle to, then forwarding is contraindicated. 1139 . Provided the bundle protocol agent succeeded in selecting the 1140 node(s) to forward the bundle to, the bundle protocol agent 1141 MUST select the convergence layer adapter(s) whose services 1142 will enable the node to send the bundle to those nodes. The 1143 manner in which specific appropriate convergence layer adapters 1144 are selected is beyond the scope of this document. If the agent 1145 finds it impossible to select any appropriate convergence layer 1146 adapter(s) to use in forwarding this bundle, then forwarding is 1147 contraindicated. 1148 . Provided the bundle protocol agent succeeded in selecting the 1149 node(s) to forward the bundle to and additionally succeeded in 1150 selecting the appropriate convergence layer adapter(s), the 1151 bundle protocol agent MUST determine the applicable bundle 1152 representation by which the bundle must be encoded when sent to 1153 each such node so that the bundle will be intelligible when 1154 received by that node. The manner in which applicable bundle 1155 representations are selected is beyond the scope of this 1156 document. If the agent finds that there are no applicable 1157 bundle representations for any of the nodes to which the bundle 1158 is to be sent, then forwarding is contraindicated. 1160 Step 3: If forwarding of the bundle is determined to be 1161 contraindicated for any of the reasons listed in Figure 4, then the 1162 Forwarding Contraindicated procedure defined in Section 5.4.1 MUST 1163 be followed; the remaining steps of Section 5 are skipped at this 1164 time. 1166 Step 4: If the bundle's custody transfer requested flag (in the 1167 bundle processing flags field) is set to 1, then the custody 1168 transfer procedure defined in Section 5.10 MUST be followed. 1170 Step 5: For each node selected for forwarding, the bundle protocol 1171 agent MUST encode the bundle in the selected applicable 1172 representation(s) and then invoke the services of the selected 1173 convergence layer adapter(s) in order to effect the sending of the 1174 bundle to that node. Determining the time at which the bundle 1175 protocol agent invokes convergence layer adapter services is a BPA 1176 implementation matter. Determining the time at which each 1177 convergence layer adapter subsequently responds to this service 1178 invocation by sending the bundle is a convergence-layer adapter 1179 implementation matter. Note that: 1181 . If the bundle contains a flow label extension block then that 1182 flow label value MAY identify procedures for determining the 1183 order in which convergence layer adapters must send bundles, 1184 e.g., considering bundle source when determining the order in 1185 which bundles are sent. The definition of such procedures is 1186 beyond the scope of this specification. 1187 . If the bundle has a bundle age block, then at the last possible 1188 moment before the CLA initiates conveyance of the bundle node 1189 via the CL protocol the bundle age value MUST be increased by 1190 the difference between the current time and the time at which 1191 the bundle was received (or, if the local node is the source of 1192 the bundle, created). 1194 Step 6: When all selected convergence layer adapters have informed 1195 the bundle protocol agent that they have concluded their data 1196 sending procedures with regard to this bundle: 1198 . If the "request reporting of bundle forwarding" flag in the 1199 bundle's status report request field is set to 1, then a bundle 1200 forwarding status report SHOULD be generated, destined for the 1201 bundle's report-to endpoint ID. If the bundle has the retention 1202 constraint "custody accepted" and all of the nodes to which the 1203 bundle was forwarded are known to be unable to send bundles 1204 back to this node, then the reason code on this bundle 1205 forwarding status report MUST be "forwarded over unidirectional 1206 link"; otherwise, the reason code MUST be "no additional 1207 information". 1208 . The bundle's "Forward pending" retention constraint MUST be 1209 removed. 1211 5.4.1. Forwarding Contraindicated 1213 The steps in responding to contraindication of forwarding are: 1215 Step 1: The bundle protocol agent MUST determine whether or not to 1216 declare failure in forwarding the bundle. Note: this decision is 1217 likely to be influenced by the reason for which forwarding is 1218 contraindicated. 1220 Step 2: If forwarding failure is declared, then the Forwarding 1221 Failed procedure defined in Section 5.4.2 MUST be followed. 1223 Otherwise, (a) if the bundle's custody transfer requested flag (in 1224 the bundle processing flags field) is set to 1, then the custody 1225 transfer procedure defined in Section 5.10 MUST be followed; (b) 1226 when -- at some future time - the forwarding of this bundle ceases 1227 to be contraindicated, processing proceeds from Step 5 of Section 1228 5.4. 1230 5.4.2. Forwarding Failed 1232 The steps in responding to a declaration of forwarding failure are: 1234 Step 1: If the bundle's custody transfer requested flag (in the 1235 bundle processing flags field) is set to 1, custody transfer failure 1236 must be handled. The bundle protocol agent MUST handle the custody 1237 transfer failure by generating a "Failed" custody signal for the 1238 bundle, destined for the bundle's current custodian(s); the custody 1239 signal MUST contain a reason code corresponding to the reason for 1240 which forwarding was determined to be contraindicated. (Note that 1241 discarding the bundle will not delete it from the network, since 1242 each current custodian still has a copy.) 1244 If the bundle's custody transfer requested flag (in the bundle 1245 processing flags field) is set to 0, then the bundle protocol agent 1246 MAY forward the bundle back to the node that sent it, as identified 1247 by the Previous Node block. 1249 Step 2: If the bundle's destination endpoint is an endpoint of which 1250 the node is a member, then the bundle's "Forward pending" retention 1251 constraint MUST be removed. Otherwise, the bundle MUST be deleted: 1252 the bundle deletion procedure defined in Section 5.13 MUST be 1253 followed, citing the reason for which forwarding was determined to 1254 be contraindicated. 1256 5.5. Bundle Expiration 1258 A bundle expires when the bundle's age exceeds its lifetime as 1259 specified in the primary bundle block. Bundle age MAY be determined 1260 by subtracting the bundle's creation timestamp time from the current 1261 time if (a) that timestamp time is not zero and (b) the local node's 1262 clock is known to be accurate (as discussed in section 4.5.1 above); 1263 otherwise bundle age MUST be obtained from the Bundle Age extension 1264 block. Bundle expiration MAY occur at any point in the processing 1265 of a bundle. When a bundle expires, the bundle protocol agent MUST 1266 delete the bundle for the reason "lifetime expired": the bundle 1267 deletion procedure defined in Section 5.13 MUST be followed. 1269 5.6. Bundle Reception 1271 The steps in processing a bundle that has been received from another 1272 node and decoded from its serialized representation are: 1274 Step 1: The retention constraint "Dispatch pending" MUST be added to 1275 the bundle. 1277 Step 2: If the "request reporting of bundle reception" flag in the 1278 bundle's status report request field is set to 1, then a bundle 1279 reception status report with reason code "No additional information" 1280 SHOULD be generated, destined for the bundle's report-to endpoint 1281 ID. 1283 Step 3: For each block in the bundle that is an extension block that 1284 the bundle protocol agent cannot process: 1286 . If the block processing flags in that block indicate that a 1287 status report is requested in this event, then a bundle 1288 reception status report with reason code "Block unintelligible" 1289 SHOULD be generated, destined for the bundle's report-to 1290 endpoint ID. 1291 . If the block processing flags in that block indicate that the 1292 bundle must be deleted in this event, then the bundle protocol 1293 agent MUST delete the bundle for the reason "Block 1294 unintelligible"; the bundle deletion procedure defined in 1295 Section 5.13 MUST be followed and all remaining steps of the 1296 bundle reception procedure MUST be skipped. 1297 . If the block processing flags in that block do NOT indicate 1298 that the bundle must be deleted in this event but do indicate 1299 that the block must be discarded, then the bundle protocol 1300 agent MUST remove this block from the bundle. 1301 . If the block processing flags in that block indicate neither 1302 that the bundle must be deleted nor that that the block must be 1303 discarded, then processing continues with the next extension 1304 block that the bundle protocol agent cannot process, if any; 1305 otherwise, processing proceeds from step 4. 1307 Step 4: If the bundle's custody transfer requested flag (in the 1308 bundle processing flags field) is set to 1 and the bundle has the 1309 same source node ID, creation timestamp, and (if the bundle is a 1310 fragment) fragment offset and payload length as another bundle that 1311 (a) has not been discarded and (b) currently has the retention 1312 constraint "Custody accepted", custody transfer redundancy MUST be 1313 handled; otherwise, processing proceeds from Step 5. The bundle 1314 protocol agent MUST handle custody transfer redundancy by generating 1315 a "Failed" custody signal for this bundle with reason code 1316 "Redundant reception", destined for this bundle's current custodian, 1317 and removing this bundle's "Dispatch pending" retention constraint. 1319 Step 5: Processing proceeds from Step 1 of Section 5.3. 1321 5.7. Local Bundle Delivery 1323 The steps in processing a bundle that is destined for an endpoint of 1324 which this node is a member are: 1326 Step 1: If the received bundle is a fragment, the application data 1327 unit reassembly procedure described in Section 5.9 MUST be followed. 1328 If this procedure results in reassembly of the entire original 1329 application data unit, processing of this bundle (whose fragmentary 1330 payload has been replaced by the reassembled application data unit) 1331 proceeds from Step 2; otherwise, the retention constraint 1332 "Reassembly pending" MUST be added to the bundle and all remaining 1333 steps of this procedure MUST be skipped. 1335 Step 2: Delivery depends on the state of the registration whose 1336 endpoint ID matches that of the destination of the bundle: 1338 . If the registration is in the Active state, then the bundle 1339 MUST be delivered subject to this registration (see Section 3.1 1340 above) as soon as all previously received bundles that are 1341 deliverable subject to this registration have been delivered. 1342 . If the registration is in the Passive state, then the 1343 registration's delivery failure action MUST be taken (see 1344 Section 3.1 above). 1346 Step 3: As soon as the bundle has been delivered: 1348 . If the "request reporting of bundle delivery" flag in the 1349 bundle's status report request field is set to 1, then a bundle 1350 delivery status report SHOULD be generated, destined for the 1351 bundle's report-to endpoint ID. Note that this status report 1352 only states that the payload has been delivered to the 1353 application agent, not that the application agent has processed 1354 that payload. 1355 . If the bundle's custody transfer requested flag (in the bundle 1356 processing flags field) is set to 1, custodial delivery MUST be 1357 reported. The bundle protocol agent MUST report custodial 1358 delivery by generating a "Succeeded" custody signal for the 1359 bundle, destined for the bundle's current custodian(s). 1361 5.8. Bundle Fragmentation 1363 It may at times be advantageous for bundle protocol agents to reduce 1364 the sizes of bundles in order to forward them. This might be the 1365 case, for example, if a node to which a bundle is to be forwarded is 1366 accessible only via intermittent contacts and no upcoming contact is 1367 long enough to enable the forwarding of the entire bundle. 1369 The size of a bundle can be reduced by "fragmenting" the bundle. To 1370 fragment a bundle whose payload is of size M is to replace it with 1371 two "fragments" -- new bundles with the same source node ID and 1372 creation timestamp as the original bundle -- whose payloads are the 1373 first N and the last (M - N) bytes of the original bundle's payload, 1374 where 0 < N < M. Note that fragments may themselves be fragmented, 1375 so fragmentation may in effect replace the original bundle with more 1376 than two fragments. (However, there is only one 'level' of 1377 fragmentation, as in IP fragmentation.) 1379 Any bundle that has any Current Custodian extension block citing any 1380 node other than the local node MUST NOT be fragmented. This 1381 restriction aside, any bundle whose primary block's bundle 1382 processing flags do NOT indicate that it must not be fragmented MAY 1383 be fragmented at any time, for any purpose, at the discretion of the 1384 bundle protocol agent. 1386 Fragmentation SHALL be constrained as follows: 1388 . The concatenation of the payloads of all fragments produced by 1389 fragmentation MUST always be identical to the payload of the 1390 fragmented bundle (that is, the bundle that is being 1391 fragmented). Note that the payloads of fragments resulting from 1392 different fragmentation episodes, in different parts of the 1393 network, may be overlapping subsets of the fragmented bundle's 1394 payload. 1395 . The primary block of each fragment MUST differ from that of the 1396 fragmented bundle, in that the bundle processing flags of the 1397 fragment MUST indicate that the bundle is a fragment and both 1398 fragment offset and total application data unit length must be 1399 provided. Additionally, the CRC of the fragmented bundle, if 1400 any, MUST be replaced in each fragment by a new CRC computed 1401 for the primary block of that fragment. 1402 . The payload blocks of fragments will differ from that of the 1403 fragmented bundle as noted above. 1405 . If the fragmented bundle is not a fragment or is the fragment 1406 with offset zero, then all extension blocks of the fragmented 1407 bundle MUST be replicated in the fragment whose offset is zero. 1408 . Each of the fragmented bundle's extension blocks whose "Block 1409 must be replicated in every fragment" flag is set to 1 MUST be 1410 replicated in every fragment. 1411 . Beyond these rules, replication of extension blocks in the 1412 fragments is an implementation matter. 1413 . If the local node is a custodian of the fragmented bundle, then 1414 the BPA MUST release custody of the fragmented bundle before 1415 fragmentation occurs and MUST take custody of every fragment. 1417 5.9. Application Data Unit Reassembly 1419 If the concatenation -- as informed by fragment offsets and payload 1420 lengths -- of the payloads of all previously received fragments with 1421 the same source node ID and creation timestamp as this fragment, 1422 together with the payload of this fragment, forms a byte array whose 1423 length is equal to the total application data unit length in the 1424 fragment's primary block, then: 1426 . This byte array -- the reassembled application data unit -- 1427 MUST replace the payload of this fragment. 1428 . The BPA MUST take custody of each fragmentary bundle whose 1429 payload is a subset of the reassembled application data unit, 1430 for which custody transfer is requested but the BPA has not yet 1431 taken custody. 1432 . The BPA MUST then release custody of every fragment whose 1433 payload is a subset of the reassembled application data unit, 1434 for which it has taken custody. 1435 . The "Reassembly pending" retention constraint MUST be removed 1436 from every other fragment whose payload is a subset of the 1437 reassembled application data unit. 1439 Note: reassembly of application data units from fragments occurs at 1440 the nodes that are members of destination endpoints as necessary; an 1441 application data unit MAY also be reassembled at some other node on 1442 the path to the destination. 1444 5.10. Custody Transfer 1446 The decision as to whether or not to accept custody of a bundle is 1447 an implementation matter that may involve both resource and policy 1448 considerations. 1450 If the bundle protocol agent elects to accept custody of the bundle, 1451 then it must follow the custody acceptance procedure defined in 1452 Section 5.10.1. 1454 5.10.1. Custody Acceptance 1456 Procedures for acceptance of custody of a bundle are defined as 1457 follows. 1459 The retention constraint "Custody accepted" MUST be added to the 1460 bundle. 1462 If the "request reporting of custody acceptance" flag in the 1463 bundle's status report request field is set to 1, a custody 1464 acceptance status report SHOULD be generated, destined for the 1465 report-to endpoint ID of the bundle. However, if a bundle reception 1466 status report was generated for this bundle (Step 2 of Section 5.6) 1467 but has not yet been transmitted, then this report SHOULD be 1468 generated by simply turning on the "Reporting node accepted custody 1469 of bundle" flag in that earlier report. 1471 The bundle protocol agent MUST generate a "Succeeded" custody signal 1472 for the bundle, destined for the bundle's current custodian(s). 1474 The bundle protocol agent MUST assert the new current custodian for 1475 the bundle. It does so by deleting all of the bundle's existing 1476 Current Custodian extension blocks and inserting a new Current 1477 Custodian extension block whose value is the node ID of the local 1478 node. 1480 If the value of a custody transfer timer interval for this bundle 1481 can be calculated with operationally satisfactory accuracy, the 1482 bundle protocol agent SHOULD set a custody transfer countdown timer 1483 for the bundle; upon expiration of this timer prior to expiration of 1484 the bundle itself and prior to custody transfer success for this 1485 bundle, the custody transfer failure procedure detailed in Section 1486 5.12 MUST be followed. The manner in which the countdown interval 1487 for such a timer is determined is an implementation matter. 1489 The bundle SHOULD be retained in persistent storage if possible. 1491 5.10.2. Custody Release 1493 When custody of a bundle is released, the "Custody accepted" 1494 retention constraint MUST be removed from the bundle and any custody 1495 transfer timer that has been established for this bundle SHOULD be 1496 destroyed. 1498 5.11. Custody Transfer Success 1500 Upon receipt of a "Succeeded" custody signal at a node that is a 1501 custodial node of the bundle identified in the custody signal, 1502 custody of the bundle MUST be released as described in Section 1503 5.10.2. 1505 5.12. Custody Transfer Failure 1507 Custody transfer is determined to have failed at a custodial node 1508 for that bundle when either (a) that node's custody transfer timer 1509 for that bundle (if any) expires or (b) a "Failed" custody signal 1510 for that bundle is received at that node. 1512 Upon determination of custody transfer failure due to expiration of 1513 a custody transfer countdown timer, the bundle protocol agent MUST 1514 re-forward the bundle, possibly on a different route (Section 5.4). 1516 Upon determination of custody transfer failure due to reception of a 1517 "Failed" custody signal, the action taken by the bundle protocol 1518 agent is implementation-specific and may depend on the nature of the 1519 failure. For example, if custody transfer failure was asserted by a 1520 "Failed" custody signal with the "Depleted storage" reason code, the 1521 bundle protocol agent might choose to re-forward the bundle, 1522 possibly on a different route (Section 5.4). Receipt of a "Failed" 1523 custody signal with the "Redundant reception" reason code, on the 1524 other hand, might cause the bundle protocol agent to release custody 1525 of the bundle and to revise its algorithm for computing countdown 1526 intervals for custody transfer timers. 1528 5.13. Bundle Deletion 1530 The steps in deleting a bundle are: 1532 Step 1: If the retention constraint "Custody accepted" currently 1533 prevents this bundle from being discarded, then: 1535 . Custody of the bundle is released as described in Section 1536 5.10.2. 1537 . A bundle deletion status report citing the reason for deletion 1538 MUST be generated, destined for the bundle's report-to endpoint 1539 ID. 1541 Otherwise, if the "request reporting of bundle deletion" flag in the 1542 bundle's status report request field is set to 1, then a bundle 1543 deletion status report citing the reason for deletion SHOULD be 1544 generated, destined for the bundle's report-to endpoint ID. 1546 Step 2: All of the bundle's retention constraints MUST be removed. 1548 5.14. Discarding a Bundle 1550 As soon as a bundle has no remaining retention constraints it MAY be 1551 discarded, thereby releasing any persistent storage that may have 1552 been allocated to it. 1554 5.15. Canceling a Transmission 1556 When requested to cancel a specified transmission, where the bundle 1557 created upon initiation of the indicated transmission has not yet 1558 been discarded, the bundle protocol agent MUST delete that bundle 1559 for the reason "transmission cancelled". For this purpose, the 1560 procedure defined in Section 5.13 MUST be followed. 1562 6. Administrative Record Processing 1564 6.1. Administrative Records 1566 Administrative records are standard application data units that are 1567 used in providing some of the features of the Bundle Protocol. Two 1568 types of administrative records have been defined to date: bundle 1569 status reports and custody signals. Note that additional types of 1570 administrative records may be defined by supplementary DTN protocol 1571 specification documents. 1573 Every administrative record consists of: 1575 . Record type code (an unsigned integer for which valid values 1576 are as defined below). 1577 . Record content in type-specific format. 1579 Valid administrative record type codes are defined as follows: 1581 +---------+--------------------------------------------+ 1583 | Value | Meaning | 1585 +=========+============================================+ 1587 | 1 | Bundle status report. | 1589 +---------+--------------------------------------------+ 1591 | 2 | Custody signal. | 1592 +---------+--------------------------------------------+ 1594 | (other) | Reserved for future use. | 1596 +---------+--------------------------------------------+ 1598 Figure 3: Administrative Record Type Codes 1600 The contents of the two types of administrative records defined in 1601 the present document are described below. 1603 6.1.1. Bundle Status Reports 1605 The transmission of "bundle status reports" under specified 1606 conditions is an option that can be invoked when transmission of a 1607 bundle is requested. These reports are intended to provide 1608 information about how bundles are progressing through the system, 1609 including notices of receipt, custody transfer, forwarding, final 1610 delivery, and deletion. They are transmitted to the Report-to 1611 endpoints of bundles. 1613 Every bundle status report comprises the following fields, in this 1614 order: 1616 . Status flags. The following conditions are asserted by the 1617 bundle status report status flags (all Boolean): 1618 o Reporting node received bundle. 1619 o Reporting node accepted custody of bundle. 1620 o Reporting node forwarded the bundle. 1621 o Reporting node delivered the bundle. 1622 o Reporting node deleted the bundle. 1623 . Reason code, an unsigned integer explaining the values of the 1624 status flags. Status report reason codes are as defined below, 1625 but the list of status report reason codes provided here is 1626 neither exhaustive nor exclusive; supplementary DTN protocol 1627 specifications (including, but not restricted to, the Bundle 1628 Security Protocol [BPSEC]) may define additional reason codes. 1629 . Status times, one unsigned integer for each condition asserted 1630 by any status flag, indicating the time (as reported by the 1631 local system clock, an implementation matter) at which the 1632 indicated condition became true for this bundle. These fields 1633 are included in the status report if and only if the "Report 1634 status time" flag was set to 1 in the subject bundle's bundle 1635 processing flags. Status time is expressed in seconds since 1636 the start of the year 2000, on the Coordinated Universal Time 1637 (UTC) scale [UTC]. 1639 . Source node, the node ID of the source of the bundle whose 1640 status is being reported. 1641 . Creation timestamp, the creation timestamp of the bundle whose 1642 status is being reported. 1643 . Fragment offset, the fragment offset of the bundle whose status 1644 is being reported (omitted if omitted from the subject bundle's 1645 primary block). 1646 . Fragment length, the length of the payload of the bundle whose 1647 status is being reported (omitted if fragment offset is omitted 1648 from the subject bundle's primary block). 1650 Valid status report reason codes are defined as follows: 1652 +---------+--------------------------------------------+ 1654 | Value | Meaning | 1656 +=========+============================================+ 1658 | 0 | No additional information. | 1660 +---------+--------------------------------------------+ 1662 | 1 | Lifetime expired. | 1664 +---------+--------------------------------------------+ 1666 | 2 | Forwarded over unidirectional link. | 1668 +---------+--------------------------------------------+ 1670 | 3 | Transmission canceled. | 1672 +---------+--------------------------------------------+ 1674 | 4 | Depleted storage. | 1676 +---------+--------------------------------------------+ 1678 | 5 | Destination endpoint ID unintelligible. | 1680 +---------+--------------------------------------------+ 1682 | 6 | No known route to destination from here. | 1684 +---------+--------------------------------------------+ 1685 | 7 | No timely contact with next node on route. | 1687 +---------+--------------------------------------------+ 1689 | 8 | Block unintelligible. | 1691 +---------+--------------------------------------------+ 1693 | (other) | Reserved for future use. | 1695 +---------+--------------------------------------------+ 1697 Figure 4: Status Report Reason Codes 1699 6.1.2. Custody Signals 1701 Custody signals are administrative records that effect custody 1702 transfer operations. They are transmitted to the nodes that are the 1703 current custodians of bundles. 1705 Every custody signal comprises the following fields, in this order: 1707 . "Custody transfer succeeded" flag (Boolean). 1708 . Reason code, an unsigned integer explaining the value of the 1709 "Custody transfer succeeded" flag. Custody signal reason codes 1710 are as defined below. 1711 . Source node, the node ID of the source of the bundle for which 1712 custodial activity is being reported. 1713 . Creation timestamp, the creation timestamp of the bundle for 1714 which custodial activity is being reported. 1715 . Fragment offset, the fragment offset of the bundle for which 1716 custodial activity is being reported (omitted if omitted from 1717 the subject bundle's primary block). 1718 . Fragment length, the length of the payload of the bundle for 1719 which custodial activity is being reported (omitted if fragment 1720 offset is omitted from the subject bundle's primary block). 1722 Valid custody signal reason codes are defined as follows: 1724 +---------+--------------------------------------------+ 1726 | Value | Meaning | 1728 +=========+============================================+ 1730 | 0 | No additional information. | 1731 +---------+--------------------------------------------+ 1733 | 1 | Reserved for future use. | 1735 +---------+--------------------------------------------+ 1737 | 2 | Reserved for future use. | 1739 +---------+--------------------------------------------+ 1741 | 3 | Redundant (reception by a node that is a | 1743 | | custodial node for this bundle). | 1745 +---------+--------------------------------------------+ 1747 | 4 | Depleted storage. | 1749 +---------+--------------------------------------------+ 1751 | 5 | Destination endpoint ID unintelligible. | 1753 +---------+--------------------------------------------+ 1755 | 6 | No known route destination from here. | 1757 +---------+--------------------------------------------+ 1759 | 7 | No timely contact with next node on route. | 1761 +---------+--------------------------------------------+ 1763 | 8 | Block unintelligible. | 1765 +---------+--------------------------------------------+ 1767 | (other) | Reserved for future use. | 1769 +---------+--------------------------------------------+ 1771 Figure 5: Custody Signal Reason Codes 1773 6.2. Generation of Administrative Records 1775 Whenever the application agent's administrative element is directed 1776 by the bundle protocol agent to generate an administrative record 1777 with reference to some bundle, the following procedure must be 1778 followed: 1780 Step 1: The administrative record must be constructed. If the 1781 referenced bundle is a fragment, the administrative record MUST 1782 contain the fragment offset and fragment length. 1784 Step 2: A request for transmission of a bundle whose payload is this 1785 administrative record MUST be presented to the bundle protocol 1786 agent. 1788 6.3. Reception of Custody Signals 1790 For each received custody signal that has the "custody transfer 1791 succeeded" flag set to 1, the administrative element of the 1792 application agent MUST direct the bundle protocol agent to follow 1793 the custody transfer success procedure in Section 5.11. 1795 For each received custody signal that has the "custody transfer 1796 succeeded" flag set to zero, the administrative element of the 1797 application agent MUST direct the bundle protocol agent to follow 1798 the custody transfer failure procedure in Section 5.12. 1800 7. Services Required of the Convergence Layer 1802 7.1. The Convergence Layer 1804 The successful operation of the end-to-end bundle protocol depends 1805 on the operation of underlying protocols at what is termed the 1806 "convergence layer"; these protocols accomplish communication 1807 between nodes. A wide variety of protocols may serve this purpose, 1808 so long as each convergence layer protocol adapter provides a 1809 defined minimal set of services to the bundle protocol agent. This 1810 convergence layer service specification enumerates those services. 1812 7.2. Summary of Convergence Layer Services 1814 Each convergence layer protocol adapter is expected to provide the 1815 following services to the bundle protocol agent: 1817 . sending a bundle to a bundle node that is reachable via the 1818 convergence layer protocol; 1819 . delivering to the bundle protocol agent a bundle that was sent 1820 by a bundle node via the convergence layer protocol. 1822 The convergence layer service interface specified here is neither 1823 exhaustive nor exclusive. That is, supplementary DTN protocol 1824 specifications (including, but not restricted to, the Bundle 1825 Security Protocol [BPSEC]) may expect convergence layer adapters 1826 that serve BP implementations conforming to those protocols to 1827 provide additional services such as reporting on the transmission 1828 and/or reception progress of individual bundles (at completion 1829 and/or incrementally), retransmitting data that were lost in 1830 transit, discarding bundle-conveying data units that the convergence 1831 layer protocol determines are corrupt or inauthentic, or reporting 1832 on the integrity and/or authenticity of delivered bundles. 1834 8. Security Considerations 1836 The bundle protocol has taken security into concern from the outset 1837 of its design. It was always assumed that security services would be 1838 needed in the use of the bundle protocol. As a result, the bundle 1839 protocol security architecture and the available security services 1840 are specified in an accompanying document, the Bundle Security 1841 Protocol specification [BPSEC]; an informative overview of this 1842 architecture is provided in [SECO]. 1844 The bundle protocol has been designed with the notion that it may be 1845 run over networks with scarce resources. For example, the networks 1846 might have limited bandwidth, limited connectivity, constrained 1847 storage in relay nodes, etc. Therefore, the bundle protocol must 1848 ensure that only those entities authorized to send bundles over such 1849 constrained environments are actually allowed to do so. All 1850 unauthorized entities should be prevented from consuming valuable 1851 resources as soon as practicable. 1853 Likewise, because of the potentially high latencies and delays 1854 involved in the networks that make use of the bundle protocol, data 1855 sources should be concerned with the integrity of the data received 1856 at the intended destination(s) and may also be concerned with 1857 ensuring confidentiality of the data as it traverses the network. 1858 Without integrity, the bundle payload data might be corrupted while 1859 in transit without the destination able to detect it. Similarly, the 1860 data source can be concerned with ensuring that the data can only be 1861 used by those authorized, hence the need for confidentiality. 1863 Internal to the bundle-aware overlay network, the bundle nodes 1864 should be concerned with the authenticity of other bundle nodes as 1865 well as the preservation of bundle payload data integrity as it is 1866 forwarded between bundle nodes. 1868 As a result, bundle security is concerned with the authenticity, 1869 integrity, and confidentiality of bundles conveyed among bundle 1870 nodes. This is accomplished via the use of two independent security- 1871 specific bundle blocks, which may be used together to provide 1872 multiple bundle security services or independently of one another, 1873 depending on perceived security threats, mandated security 1874 requirements, and security policies that must be enforced. 1876 To provide end-to-end bundle authenticity and integrity, the Block 1877 Integrity Block (BIB) is used. The BIB allows any security-enabled 1878 entity along the delivery path to ensure the integrity of the 1879 bundle's payload or any other block other than a Block 1880 Confidentiality Block. 1882 To provide payload confidentiality, the use of the Block 1883 Confidentiality Block (BCB) is available. The bundle payload, or any 1884 other block aside from the primary block and the Bundle Security 1885 Protocol blocks, may be encrypted to provide end-to-end payload 1886 confidentiality/privacy. 1888 Additionally, convergence-layer protocols that ensure authenticity 1889 of communication between adjacent nodes in BP network topology 1890 SHOULD be used where available, to minimize the ability of 1891 unauthenticated nodes to introduce inauthentic traffic into the 1892 network. 1894 Bundle security MUST NOT be invalidated by forwarding nodes even 1895 though they themselves might not use the Bundle Security Protocol. 1897 In particular, while blocks MAY be added to bundles transiting 1898 intermediate nodes, removal of blocks with the 'Discard block if it 1899 can't be processed' flag set in the block processing control flags 1900 may cause security to fail. 1902 Inclusion of the Bundle Security Protocol in any Bundle Protocol 1903 implementation is RECOMMENDED. Use of the Bundle Security Protocol 1904 in Bundle Protocol operations is OPTIONAL. 1906 9. IANA Considerations 1908 The "dtn" and "ipn" URI schemes have been provisionally registered 1909 by IANA. See http://www.iana.org/assignments/uri-schemes.html for 1910 the latest details. 1912 Registries of scheme type numbers, extension block type numbers, and 1913 administrative record type numbers will be required. 1915 10. References 1917 10.1. Normative References 1919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1920 Requirement Levels", BCP 14, RFC 2119, March 1997. 1922 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1923 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 1924 January 2005. 1926 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 1927 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 1928 2015. 1930 10.2. Informative References 1932 [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 1933 4838, April 2007. 1935 [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work 1936 In Progress, October 2015. 1938 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1939 Identifiers (IRIs)", RFC 3987, January 2005. 1941 [RFC5050] Scott, M. and S. Burleigh, "Bundle Protocol 1942 Specification", RFC 5050, November 2007. 1944 [SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay- 1945 Tolerant Networking Security Overview", Work Progress, July 2007. 1947 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 1948 Challenged Internets", SIGCOMM 2003. 1950 [TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A Tutorial", 1951 . 1953 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 1954 historical background and perspectives" in "Journees systemes de 1955 reference spatio-temporels", 2004. 1957 11. Acknowledgments 1959 This work is freely adapted from [RFC5050], which was an effort of 1960 the Delay Tolerant Networking Research Group. The following DTNRG 1961 participants contributed significant technical material and/or 1962 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 1963 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 1964 Michael Demmer of the University of California at Berkeley, Robert 1965 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 1966 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 1967 College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of 1968 Ohio University, and Howard Weiss of SPARTA, Inc. 1970 This document was prepared using 2-Word-v2.0.template.dot. 1972 12. Significant Changes from RFC 5050 1974 Points on which this draft significantly differs from RFC 5050 1975 include the following: 1977 . Clarify the difference between transmission and forwarding. 1978 . Amplify discussion of custody transfer. Move current custodian 1979 to an extension block, of which there can be multiple 1980 occurrences (possible support for the MITRE idea of multiple 1981 concurrent custodians, from several years ago); define that 1982 block in this specification. 1983 . Introduce the concept of "node ID" as functionally distinct 1984 from endpoint ID, while having the same syntax. 1985 . Restructure primary block, making it immutable. Add optional 1986 CRC. 1987 . Add optional CRCs to non-primary blocks. 1988 . Add block ID number to canonical block format (to support 1989 streamlined BSP). 1990 . Add bundle age extension block, defined in this specification. 1991 . Add previous node extension block, defined in this 1992 specification. 1993 . Add flow label extension block, *not* defined in this 1994 specification. 1995 . Add manifest extension block, *not* defined in this 1996 specification. 1997 . Add hop count extension block, defined in this specification. 1998 . Clean up a conflict between fragmentation and custody transfer 1999 that Ed Birrane pointed out. 2000 . Remove representation specifications from the document, making 2001 the protocol specification representation-neutral. 2003 Appendix A. For More Information 2005 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 2006 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 2008 Copyright (c) 2016 IETF Trust and the persons identified as authors 2009 of the code. All rights reserved. 2011 Redistribution and use in source and binary forms, with or without 2012 modification, is permitted pursuant to, and subject to the license 2013 terms contained in, the Simplified BSD License set forth in Section 2014 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2015 (http://trustee.ietf.org/license-info). 2017 Authors' Addresses 2019 Scott Burleigh 2020 Jet Propulsion Laboratory, California Institute of Technology 2021 4800 Oak Grove Dr. 2022 Pasadena, CA 91109-8099 2023 US 2024 Phone: +1 818 393 3353 2025 Email: Scott.Burleigh@jpl.nasa.gov 2027 Kevin Fall 2028 Carnegie Mellon University / Software Engineering Institute 2029 4500 Fifth Avenue 2030 Pittsburgh, PA 15213 2031 US 2032 Phone: +1 412 268 3304 2033 Email: kfall@cmu.edu 2035 Edward J. Birrane 2036 Johns Hopkins University Applied Physics Laboratory 2037 11100 Johns Hopkins Rd 2038 Laurel, MD 20723 2039 US 2040 Phone: +1 443 778 7423 2041 Email: Edward.Birrane@jhuapl.edu