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