idnits 2.17.1 draft-ietf-dtn-bpbis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (November 25, 2015) is 3067 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) == Missing Reference: 'BPSECBSP' is mentioned on line 1667, but not defined == Unused Reference: 'ASN1' is defined on line 1975, 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: December 2015 Carnegie Mellon University / SEI 5 E. Birrane 6 APL, Johns Hopkins University 7 November 25, 2015 9 Bundle Protocol 10 draft-ietf-dtn-bpbis-01.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 May 27, 2016. 47 Copyright Notice 49 Copyright (c) 2015 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.................................9 76 3.3. Services Offered by Bundle Protocol Agents...............15 77 4. Bundle Format.................................................15 78 4.1. Bundle Processing Control Flags..........................16 79 4.2. Block Processing Control Flags...........................17 80 4.3. Identifiers..............................................18 81 4.3.1. Endpoint ID.........................................18 82 4.3.2. Node ID.............................................18 83 4.4. Contents of Bundle Blocks................................19 84 4.4.1. Primary Bundle Block................................19 85 4.4.2. Canonical Bundle Block Format.......................21 86 4.5. Extension Blocks.........................................22 87 4.5.1. Current Custodian...................................22 88 4.5.2. Flow Label..........................................22 89 4.5.3. Previous Node ID....................................22 90 4.5.4. Bundle Age..........................................23 91 4.5.5. Hop Count...........................................23 92 5. Bundle Processing.............................................23 93 5.1. Generation of Administrative Records.....................23 94 5.2. Bundle Transmission......................................24 95 5.3. Bundle Dispatching.......................................25 96 5.4. Bundle Forwarding........................................25 97 5.4.1. Forwarding Contraindicated..........................28 98 5.4.2. Forwarding Failed...................................28 99 5.5. Bundle Expiration........................................29 100 5.6. Bundle Reception.........................................29 101 5.7. Local Bundle Delivery....................................30 102 5.8. Bundle Fragmentation.....................................31 103 5.9. Application Data Unit Reassembly.........................32 104 5.10. Custody Transfer........................................33 105 5.10.1. Custody Acceptance.................................33 106 5.10.2. Custody Release....................................34 107 5.11. Custody Transfer Success................................34 108 5.12. Custody Transfer Failure................................34 109 5.13. Bundle Deletion.........................................34 110 5.14. Discarding a Bundle.....................................35 111 5.15. Canceling a Transmission................................35 112 6. Administrative Record Processing..............................35 113 6.1. Administrative Records...................................35 114 6.1.1. Bundle Status Reports...............................36 115 6.1.2. Custody Signals.....................................38 116 6.2. Generation of Administrative Records.....................40 117 6.3. Reception of Custody Signals.............................40 118 7. Services Required of the Convergence Layer....................40 119 7.1. The Convergence Layer....................................40 120 7.2. Summary of Convergence Layer Services....................40 121 8. Security Considerations.......................................41 122 9. IANA Considerations...........................................42 123 10. References...................................................43 124 10.1. Normative References....................................43 125 10.2. Informative References..................................43 126 11. Acknowledgments..............................................44 127 12. Significant Changes from RFC 5050............................44 128 13. Open Issues..................................................45 129 13.1. Application Agent.......................................45 130 13.2. Primary block CRC type..................................45 131 Appendix A. For More Information.................................47 133 1. Introduction 135 Since the publication of the Bundle Protocol Specification 136 (Experimental RFC 5050[RFC5050]) in 2007, the Delay-Tolerant 137 Networking Bundle Protocol has been implemented in multiple 138 programming languages and deployed to a wide variety of computing 139 platforms for a wide range of successful exercises. This 140 implementation and deployment experience has demonstrated the 141 general utility of the protocol for challenged network operations. 143 It has also, as expected, identified opportunities for making the 144 protocol simpler, more capable, and easier to use. The present 145 document, standardizing the Bundle Protocol (BP), is adapted from 146 RFC 5050 in that context. 148 This document describes version 7 of BP. 150 Delay Tolerant Networking is a network architecture providing 151 communications in and/or through highly stressed environments. 152 Stressed networking environments include those with intermittent 153 connectivity, large and/or variable delays, and high bit error 154 rates. To provide its services, BP may be viewed as sitting at the 155 application layer of some number of constituent networks, forming a 156 store-carry-forward overlay network. Key capabilities of BP 157 include: 159 . Custodial forwarding 160 . Ability to cope with intermittent connectivity, including cases 161 where the sender and receiver are not concurrently present in 162 the network 163 . Ability to take advantage of scheduled, predicted, and 164 opportunistic connectivity, whether bidirectional or 165 unidirectional, in addition to continuous connectivity 166 . Late binding of overlay network endpoint identifiers to 167 underlying constituent network addresses 169 For descriptions of these capabilities and the rationale for the DTN 170 architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial- 171 level overview of DTN concepts. 173 BP's location within the standard protocol stack is as shown in 174 Figure 1. BP uses underlying "native" transport and/or network 175 protocols for communications within a given constituent network. 177 The interface between the bundle protocol and a specific underlying 178 protocol is termed a "convergence layer adapter". 180 Figure 1 shows three distinct transport and network protocols 181 (denoted T1/N1, T2/N2, and T3/N3). 183 +-----------+ +-----------+ 184 | BP app | | BP app | 185 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 186 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 187 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 188 | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | 189 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 190 | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | 191 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 192 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 193 +-----------+ +-------------+ +-------------+ +-----------+ 194 | | | | 195 |<---- A network ---->| |<---- A network ---->| 196 | | | | 198 Figure 1: The Bundle Protocol in the Protocol Stack Model 200 This document describes the format of the protocol data units 201 (called "bundles") passed between entities participating in BP 202 communications. 204 The entities are referred to as "bundle nodes". This document does 205 not address: 207 . Operations in the convergence layer adapters that bundle nodes 208 use to transport data through specific types of internets. 209 (However, the document does discuss the services that must be 210 provided by each adapter at the convergence layer.) 211 . The bundle route computation algorithm. 212 . Mechanisms for populating the routing or forwarding information 213 bases of bundle nodes. 214 . The mechanisms for securing bundles en-route. 215 . The mechanisms for managing bundle nodes. 217 2. Conventions used in this document 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in RFC-2119 [RFC2119]. 223 In this document, these words will appear with that interpretation 224 only when in ALL CAPS. Lower case uses of these words are not to be 225 interpreted as carrying RFC-2119 significance. 227 3. Service Description 229 3.1. Definitions 231 Bundle - A bundle is a protocol data unit of BP, so named because 232 negotiation of the parameters of a data exchange may be impractical 233 in a delay-tolerant network: it is often better practice to "bundle" 234 with a unit of data all metadata that might be needed in order to 235 make the data immediately usable when delivered to applications. 236 Each bundle comprises a sequence of two or more "blocks" of protocol 237 data, which serve various purposes. 239 Block - A bundle protocol block is one of the protocol data 240 structures that together constitute a well-formed bundle. 242 Bundle payload - A bundle payload (or simply "payload") is the 243 application data whose conveyance to the bundle's destination is the 244 purpose for the transmission of a given bundle; it is the content of 245 the bundle's payload block. The terms "bundle content", "bundle 246 payload", and "payload" are used interchangeably in this document. 248 Partial payload - A partial payload is a payload that comprises 249 either the first N bytes or the last N bytes of some other payload 250 of length M, such that 0 < N < M. 252 Fragment - A fragment is a bundle whose payload block contains a 253 partial payload. 255 Bundle node - A bundle node (or, in the context of this document, 256 simply a "node") is any entity that can send and/or receive bundles. 257 Each bundle node has three conceptual components, defined below: a 258 "bundle protocol agent", a set of zero or more "convergence layer 259 adapters", and an "application agent". 261 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 262 the node component that offers the BP services and executes the 263 procedures of the bundle protocol. 265 Convergence layer adapter - A convergence layer adapter (CLA) is a 266 node component that sends and receives bundles on behalf of the BPA, 267 utilizing the services of some 'native' protocol stack that is 268 supported in one of the networks within which the node is 269 functionally located. 271 Application agent - The application agent (AA) of a node is the node 272 component that utilizes the BP services to effect communication for 273 some user purpose. The application agent in turn has two elements, 274 an administrative element and an application-specific element. 276 Application-specific element - The application-specific element of 277 an AA is the node component that constructs, requests transmission 278 of, accepts delivery of, and processes units of user application 279 data. 281 Administrative element - The administrative element of an AA is the 282 node component that constructs and requests transmission of 283 administrative records (defined below), including status reports and 284 custody signals, and accepts delivery of and processes any custody 285 signals that the node receives. 287 Administrative record - A BP administrative record is an application 288 data unit that is exchanged between the administrative elements of 289 nodes' application agents for some BP administrative purpose. The 290 formats of some fundamental administrative records (and of no other 291 application data units) are defined in this specification. 293 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 294 of zero or more bundle nodes that all identify themselves for BP 295 purposes by some common identifier, called a "bundle endpoint ID" 296 (or, in this document, simply "endpoint ID"; endpoint IDs are 297 described in detail in Section 4.3.1 below). 299 Singleton endpoint - A singleton endpoint is an endpoint that always 300 contains exactly one member. 302 Registration - A registration is the state machine characterizing a 303 given node's membership in a given endpoint. Any single 304 registration has an associated delivery failure action as defined 305 below and must at any time be in one of two states: Active or 306 Passive. 308 Delivery - A bundle is considered to have been delivered at a node 309 subject to a registration as soon as the application data unit that 310 is the payload of the bundle, together with any relevant metadata 311 (an implementation matter), has been presented to the node's 312 application agent in a manner consistent with the state of that 313 registration. 315 Deliverability - A bundle is considered "deliverable" subject to a 316 registration if and only if (a) the bundle's destination endpoint is 317 the endpoint with which the registration is associated, (b) the 318 bundle has not yet been delivered subject to this registration, and 319 (c) the bundle has not yet been "abandoned" (as defined below) 320 subject to this registration. 322 Abandonment - To abandon a bundle subject to some registration is to 323 assert that the bundle is not deliverable subject to that 324 registration. 326 Delivery failure action - The delivery failure action of a 327 registration is the action that is to be taken when a bundle that is 328 "deliverable" subject to that registration is received at a time 329 when the registration is in the Passive state. 331 Destination - The destination of a bundle is the endpoint comprising 332 the node(s) at which the bundle is to be delivered (as defined 333 below). 335 Minimum transmission group - The minimum transmission group of an 336 endpoint is the minimum number of members of the endpoint (nodes) at 337 which the bundle must have been delivered in order for the bundle to 338 be considered delivered to the endpoint. 340 Transmission - A transmission is an attempt by a node's BPA to cause 341 copies of a bundle to be delivered at all nodes in the minimum 342 reception group of some endpoint (the bundle's destination) in 343 response to a transmission request issued by the node's application 344 agent. 346 Forwarding - To forward a bundle to a node is to invoke the services 347 of a CLA in a sustained effort to cause a copy of the bundle to be 348 received by that node. 350 Discarding - To discard a bundle is to cease all operations on the 351 bundle and functionally erase all references to it. The specific 352 procedures by which this is accomplished are an implementation 353 matter. 355 Retention constraint - A retention constraint is an element of the 356 state of a bundle that prevents the bundle from being discarded. 357 That is, a bundle cannot be discarded while it has any retention 358 constraints. 360 Deletion - To delete a bundle is to remove unconditionally all of 361 the bundle's retention constraints, enabling the bundle to be 362 discarded. 364 Custodian - A custodian of a bundle is a node that has determined 365 that it will retain a copy of that bundle for an indefinite period 366 of time, forwarding and possibly re-forwarding the bundle as 367 appropriate, until it detects one of the conditions under which it 368 may cease being a custodian of that bundle (discussed later). 370 Taking custody - To take custody of a bundle is to become a 371 custodian of that bundle. 373 Accepting custody - To accept custody of a bundle is to take custody 374 of the bundle, mark the bundle in such a way as to indicate this 375 custodianship to nodes that subsequently receive copies of the 376 bundle, and announce this custodianship to all current custodians of 377 the bundle. 379 Refusing custody - To "refuse custody" of a bundle is to notify all 380 current custodians of that bundle that an opportunity to take 381 custody of the bundle has been declined. 383 Releasing custody - To release custody of a bundle is to cease to be 384 a custodian of the bundle. 386 3.2. Discussion of BP concepts 388 Multiple instances of the same bundle (the same unit of DTN protocol 389 data) might exist concurrently in different parts of a network -- 390 possibly in different representations and/or differing in some 391 blocks -- in the memory local to one or more bundle nodes and/or in 392 transit between nodes. In the context of the operation of a bundle 393 node, a bundle is an instance (copy), in that node's local memory, 394 of some bundle that is in the network. 396 The payload for a bundle forwarded in response to a bundle 397 transmission request is the application data unit whose location is 398 provided as a parameter to that request. The payload for a bundle 399 forwarded in response to reception of a bundle is the payload of the 400 received bundle. 402 In the most familiar case, a bundle node is instantiated as a single 403 process running on a general-purpose computer, but in general the 404 definition is meant to be broader: a bundle node might alternatively 405 be a thread, an object in an object-oriented operating system, a 406 special-purpose hardware device, etc. 408 The manner in which the functions of the BPA are performed is wholly 409 an implementation matter. For example, BPA functionality might be 410 coded into each node individually; it might be implemented as a 411 shared library that is used in common by any number of bundle nodes 412 on a single computer; it might be implemented as a daemon whose 413 services are invoked via inter-process or network communication by 414 any number of bundle nodes on one or more computers; it might be 415 implemented in hardware. 417 Every CLA implements its own thin layer of protocol, interposed 418 between BP and the (usually "top") protocol(s) of the underlying 419 native protocol stack; this "CL protocol" may only serve to 420 multiplex and de-multiplex bundles to and from the underlying native 421 protocol, or it may offer additional CL-specific functionality. The 422 manner in which a CLA sends and receives bundles is, again, wholly 423 an implementation matter. The definitions of CLAs and CL protocols 424 are beyond the scope of this specification. 426 Note that the administrative element of a node's application agent 427 may itself, in some cases, function as a convergence-layer adapter. 428 That is, outgoing bundles may be "tunneled" through encapsulating 429 bundles: 431 . An outgoing bundle that has been encoded in some documented 432 representation constitutes a byte array. This byte array may, 433 like any other, be presented to the bundle protocol agent as an 434 application data unit that is to be transmitted to some 435 endpoint. 436 . The original encoded bundle thus forms the payload of an 437 encapsulating bundle that is forwarded using some other 438 convergence-layer protocol(s). 439 . When the encapsulating bundle is received, its payload is 440 delivered to the peer application agent administrative element, 441 which then instructs the bundle protocol agent to dispatch that 442 original encoded bundle in the usual way. 444 The purposes for which this technique may be useful (such as cross- 445 domain security) are beyond the scope of this specification. 447 The only interface between the BPA and the application-specific 448 element of the AA is the BP service interface. But between the BPA 449 and the administrative element of the AA there is a (conceptual) 450 private control interface in addition to the BP service interface. 451 This private control interface enables the BPA and the 452 administrative element of the AA to direct each other to take action 453 under specific circumstances 455 In the case of a node that serves simply as a BP "router", the AA 456 may have no application-specific element at all. The application- 457 specific elements of other nodes' AAs may perform arbitrarily 458 complex application functions, perhaps even offering multiplexed DTN 459 communication services to a number of other applications. As with 460 the BPA, the manner in which the AA performs its functions is wholly 461 an implementation matter. 463 Singletons are the most familiar sort of endpoint, but in general 464 the endpoint notion is meant to be broader. For example, the nodes 465 in a sensor network might constitute a set of bundle nodes that 466 identify themselves by a single common endpoint ID and thus form a 467 single bundle endpoint. *Note* too that a given bundle node might 468 identify itself by multiple endpoint IDs and thus be a member of 469 multiple bundle endpoints. 471 The destination of every bundle is an endpoint, which may or may not 472 be singleton. The source of every bundle is a node, identified by 473 the endpoint ID for some singleton endpoint that contains that node. 475 Upon reception, the processing of a bundle that has been received by 476 a given node depends on whether or not the receiving node is 477 registered in the bundle's destination endpoint. If it is, and if 478 the payload of the bundle is non-fragmentary (possibly as a result 479 of successful payload reassembly from fragmentary payloads, 480 including the original payload of the newly received bundle), then 481 the bundle is normally "delivered" to the node's application agent 482 subject to the registration characterizing the node's membership in 483 the destination endpoint. 485 The minimum reception group of an endpoint may be any one of the 486 following: (a) ALL of the nodes registered in an endpoint that is 487 permitted to contain multiple nodes (in which case forwarding to the 488 endpoint is functionally similar to "multicast" operations in the 489 Internet, though possibly very different in implementation); (b) ANY 490 N of the nodes registered in an endpoint that is permitted to 491 contain multiple nodes, where N is in the range from zero to the 492 cardinality of the endpoint; or (c) THE SOLE NODE registered in a 493 singleton endpoint (in which case forwarding to the endpoint is 494 functionally similar to "unicast" operations in the Internet). 496 The nature of the minimum reception group for a given endpoint can 497 typically be determined from the endpoint's ID. For some endpoint 498 ID "schemes", the nature of the minimum reception group is fixed - 499 in a manner that is defined by the scheme - for all endpoints 500 identified under the scheme. For other schemes, the nature of the 501 minimum reception group is indicated by some lexical feature of the 502 "scheme-specific part" of the endpoint ID, in a manner that is 503 defined by the scheme. 505 Any number of transmissions may be concurrently undertaken by the 506 bundle protocol agent of a given node. 508 When the bundle protocol agent of a node determines that a bundle 509 must be forwarded to a node (either to a node that is a member of 510 the bundle's destination endpoint or to some intermediate forwarding 511 node) in the course of completing the successful transmission of 512 that bundle, it invokes the services of a CLA in a sustained effort 513 to cause a copy of the bundle to be received by that node. 515 Upon reception, the processing of a bundle that has been received by 516 a given node depends on whether or not the receiving node is 517 registered in the bundle's destination endpoint. If it is, and if 518 the payload of the bundle is non-fragmentary (possibly as a result 519 of successful payload reassembly from fragmentary payloads, 520 including the original payload of the newly received bundle), then 521 the bundle is normally delivered to the node's application agent 522 subject to the registration characterizing the node's membership in 523 the destination endpoint. 525 Whenever, for some implementation-specific reason, a node's BPA 526 finds it impossible to immediately deliver a bundle that is 527 deliverable, delivery of the bundle has failed. In this event, the 528 delivery failure action associated with the applicable registration 529 must be taken. Delivery failure action MUST be one of the following: 531 . defer delivery of the bundle subject to this registration until 532 (a) this bundle is the least recently received of all bundles 533 currently deliverable subject to this registration and (b) 534 either the registration is polled or else the registration is 535 in the Active state; or 537 . abandon delivery of the bundle subject to this registration. 539 An additional implementation-specific delivery deferral procedure 540 MAY optionally be associated with the registration. 542 While the state of a registration is Passive, reception of a bundle 543 that is deliverable subject to this registration MUST cause delivery 544 of the bundle to be abandoned or deferred as mandated by the 545 registration's current delivery failure action; in the latter case, 546 any additional delivery deferral procedure associated with the 547 registration MUST also be performed. 549 While the state of a registration is Active, reception of a bundle 550 that is deliverable subject to this registration MUST cause the 551 bundle to be delivered automatically as soon as it is the next 552 bundle that is due for delivery according to the BPA's bundle 553 delivery scheduling policy, an implementation matter. 555 Normally only registrations' registered delivery failure actions 556 cause deliveries to be abandoned. 558 Custody of a bundle MAY be taken only if the destination of the 559 bundle is a singleton endpoint. Custody MAY be released only when 560 either (a) notification is received that some other node has 561 accepted custody of the same bundle; (b) notification is received 562 that the bundle has been delivered at the (sole) node registered in 563 the bundle's destination endpoint; (c) the current custodian chooses 564 to fragment the bundle, releasing custody of the original bundle and 565 taking custody of the fragments instead, or (d) the bundle is 566 explicitly deleted for some reason, such as lifetime expiration. 568 The custody transfer mechanism in BP is primarily intended as a 569 means of recovering from forwarding failures. When a bundle arrives 570 at a node from which it must be forwarded, but forwarding is 571 impossible, BP must recover from this error. BP can "return" the 572 bundle back toward some node for forwarding along some other path in 573 the network, or else it can instead send a small "signal" bundle 574 back to such a node, in the event that this node has retained a copy 575 of the bundle ("taken custody") and is therefore able to re-forward 576 the bundle without receiving a copy. Custody transfer sharply 577 reduces the network traffic required for recovery from forwarding 578 failures, at the cost of increased buffer occupancy and state 579 management at the custodial nodes. 581 Note that custodial re-forwarding can also be initiated by 582 expiration of a timer prior to reception of a custody acceptance or 583 refusal signal. Since the absence of a custody acceptance signal 584 might be caused by failure to receive the bundle, rather than only a 585 disinclination to take custody, custody transfer can additionally 586 serve as an automated retransmission mechanism. 588 However, because custody transfer's only remedy for loss of any part 589 of a bundle is retransmission of the entire bundle (not just the 590 lost portion), custody transfer is a less efficient automated 591 retransmission mechanism than the reliable transport protocols that 592 are typically available at the convergence layer; configuring BPAs 593 to use reliable convergence-layer protocols between nodes is 594 generally the best means of ensuring bundle delivery at the 595 destination node(s). But there are some use cases (typically 596 involving unidirectional links) in which custody transfer in BP may 597 be a more cost-effective solution for reliable transmission between 598 two BP agents than invoking retransmission protocols at the 599 convergence layer. 601 3.3. Implementation Architectures 603 The definitions of BP concepts are intended to enable the bundle 604 protocol's operations to be specified in a manner that minimizes 605 bias toward any particular implementation architecture. To 606 illustrate the range of interoperable implementation models that 607 might conform to this specification, four example architectures are 608 briefly described below. 610 3.3.1. Bundle protocol application server 612 A single bundle protocol application server, constituting a single 613 bundle node, runs as a daemon process on each computer. The daemon's 614 functionality includes all functions of the bundle protocol agent, 615 all convergence layer adapters, and both the administrative and 616 application-specific elements of the application agent. The 617 application-specific element of the application agent functions as a 618 server, offering bundle protocol service over a local area network: 619 it responds to remote procedure calls from application processes (on 620 the same computer and/or remote computers) that need to communicate 621 via the bundle protocol. The server supports its clients by creating 622 a new node for each one and registering each such node in a client- 623 specified endpoint. The conceptual nodes managed by the server 624 function as clients' bundle protocol service access points. 626 3.3.2. Peer application nodes 628 Any number of bundle protocol application processes, each one 629 constituting a single bundle node, run on each computer. The 630 functionality of the bundle protocol agent, all convergence layer 631 adapters, and the administrative element of the application agent is 632 provided by a library to which each node process is dynamically 633 linked at run time. The application-specific element of each node's 634 application agent is node-specific application code. 636 3.3.3. Sensor network nodes 638 Each node of the sensor network is the self-contained implementation 639 of a single bundle node. All functions of the bundle protocol agent, 640 all convergence layer adapters, and the administrative element of 641 the application agent are implemented in simplified form in 642 hardware, while the application-specific element of each node's 643 application agent is implemented in a programmable microcontroller. 644 Forwarding is rudimentary: all bundles are forwarded on a hard-coded 645 default route. 647 3.3.4. Dedicated bundle router 649 Each computer constitutes a single bundle node that functions solely 650 as a high-performance bundle forwarder. Many standard functions of 651 the bundle protocol agent, the convergence layer adapters, and the 652 administrative element of the application agent are implemented in 653 specialized hardware, but some functions are implemented in a high- 654 speed processor to enable reprogramming as necessary. The node's 655 application agent has no application-specific element. Substantial 656 non-volatile storage resources are provided, and arbitrarily complex 657 forwarding algorithms are supported. 659 3.4. 3.3. Services Offered by Bundle Protocol Agents 661 The BPA of each node is expected to provide the following services 662 to the node's application agent: 664 . commencing a registration (registering the node in an 665 endpoint); 666 . terminating a registration; 667 . switching a registration between Active and Passive states; 668 . transmitting a bundle to an identified bundle endpoint; 669 . canceling a transmission; 670 . polling a registration that is in the Passive state; 671 . delivering a received bundle. 673 4. Bundle Format 675 NOTE that only the abstract structures of blocks are defined here. 676 The specific bitstream that is emitted when a CLA sends a bundle 677 will be dictated by the applicable bundle representation 678 specification to which the sending and receiving nodes conform, an 679 implementation matter. It is important to note that not all BP 680 implementations are required to implement all bundle representation 681 specifications. The BP implementations used to instantiate nodes in 682 a given network must be chosen with care in order for every node to 683 be able to exchange bundles with every other node. Bundle 684 representation specifications are beyond the scope of this document. 686 Each bundle SHALL be a concatenated sequence of at least two blocks. 687 The first block in the sequence MUST be a primary bundle block, and 688 the bundle MUST have exactly one primary bundle block. Additional 689 bundle protocol blocks of other types MAY follow the primary block 690 to support extensions to the bundle protocol, such as the Bundle 691 Security Protocol [BSPBPSEC]. Exactly one of the blocks in the 692 sequence MUST be a payload block, and the payload block MUST be the 693 last block in the sequence. 695 4.1. Bundle Processing Control Flags 697 Bundle processing control flags assert properties of the bundle as a 698 whole rather than of any particular block of the bundle. They are 699 conveyed in the primary block of the bundle. 701 The following properties are asserted by the bundle processing 702 control flags: 704 . The bundle is a fragment. (Boolean) 706 . The bundle's payload is an administrative record. (Boolean) 708 . The bundle must not be fragmented. (Boolean) 710 . Custody transfer is requested for this bundle. (Boolean) 712 . The bundle's destination endpoint is a singleton. (Boolean) 714 . Acknowledgment by the user application is requested. (Boolean) 716 . The bundle is "critical" as discussed later. (Boolean) 718 . Best-efforts forwarding of the bundle is requested. (Boolean) 720 . Reliable forwarding of the bundle is requested. (Boolean) 722 . Status time is requested in all status reports. (Boolean) 724 . Type of CRC that is present in the bundle's primary block. (An 725 unsigned integer CRC type code; 0 indicates that the block 726 contains no CRC, other valid values TBD) 728 . The bundle's priority, a numeric value from 0 to 127, with 729 higher values being of higher priority (greater urgency). 731 . Flags requesting types of status reports (all Boolean): 733 o Request reporting of bundle reception. 735 o Request reporting of custody acceptance. 737 o Request reporting of bundle forwarding. 739 o Request reporting of bundle delivery. 741 o Request reporting of bundle deletion. 743 If the bundle processing control flags indicate that the bundle's 744 application data unit is an administrative record, then the custody 745 transfer requested flag value must be zero and all status report 746 request flag values must be zero. 748 If the custody transfer requested flag is 1, then the source node is 749 requesting that every receiving node accept custody of the bundle. 751 If the bundle's source node is omitted (i.e., the source endpoint ID 752 is the null endpoint, which has no members as discussed below), then 753 the bundle is not uniquely identifiable and all bundle protocol 754 features that rely on bundle identity must therefore be disabled: 755 the bundle's custody transfer requested flag value must be zero, the 756 "Bundle must not be fragmented" flag value must be 1, and all status 757 report request flag values must be zero. 759 4.2. Block Processing Control Flags 761 The block processing control flags assert properties of individual 762 bundle blocks other than the primary block. They are conveyed in 763 the header of the block to which they pertain. 765 The following properties are asserted by the block processing 766 control flags: 768 . This block must be replicated in every fragment. (Boolean) 770 . Status report must be transmitted if this block can't be 771 processed. (Boolean) 773 . Block must be removed from the bundle if it can't be processed. 774 (Boolean) 776 . Bundle must be deleted if this block can't be processed. 777 (Boolean) 779 . This block was forwarded without being processed. (Boolean) 781 For each bundle whose bundle processing control flags indicate that 782 the bundle's application data unit is an administrative record, the 783 value of the "Transmit status report if block can't be processed" 784 flag in every block of the bundle other than the primary block must 785 be zero. 787 4.3. Identifiers 789 4.3.1. Endpoint ID 791 The destinations of bundles are bundle endpoints, identified by text 792 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 793 (EID) conveyed in any bundle block takes the form of a Uniform 794 Resource Identifier (URI; [URI]). As such, each endpoint ID can be 795 characterized as having this general structure: 797 < scheme name > : < scheme-specific part, or "SSP" > 799 The scheme identified by the < scheme name > in an endpoint ID is a 800 set of syntactic and semantic rules that fully explain how to parse 801 and interpret the SSP. The set of allowable schemes is effectively 802 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 803 protocol endpoint ID. 805 Note that, although endpoint IDs are URIs, implementations of the BP 806 service interface may support expression of endpoint IDs in some 807 internationalized manner (e.g., Internationalized Resource 808 Identifiers (IRIs); see [RFC3987]). 810 Note also that the representation of an EID in the bitstream that is 811 emitted when a CLA sends a bundle will be dictated by the applicable 812 bundle representation specification to which the sending and 813 receiving nodes conform, an implementation matter. 815 The endpoint ID "dtn:none" identifies the "null endpoint", the 816 endpoint that by definition never has any members. 818 4.3.2. Node ID 820 For many purposes of the Bundle Protocol it is important to identify 821 the node that is operative in some context. 823 As discussed in 3.1 above, nodes are distinct from endpoints; 824 specifically, an endpoint is a set of zero or more nodes. But 825 rather than define a separate namespace for node identifiers, we 826 instead use endpoint identifiers to identify nodes, subject to the 827 following restrictions: 829 . Every node must MUST be a member of at least one singleton 830 endpoint. 831 . The EID of any singleton endpoint of which a node is a member 832 may MAY be used to identify that node. A "node ID" is an EID 833 that is used in this way. 835 . A node's membership in a given singleton endpoint must MUST be 836 sustained at least until the nominal operation of the Bundle 837 Protocol no longer depends on the identification of that node 838 using that endpoint's ID. 840 4.4. Contents of Bundle Blocks 842 This section describes the contents of the primary block in detail 843 and the contents of all non-primary blocks in general. Rules for 844 processing these blocks appear in Section 5 of this document. 846 Note that supplementary DTN protocol specifications (including, but 847 not restricted to, the Bundle Security Protocol [BSPBPSEC]) may 848 require that BP implementations conforming to those protocols 849 construct and process additional blocks. 851 4.4.1. Primary Bundle Block 853 The primary bundle block contains the basic information needed to 854 forward bundles to their destinations. The fields of the primary 855 bundle block are: 857 Version: An unsigned integer value indicating the version of the 858 bundle protocol that constructed this block. The present document 859 describes version 7 of the bundle protocol. 861 Bundle Processing Control Flags: The Bundle Processing Control Flags 862 are discussed in Section 4.1 above. 864 Destination EID: The Destination EID field identifies the bundle 865 endpoint that is the bundle's destination, i.e., the endpoint that 866 contains the node(s) at which the bundle is to be delivered. 868 Source node ID: The Source node ID field identifies the bundle node 869 at which the bundle was initially transmitted, except that Source 870 node ID may be the null endpoint ID in the event that the bundle's 871 source chooses to remain anonymous. 873 Report-to EID: The Report-to EID field identifies the bundle 874 endpoint to which status reports pertaining to the forwarding and 875 delivery of this bundle are to be transmitted. 877 Creation Timestamp: The creation timestamp is a pair of unsigned 878 integers that, together with the source node ID and (if the bundle 879 is a fragment) the fragment offset and payload length, serve to 880 identify the bundle. The first of these integers is the bundle's 881 creation time, while the second is the bundle's creation timestamp 882 sequence number. Bundle creation time is the time - expressed in 883 seconds since the start of the year 2000, on the Coordinated 884 Universal Time (UTC) scale [UTC] - at which the transmission request 885 was received that resulted in the creation of the bundle. Sequence 886 count is the latest value (as of the time at which that transmission 887 request was received) of a monotonically increasing positive integer 888 counter managed by the source node's bundle protocol agent that may 889 be reset to zero whenever the current time advances by one second. 890 For nodes that lack accurate clocks (that is, nodes that are not at 891 all moments able to determine the current UTC time to within 30 892 seconds), bundle creation time MUST be set to zero and the counter 893 used as the source of the bundle sequence count MUST NEVER be reset 894 to zero. In any case, a source Bundle Protocol Agent must never 895 create two distinct bundles with the same source node ID and bundle 896 creation timestamp. The combination of source node ID and bundle 897 creation timestamp serves to identify a single transmission request, 898 enabling it to be acknowledged by the receiving application 899 (provided the source node ID is not the null endpoint ID). 901 Lifetime: The lifetime field is an unsigned integer that indicates 902 the time at which the bundle's payload will no longer be useful, 903 encoded as a number of seconds past the creation time. When a 904 bundle's age exceeds its lifetime, bundle nodes need no longer 905 retain or forward the bundle; the bundle SHOULD be deleted from the 906 network. 908 Inventory: The Primary block MAY contain an accounting of all types 909 of blocks that were in the bundle at the time it was transmitted 910 from the source node. This feature is optional; its structure and 911 the manner by which its presence is signaled to the receiving node 912 are matters of representation that are beyond the scope of this 913 document. If present, the bundle inventory SHALL comprise a 914 sequence of block type code numbers, each an unsigned integer, one 915 for each type of block that was present in the bundle at the time it 916 was transmitted, and no others. The order of block types appearing 917 in the inventory is undefined. 919 The CRC field of the Primary Bundle Block is present only if the CRC 920 type field in the block's processing flags field is non-zero. 922 Fragment Offset: If and only if the Bundle Processing Control Flags 923 of this Primary block indicate that the bundle is a fragment, then 924 the Fragment Offset field SHALL be an unsigned integer indicating 925 the offset from the start of the original application data unit at 926 which the bytes comprising the payload of this bundle were located. 927 If not, then the Fragment Offset field SHALL be omitted from the 928 block. 930 Total Application Data Unit Length: If and only if the Bundle 931 Processing Control Flags of this Primary block indicate that the 932 bundle is a fragment, then the Total Application Data Unit Length 933 field SHALL be an unsigned integer indicating the total length of 934 the original application data unit of which this bundle's payload is 935 a part. If not, then the Total Application Data Unit Length field 936 SHALL be omitted from the block. 938 If and only if the CRC type in the Bundle Processing Control Flags 939 of this Primary block is non-zero, a CRC SHALL be present the 940 primary block. The length and nature of the CRC SHALL be as 941 indicated by the CRC type. The CRC SHALL be computed over the 942 concatenation of all bytes of the primary block including the CRC 943 field itself, which for this purpose is temporarily populated with 944 the value zero. 946 4.4.2. Canonical Bundle Block Format 948 Every bundle block of every type other than the primary bundle block 949 comprises the following fields, in this order: 951 . Block type code, an unsigned integer. Bundle block type code 1 952 indicates that the block is a bundle payload block. Block type 953 codes 2 through 9 are explicitly reserved as noted later in 954 this specification. Block type codes 192 through 255 are not 955 reserved and are available for private and/or experimental use. 956 All other block type code values are reserved for future use. 957 . Block number, an unsigned integer. The block number uniquely 958 identifies the block within the bundle, enabling blocks 959 (notably bundle security protocol blocks) to explicitly 960 reference other blocks in the same bundle. Block numbers need 961 not be in continuous sequence, and blocks need not appear in 962 block number sequence in the bundle. The block number of the 963 payload block is always zero. 964 . Block processing control flags as discussed above. 965 . Block data length, an unsigned integer. The block data length 966 field contains the aggregate length of all remaining fields of 967 the block, i.e., the block-type-specific data fields. 968 . Block-type-specific data fields, whose nature and order are 969 type-specific and whose aggregate length in octets is the value 970 of the block data length field. For the Payload Block in 971 particular (block type 1), there SHALL be exactly one block- 972 type-specific data field, the "payload", i.e., the application 973 data carried by this bundle. 975 4.5. Extension Blocks 977 "Extension blocks" are all blocks other than the primary and payload 978 blocks. Because not all extension blocks are defined in the Bundle 979 Protocol specification (the present document), not all nodes 980 conforming to this specification will necessarily instantiate Bundle 981 Protocol implementations that include procedures for processing 982 (that is, recognizing, parsing, acting on, and/or producing) all 983 extension blocks. It is therefore possible for a node to receive a 984 bundle that includes extension blocks that the node cannot process. 985 The values of the block processing control flags indicate the action 986 to be taken by the bundle protocol agent when this is the case. 988 Whenever a bundle is forwarded that contains one or more extension 989 blocks that could not be processed, the "Block was forwarded without 990 being processed" flag must be set to 1 within the block processing 991 flags of each such block. For each block flagged in this way, the 992 flag may optionally be cleared (i.e., set to zero) by another node 993 that subsequently receives the bundle and is able to process that 994 block; the specifications defining the various extension blocks are 995 expected to define the circumstances under which this flag may be 996 cleared, if any. 998 The extension blocks of the Bundle Security Protocol (block types 2 999 and, 3, and 4) are defined separately in the Bundle Security 1000 Protocol specification (work in progress). 1002 The following extension blocks are defined in the current document. 1004 4.5.1. Current Custodian 1006 The Current Custodian block, block type 5, identifies a node that is 1007 known to have accepted custody of the bundle. The block-type- 1008 specific data of this block is the node ID of a custodian. The 1009 bundle MAY contain one or more occurrences of this type of block. 1011 4.5.2. Flow Label 1013 The Flow Label block, block type 6, indicates the flow label that is 1014 intended to govern transmission of the bundle by convergence-layer 1015 adapters. The syntax and semantics of BP flow labels are beyond the 1016 scope of this document. 1018 4.5.3. Previous Node ID 1020 The Previous Node ID block, block type 7, identifies the node that 1021 forwarded this bundle to the local node; its block-type-specific 1022 data is the node ID of that node. If the local node is the source 1023 of the bundle, then the bundle MUST NOT contain any Previous Node ID 1024 block. Otherwise the bundle MUST contain one (1) occurrence of this 1025 type of block. If present, the Previous Node ID block MUST be the 1026 FIRST block following the primary block, as the processing of other 1027 extension blocks may depend on its value. 1029 4.5.4. Bundle Age 1031 The Bundle Age block, block type 8, contains the number of seconds 1032 that have elapsed between the time the bundle was created and time 1033 at which it was most recently forwarded. It is intended for use by 1034 nodes lacking access to an accurate clock, to aid in determining the 1035 time at which a bundle's lifetime expires. The block-type-specific 1036 data of this block is an unsigned integer containing the age of the 1037 bundle (the sum of all known intervals of the bundle's residence at 1038 forwarding nodes, up to the time at which the bundle was most 1039 recently forwarded) in seconds. If the bundle's creation time is 1040 zero, then the bundle MUST contain exactly one (1) occurrence of 1041 this type of block; otherwise, the bundle MAY contain at most one 1042 (1) occurrence of this type of block. 1044 4.5.5. Hop Count 1046 The Hop Count block, block type 9, contains two unsigned integers, 1047 hop limit and hop count. It is mainly intended as a safety 1048 mechanism, a means of identifying bundles for removal from the 1049 network that can never be delivered due to a persistent forwarding 1050 error: a bundle may be deleted when its hop count exceeds its hop 1051 limit. Procedures for determining the appropriate hop limit for a 1052 block are beyond the scope of this specification. A bundle MAY 1053 contain at most one (1) occurrence of this type of block. 1055 5. Bundle Processing 1057 The bundle processing procedures mandated in this section and in 1058 Section 6 govern the operation of the Bundle Protocol Agent and the 1059 Application Agent administrative element of each bundle node. They 1060 are neither exhaustive nor exclusive. Supplementary DTN protocol 1061 specifications (including, but not restricted to, the Bundle 1062 Security Protocol [BSPBPSEC]) may augment, override, or supersede 1063 the mandates of this document. 1065 5.1. Generation of Administrative Records 1067 All transmission of bundles is in response to bundle transmission 1068 requests presented by nodes' application agents. When required to 1069 "generate" an administrative record (such as a bundle status report 1070 or a custody signal), the bundle protocol agent itself is 1071 responsible for causing a new bundle to be transmitted, conveying 1072 that record. In concept, the bundle protocol agent discharges this 1073 responsibility by directing the administrative element of the node's 1074 application agent to construct the record and request its 1075 transmission as detailed in Section 6 below. In practice, the manner 1076 in which administrative record generation is accomplished is an 1077 implementation matter, provided the constraints noted in Section 6 1078 are observed. 1080 Under some circumstances, the requesting of status reports could 1081 result in an unacceptable increase in the bundle traffic in the 1082 network. For this reason, the generation of status reports is 1083 mandatory only in one case, the deletion of a bundle for which 1084 custody transfer is requested. In all other cases, the decision on 1085 whether or not to generate a requested status report is left to the 1086 discretion of the bundle protocol agent. Mechanisms that could 1087 assist in making such decisions, such as pre-placed agreements 1088 authorizing the generation of status reports under specified 1089 circumstances, are beyond the scope of this specification. 1091 Notes on administrative record terminology: 1093 . A "bundle reception status report" is a bundle status report 1094 with the "reporting node received bundle" flag set to 1. 1095 . A "custody acceptance status report" is a bundle status report 1096 with the "reporting node accepted custody of bundle" flag set 1097 to 1. 1098 . A "bundle forwarding status report" is a bundle status report 1099 with the "reporting node forwarded the bundle" flag set to 1. 1100 . A "bundle delivery status report" is a bundle status report 1101 with the "reporting node delivered the bundle" flag set to 1. 1102 . A "bundle deletion status report" is a bundle status report 1103 with the "reporting node deleted the bundle" flag set to 1. 1104 . A "Succeeded" custody signal is a custody signal with the 1105 "custody transfer succeeded" flag set to 1. 1106 . A "Failed" custody signal is a custody signal with the "custody 1107 transfer succeeded" flag set to zero. 1108 . A "current custodian" of a bundle is a node identified in a 1109 Current Custodian extension block of that bundle. 1111 5.2. Bundle Transmission 1113 The steps in processing a bundle transmission request are: 1115 Step 1: If custody transfer is requested for this bundle 1116 transmission then the destination MUST be a singleton endpoint. If, 1117 moreover, custody acceptance by the source node is required but the 1118 conditions under which custody of the bundle may be accepted are not 1119 satisfied, then the request cannot be honored and all remaining 1120 steps of this procedure MUST be skipped. 1122 Step 2: Transmission of the bundle is initiated. An outbound bundle 1123 MUST be created per the parameters of the bundle transmission 1124 request, with the retention constraint "Dispatch pending". The 1125 source node ID of the bundle MUST be either the null endpoint ID, 1126 indicating that the source of the bundle is anonymous, or else the 1127 EID of a singleton endpoint whose only member is the node of which 1128 the BPA is a component. 1130 Step 3: Processing proceeds from Step 1 of Section 5.4. 1132 5.3. Bundle Dispatching 1134 The steps in dispatching a bundle are: 1136 Step 1: If the bundle's destination endpoint is an endpoint of which 1137 the node is a member, the bundle delivery procedure defined in 1138 Section 5.7 MUST be followed. 1140 Step 2: Processing proceeds from Step 1 of Section 5.4. 1142 5.4. Bundle Forwarding 1144 The steps in forwarding a bundle are: 1146 Step 1: The retention constraint "Forward pending" MUST be added to 1147 the bundle, and the bundle's "Dispatch pending" retention constraint 1148 MUST be removed. 1150 Step 2: The bundle protocol agent MUST determine whether or not 1151 forwarding is contraindicated for any of the reasons listed in 1152 Figure 12. In particular: 1154 . The bundle protocol agent MUST determine which node(s) to 1155 forward the bundle to. The bundle protocol agent MAY choose 1156 either to forward the bundle directly to its destination 1157 node(s) (if possible) or to forward the bundle to some other 1158 node(s) for further forwarding. The manner in which this 1159 decision is made may depend on the scheme name in the 1160 destination endpoint ID and/or on other state but in any case 1161 is beyond the scope of this document. If the BPA elects to 1162 forward the bundle to some other node(s) for further forwarding 1163 but finds it impossible to select any node(s) to forward the 1164 bundle to, then forwarding is contraindicated.: 1165 o If the "Bundle is critical" flag (in the bundle processing 1166 flags) is set to 1, then ALL nodes that have some 1167 plausible prospect of forwarding the bundle to its 1168 destination node(s) SHOULD be selected for this purpose. 1169 o If the agent finds it impossible to select any node(s) to 1170 forward the bundle to, then forwarding is contraindicated. 1171 . Provided the bundle protocol agent succeeded in selecting the 1172 node(s) to forward the bundle to, the bundle protocol agent 1173 MUST select the convergence layer adapter(s) whose services 1174 will enable the node to send the bundle to those nodes. If 1175 both the "Best-efforts forwarding requested" and the "Reliable 1176 forwarding is requested" bundle processing flags are set to 1, 1177 then all selected CLAs MUST be for bundle streaming CL 1178 protocols such as the proposed Bundle Streaming Service 1179 Protocol. Otherwise, if only the "Reliable forwarding is 1180 requested" bundle processing flag is set to 1, then all 1181 selected CLAs MUST be for reliable protocols such as TCP/IP. 1182 Otherwise, if only the "Best-efforts forwarding requested" 1183 bundle processing flag is set to 1, then all selected CLAs MUST 1184 be for best-efforts protocols such as UDP/IP. Otherwise, any 1185 available CLAs MAY be selected. The manner in which specific 1186 appropriate convergence layer adapters are selected is beyond 1187 the scope of this document. If the agent finds it impossible to 1188 select any appropriate convergence layer adapter(s) to use in 1189 forwarding this bundle, then forwarding is contraindicated. 1190 . Provided the bundle protocol agent succeeded in selecting the 1191 node(s) to forward the bundle to and additionally succeeded in 1192 selecting the appropriate convergence layer adapter(s), the 1193 bundle protocol agent MUST determine the applicable bundle 1194 representation by which the bundle must be encoded when sent to 1195 each such node so that the bundle will be intelligible when 1196 received by that node. The manner in which applicable bundle 1197 representations are selected is beyond the scope of this 1198 document. If the agent finds that there are no applicable 1199 bundle representations for any of the nodes to which the bundle 1200 is to be sent, then forwarding is contraindicated. 1202 Step 3: If forwarding of the bundle is determined to be 1203 contraindicated for any of the reasons listed in Figure 12, then the 1204 Forwarding Contraindicated procedure defined in Section 5.4.1 MUST 1205 be followed; the remaining steps of Section 5 are skipped at this 1206 time. 1208 Step 4: If the bundle's custody transfer requested flag (in the 1209 bundle processing flags field) is set to 1, then the custody 1210 transfer procedure defined in Section 5.10.2 MUST be followed. 1212 Step 5: For each node selected for forwarding, the bundle protocol 1213 agent MUST encode the bundle in the selected applicable 1214 representation(s) and then invoke the services of the selected 1215 convergence layer adapter(s) in order to effect the sending of the 1216 bundle to that node. Determining the time at which the bundle 1217 protocol agent invokes convergence layer adapter services is a BPA 1218 implementation matter. Determining the time at which the bundle is 1219 to be sent by each convergence layer adapter subsequently responds 1220 to this service invocation by sending the bundle is an convergence- 1221 layer adapter implementation matter. Note that: 1223 . The order in which convergence layer adapters send bundles 1224 SHOULD normally conform to the priority indicated in each 1225 bundle's bundle processing control flags field: all bundles of 1226 priority 127 sent from any single source should be sent before 1227 all bundles of priority 126 sent from the same source and so 1228 on. 1229 . But iIf the bundle contains a flow label extension block then 1230 that flow label value MAY identify overriding procedures for 1231 determining the order in which convergence layer adapters must 1232 send bundles, e.g., considering bundle source when determining 1233 the order in which bundles are sent. The definition of such 1234 procedures is beyond the scope of this specification. 1235 . If the bundle has a bundle age block, then at the last possible 1236 moment before the CLA initiates conveyance of the bundle node 1237 via the CL protocol the bundle age value MUST be increased by 1238 the difference between the current time and the time at which 1239 the bundle was received (or, if the local node is the source of 1240 the bundle, created). 1242 Step 6: When all selected convergence layer adapters have informed 1243 the bundle protocol agent that they have concluded their data 1244 sending procedures with regard to this bundle: 1246 . If the "request reporting of bundle forwarding" flag in the 1247 bundle's status report request field is set to 1, then a bundle 1248 forwarding status report SHOULD be generated, destined for the 1249 bundle's report-to endpoint ID. If the bundle has the retention 1250 constraint "custody accepted" and all of the nodes to which the 1251 bundle was forwarded are known to be unable to send bundles 1252 back to this node, then the reason code on this bundle 1253 forwarding status report MUST be "forwarded over unidirectional 1254 link"; otherwise, the reason code MUST be "no additional 1255 information". 1256 . The bundle's "Forward pending" retention constraint MUST be 1257 removed. 1259 5.4.1. Forwarding Contraindicated 1261 The steps in responding to contraindication of forwarding are: 1263 Step 1: The bundle protocol agent MUST determine whether or not to 1264 declare failure in forwarding the bundle. Note: this decision is 1265 likely to be influenced by the reason for which forwarding is 1266 contraindicated. 1268 Step 2: If forwarding failure is declared, then the Forwarding 1269 Failed procedure defined in Section 5.4.2 MUST be followed. 1271 Otherwise, (a) if the bundle's custody transfer requested flag (in 1272 the bundle processing flags field) is set to 1, then the custody 1273 transfer procedure defined in Section 5.10 MUST be followed; (b) 1274 when -- at some future time - the forwarding of this bundle ceases 1275 to be contraindicated, processing proceeds from Step 5 of Section 1276 5.4. 1278 5.4.2. Forwarding Failed 1280 The steps in responding to a declaration of forwarding failure are: 1282 Step 1: If the bundle's custody transfer requested flag (in the 1283 bundle processing flags field) is set to 1, custody transfer failure 1284 must be handled. The bundle protocol agent MUST handle the custody 1285 transfer failure by generating a "Failed" custody signal for the 1286 bundle, destined for the bundle's current custodian(s); the custody 1287 signal MUST contain a reason code corresponding to the reason for 1288 which forwarding was determined to be contraindicated. (Note that 1289 discarding the bundle will not delete it from the network, since 1290 each current custodian still has a copy.) 1292 If the bundle's custody transfer requested flag (in the bundle 1293 processing flags field) is set to 0, then the bundle protocol agent 1294 MAY forward the bundle back to the node that sent it, as identified 1295 by the Previous Node ID block. 1297 Step 2: If the bundle's destination endpoint is an endpoint of which 1298 the node is a member, then the bundle's "Forward pending" retention 1299 constraint MUST be removed. Otherwise, the bundle MUST be deleted: 1300 the bundle deletion procedure defined in Section 5.13 MUST be 1301 followed, citing the reason for which forwarding was determined to 1302 be contraindicated. 1304 5.5. Bundle Expiration 1306 A bundle expires when the bundle's age exceeds its lifetime as 1307 specified in the primary bundle block. Bundle age MAY be determined 1308 by subtracting the bundle's creation timestamp time from the current 1309 time if (a) that timestamp time is not zero and (b) the local node's 1310 clock is known to be accurate (as discussed in section 4.5.1 above); 1311 otherwise bundle age MUST be obtained from the Bundle Age extension 1312 block. Bundle expiration MAY occur at any point in the processing 1313 of a bundle. When a bundle expires, the bundle protocol agent MUST 1314 delete the bundle for the reason "lifetime expired": the bundle 1315 deletion procedure defined in Section 5.13 MUST be followed. 1317 5.6. Bundle Reception 1319 The steps in processing a bundle that has been received from another 1320 node and decoded from its serialized representation are: 1322 Step 1: The retention constraint "Dispatch pending" MUST be added to 1323 the bundle. 1325 Step 2: If the "request reporting of bundle reception" flag in the 1326 bundle's status report request field is set to 1, then a bundle 1327 reception status report with reason code "No additional information" 1328 SHOULD be generated, destined for the bundle's report-to endpoint 1329 ID. 1331 Step 3: For each block in the bundle that is an extension block that 1332 the bundle protocol agent cannot process: 1334 . If the block processing flags in that block indicate that a 1335 status report is requested in this event, then a bundle 1336 reception status report with reason code "Block unintelligible" 1337 SHOULD be generated, destined for the bundle's report-to 1338 endpoint ID. 1339 . If the block processing flags in that block indicate that the 1340 bundle must be deleted in this event, then the bundle protocol 1341 agent MUST delete the bundle for the reason "Block 1342 unintelligible"; the bundle deletion procedure defined in 1343 Section 5.13 MUST be followed and all remaining steps of the 1344 bundle reception procedure MUST be skipped. 1345 . If the block processing flags in that block do NOT indicate 1346 that the bundle must be deleted in this event but do indicate 1347 that the block must be discarded, then the bundle protocol 1348 agent MUST remove this block from the bundle. 1349 . If the block processing flags in that block indicate NEITHER 1350 that the bundle must be deleted NOR that the block must be 1351 discarded, then the bundle protocol agent MUST set to 1 the 1352 "Block was forwarded without being processed" flag in the block 1353 processing flags of the block. 1355 Step 4: If the bundle's custody transfer requested flag (in the 1356 bundle processing flags field) is set to 1 and the bundle has the 1357 same source node ID, creation timestamp, and (if the bundle is a 1358 fragment) fragment offset and payload length as another bundle that 1359 (a) has not been discarded and (b) currently has the retention 1360 constraint "Custody accepted", custody transfer redundancy MUST be 1361 handled; otherwise, processing proceeds from Step 5. The bundle 1362 protocol agent MUST handle custody transfer redundancy by generating 1363 a "Failed" custody signal for this bundle with reason code 1364 "Redundant reception", destined for this bundle's current custodian, 1365 and removing this bundle's "Dispatch pending" retention constraint. 1367 Step 5: Processing proceeds from Step 1 of Section 5.3. 1369 5.7. Local Bundle Delivery 1371 The steps in processing a bundle that is destined for an endpoint of 1372 which this node is a member are: 1374 Step 1: If the received bundle is a fragment, the application data 1375 unit reassembly procedure described in Section 5.9 MUST be followed. 1376 If this procedure results in reassembly of the entire original 1377 application data unit, processing of this bundle (whose fragmentary 1378 payload has been replaced by the reassembled application data unit) 1379 proceeds from Step 2; otherwise, the retention constraint 1380 "Reassembly pending" MUST be added to the bundle and all remaining 1381 steps of this procedure MUST be skipped. 1383 Step 2: Delivery depends on the state of the registration whose 1384 endpoint ID matches that of the destination of the bundle: 1386 . If the registration is in the Active state, then the bundle 1387 MUST be delivered subject to this registration (see Section 3.1 1388 above) as soon as all previously received bundles that are 1389 deliverable subject to this registration have been delivered. 1390 . If the registration is in the Passive state, then the 1391 registration's delivery failure action MUST be taken (see 1392 Section 3.1 above). 1394 Step 3: As soon as the bundle has been delivered: 1396 . If the "request reporting of bundle delivery" flag in the 1397 bundle's status report request field is set to 1, then a bundle 1398 delivery status report SHOULD be generated, destined for the 1399 bundle's report-to endpoint ID. Note that this status report 1400 only states that the payload has been delivered to the 1401 application agent, not that the application agent has processed 1402 that payload. 1403 . If the bundle's custody transfer requested flag (in the bundle 1404 processing flags field) is set to 1, custodial delivery MUST be 1405 reported. The bundle protocol agent MUST report custodial 1406 delivery by generating a "Succeeded" custody signal for the 1407 bundle, destined for the bundle's current custodian(s). 1409 5.8. Bundle Fragmentation 1411 It may at times be advantageous for bundle protocol agents to reduce 1412 the sizes of bundles in order to forward them. This might be the 1413 case, for example, if a node to which a bundle is to be forwarded is 1414 accessible only via intermittent contacts and no upcoming contact is 1415 long enough to enable the forwarding of the entire bundle. 1417 The size of a bundle can be reduced by "fragmenting" the bundle. To 1418 fragment a bundle whose payload is of size M is to replace it with 1419 two "fragments" -- new bundles with the same source node ID and 1420 creation timestamp as the original bundle -- whose payloads are the 1421 first N and the last (M - N) bytes of the original bundle's payload, 1422 where 0 < N < M. Note that fragments may themselves be fragmented, 1423 so fragmentation may in effect replace the original bundle with more 1424 than two fragments. (However, there is only one 'level' of 1425 fragmentation, as in IP fragmentation.) 1427 Any bundle that has any Current Custodian extension block citing any 1428 node other than the local node MUST NOT be fragmented. This 1429 restriction aside, any bundle whose primary block's bundle 1430 processing flags do NOT indicate that it must not be fragmented MAY 1431 be fragmented at any time, for any purpose, at the discretion of the 1432 bundle protocol agent. 1434 Fragmentation SHALL be constrained as follows: 1436 . The concatenation of the payloads of all fragments produced by 1437 fragmentation MUST always be identical to the payload of the 1438 fragmented bundle (that is, the bundle that is being 1439 fragmented). Note that the payloads of fragments resulting from 1440 different fragmentation episodes, in different parts of the 1441 network, may be overlapping subsets of the fragmented bundle's 1442 payload. 1443 . The primary block of each fragment MUST differ from that of the 1444 fragmented bundle, in that the bundle processing flags of the 1445 fragment MUST indicate that the bundle is a fragment and both 1446 fragment offset and total application data unit length must be 1447 provided. Additionally, the CRC of the fragmented bundle, if 1448 any, MUST be replaced in each fragment by a new CRC computed 1449 for the primary block of that fragment. 1450 . The payload blocks of fragments will differ from that of the 1451 fragmented bundle as noted above. 1452 . If the fragmented bundle is not a fragment or is the fragment 1453 with offset zero, then all extension blocks of the fragmented 1454 bundle MUST be replicated in the fragment whose offset is zero. 1455 . Each of the fragmented bundle's extension blocks whose "Block 1456 must be replicated in every fragment" flag is set to 1 MUST be 1457 replicated in every fragment. 1458 . Beyond these rules, replication of extension blocks in the 1459 fragments is an implementation matter. 1460 . If the local node is a custodian of the fragmented bundle, then 1461 the BPA MUST release custody of the fragmented bundle before 1462 fragmentation occurs and MUST take custody of every fragment. 1464 5.9. Application Data Unit Reassembly 1466 If the concatenation -- as informed by fragment offsets and payload 1467 lengths -- of the payloads of all previously received fragments with 1468 the same source node ID and creation timestamp as this fragment, 1469 together with the payload of this fragment, forms a byte array whose 1470 length is equal to the total application data unit length in the 1471 fragment's primary block, then: 1473 . This byte array -- the reassembled application data unit -- 1474 MUST replace the payload of this fragment. 1475 . The BPA MUST take custody of each fragmentary bundle whose 1476 payload is a subset of the reassembled application data unit, 1477 for which custody transfer is requested but the BPA has not yet 1478 taken custody. 1479 . The BPA MUST then release custody of every fragment whose 1480 payload is a subset of the reassembled application data unit, 1481 for which it has taken custody. 1482 . The "Reassembly pending" retention constraint MUST be removed 1483 from every other fragment whose payload is a subset of the 1484 reassembled application data unit. 1486 Note: reassembly of application data units from fragments occurs at 1487 the nodes that are members of destination endpoints as necessary; an 1488 application data unit MAY also be reassembled at some other node on 1489 the path to the destination. 1491 5.10. Custody Transfer 1493 The decision as to whether or not to accept custody of a bundle is 1494 an implementation matter that may involve both resource and policy 1495 considerations. 1497 If the bundle protocol agent elects to accept custody of the bundle, 1498 then it must follow the custody acceptance procedure defined in 1499 Section 5.10.1. 1501 5.10.1. Custody Acceptance 1503 Procedures for acceptance of custody of a bundle are defined as 1504 follows. 1506 The retention constraint "Custody accepted" MUST be added to the 1507 bundle. 1509 If the "request reporting of custody acceptance" flag in the 1510 bundle's status report request field is set to 1, a custody 1511 acceptance status report SHOULD be generated, destined for the 1512 report-to endpoint ID of the bundle. However, if a bundle reception 1513 status report was generated for this bundle (Step 1 of Section 5.6) 1514 but has not yet been transmitted, then this report SHOULD be 1515 generated by simply turning on the "Reporting node accepted custody 1516 of bundle" flag in that earlier report. 1518 The bundle protocol agent MUST generate a "Succeeded" custody signal 1519 for the bundle, destined for the bundle's current custodian(s). 1521 The bundle protocol agent MUST assert the new current custodian for 1522 the bundle. It does so by inserting a new Current Custodian 1523 extension block whose value is the node ID of the local node or by 1524 changing the value of an existing Current Custodian extension block 1525 to the local node ID. 1527 The bundle protocol agent MAY set a custody transfer countdown timer 1528 for this bundle; upon expiration of this timer prior to expiration 1529 of the bundle itself and prior to custody transfer success for this 1530 bundle, the custody transfer failure procedure detailed in Section 1531 5.12 MAY be followed. The manner in which the countdown interval for 1532 such a timer is determined is an implementation matter. 1534 The bundle SHOULD be retained in persistent storage if possible. 1536 5.10.2. Custody Release 1538 When custody of a bundle is released, the "Custody accepted" 1539 retention constraint MUST be removed from the bundle and any custody 1540 transfer timer that has been established for this bundle SHOULD be 1541 destroyed. 1543 5.11. Custody Transfer Success 1545 Upon receipt of a "Succeeded" custody signal at a node that is a 1546 custodial node of the bundle identified in the custody signal, 1547 custody of the bundle MUST be released as described in Section 1548 5.10.2. 1550 5.12. Custody Transfer Failure 1552 Custody transfer is determined to have failed at a custodial node 1553 for that bundle when either (a) that node's custody transfer timer 1554 for that bundle (if any) expires or (b) a "Failed" custody signal 1555 for that bundle is received at that node. 1557 Upon determination of custody transfer failure, the action taken by 1558 the bundle protocol agent is implementation-specific and may depend 1559 on the nature of the failure. For example, if custody transfer 1560 failure was inferred from expiration of a custody transfer timer or 1561 was asserted by a "Failed" custody signal with the "Depleted 1562 storage" reason code, the bundle protocol agent might choose to re- 1563 forward the bundle, possibly on a different route (Section 5.4). 1564 Receipt of a "Failed" custody signal with the "Redundant reception" 1565 reason code, on the other hand, might cause the bundle protocol 1566 agent to release custody of the bundle and to revise its algorithm 1567 for computing countdown intervals for custody transfer timers. 1569 5.13. Bundle Deletion 1571 The steps in deleting a bundle are: 1573 Step 1: If the retention constraint "Custody accepted" currently 1574 prevents this bundle from being discarded, then: 1576 . Custody of the node is released as described in Section 5.10.2. 1577 . A bundle deletion status report citing the reason for deletion 1578 MUST be generated, destined for the bundle's report-to endpoint 1579 ID. 1581 Otherwise, if the "request reporting of bundle deletion" flag in the 1582 bundle's status report request field is set to 1, then a bundle 1583 deletion status report citing the reason for deletion SHOULD be 1584 generated, destined for the bundle's report-to endpoint ID. 1586 Step 2: All of the bundle's retention constraints MUST be removed. 1588 5.14. Discarding a Bundle 1590 As soon as a bundle has no remaining retention constraints it MAY be 1591 discarded. 1593 5.15. Canceling a Transmission 1595 When requested to cancel a specified transmission, where the bundle 1596 created upon initiation of the indicated transmission has not yet 1597 been discarded, the bundle protocol agent MUST delete that bundle 1598 for the reason "transmission cancelled". For this purpose, the 1599 procedure defined in Section 5.13 MUST be followed. 1601 6. Administrative Record Processing 1603 6.1. Administrative Records 1605 Administrative records are standard application data units that are 1606 used in providing some of the features of the Bundle Protocol. Two 1607 types of administrative records have been defined to date: bundle 1608 status reports and custody signals. Note that additional types of 1609 administrative records may be defined by supplementary DTN protocol 1610 specification documents. 1612 Every administrative record consists of: 1614 . Record type code (an unsigned integer for which valid values 1615 are as defined below). 1616 . Record content in type-specific format. 1618 Valid administrative record type codes are defined as follows: 1620 +---------+--------------------------------------------+ 1622 | Value | Meaning | 1624 +=========+============================================+ 1626 | 1 | Bundle status report. | 1628 +---------+--------------------------------------------+ 1629 | 2 | Custody signal. | 1631 +---------+--------------------------------------------+ 1633 | (other) | Reserved for future use. | 1635 +---------+--------------------------------------------+ 1637 Figure 2: Administrative Record Type Codes 1639 The contents of the two types of administrative records defined in 1640 the present document are described below. 1642 6.1.1. Bundle Status Reports 1644 The transmission of 'bundle status reports' under specified 1645 conditions is an option that can be invoked when transmission of a 1646 bundle is requested. These reports are intended to provide 1647 information about how bundles are progressing through the system, 1648 including notices of receipt, custody transfer, forwarding, final 1649 delivery, and deletion. They are transmitted to the Report-to 1650 endpoints of bundles. 1652 Every bundle status report comprises the following fields, in this 1653 order: 1655 . Status flags. The following conditions are asserted by the 1656 bundle status report status flags (all Boolean): 1657 o Reporting node received bundle. 1658 o Reporting node accepted custody of bundle. 1659 o Reporting node forwarded the bundle. 1660 o Reporting node delivered the bundle. 1661 o Reporting node deleted the bundle. 1662 . Reason code, an unsigned integer explaining the values of the 1663 status flags. Status report reason codes are as defined below, 1664 but the list of status report reason codes provided here is 1665 neither exhaustive nor exclusive; supplementary DTN protocol 1666 specifications (including, but not restricted to, the Bundle 1667 Security Protocol [BPSECBSP]) may define additional reason 1668 codes. 1669 . Status times, a pair ofone unsigned integers for each condition 1670 asserted by any status flag, that indicatinge the time (as 1671 reported by the local system clock, an implementation matter) 1672 at which the indicated condition became true for this bundle 1673 whose status is being reported entered that status. Theseis 1674 fields are is included in the status report if and only if the 1675 "Report status time" flag was set to 1 in the subject bundle's 1676 bundle processing flags. Status time is expressed as:in 1677 seconds since the start of the year 2000, on the Coordinated 1678 Universal Time (UTC) scale [UTC]. 1679 o Nanoseconds within the indicated second. 1680 . Source node, the node ID of the source of the bundle whose 1681 status is being reported. 1682 . Creation timestamp, the creation timestamp of the bundle whose 1683 status is being reported. 1684 . Fragment offset, the fragment offset of the bundle whose status 1685 is being reported (omitted if omitted from the subject bundle's 1686 primary block). 1687 . Fragment length, the length of the payload of the bundle whose 1688 status is being reported (omitted if fragment offset is omitted 1689 from the subject bundle's primary block). 1691 Valid status report reason codes are defined as follows: 1693 +---------+--------------------------------------------+ 1695 | Value | Meaning | 1697 +=========+============================================+ 1699 | 0 | No additional information. | 1701 +---------+--------------------------------------------+ 1703 | 1 | Lifetime expired. | 1705 +---------+--------------------------------------------+ 1707 | 2 | Forwarded over unidirectional link. | 1709 +---------+--------------------------------------------+ 1711 | 3 | Transmission canceled. | 1713 +---------+--------------------------------------------+ 1715 | 4 | Depleted storage. | 1717 +---------+--------------------------------------------+ 1719 | 5 | Destination endpoint ID unintelligible. | 1721 +---------+--------------------------------------------+ 1722 | 6 | No known route to destination from here. | 1724 +---------+--------------------------------------------+ 1726 | 7 | No timely contact with next node on route. | 1728 +---------+--------------------------------------------+ 1730 | 8 | Block unintelligible. | 1732 +---------+--------------------------------------------+ 1734 | (other) | Reserved for future use. | 1736 +---------+--------------------------------------------+ 1738 Figure 3: Status Report Reason Codes 1740 6.1.2. Custody Signals 1742 Custody signals are administrative records that effect custody 1743 transfer operations. They are transmitted to the nodes that are the 1744 current custodians of bundles. 1746 Every custody signal comprises the following fields, in this order: 1748 . "Custody transfer succeeded" flag (Boolean). 1749 . Reason code, an unsigned integer explaining the value of the 1750 "Custody transfer succeeded" flag. Custody signal reason codes 1751 are as defined below. 1752 . Source node, the node ID of the source of the bundle for which 1753 custodial activity is being reported. 1754 . Creation timestamp, the creation timestamp of the bundle for 1755 which custodial activity is being reported. 1756 . Fragment offset, the fragment offset of the bundle for which 1757 custodial activity is being reported (omitted if omitted from 1758 the subject bundle's primary block). 1759 . Fragment length, the length of the payload of the bundle for 1760 which custodial activity is being reported (omitted if fragment 1761 offset is omitted from the subject bundle's primary block). 1763 Valid custody signal reason codes are defined as follows: 1765 +---------+--------------------------------------------+ 1767 | Value | Meaning | 1768 +=========+============================================+ 1770 | 0 | No additional information. | 1772 +---------+--------------------------------------------+ 1774 | 1 | Reserved for future use. | 1776 +---------+--------------------------------------------+ 1778 | 2 | Reserved for future use. | 1780 +---------+--------------------------------------------+ 1782 | 3 | Redundant (reception by a node that is a | 1784 | | custodial node for this bundle). | 1786 +---------+--------------------------------------------+ 1788 | 4 | Depleted storage. | 1790 +---------+--------------------------------------------+ 1792 | 5 | Destination endpoint ID unintelligible. | 1794 +---------+--------------------------------------------+ 1796 | 6 | No known route destination from here. | 1798 +---------+--------------------------------------------+ 1800 | 7 | No timely contact with next node on route. | 1802 +---------+--------------------------------------------+ 1804 | 8 | Block unintelligible. | 1806 +---------+--------------------------------------------+ 1808 | (other) | Reserved for future use. | 1810 +---------+--------------------------------------------+ 1812 Figure 4: Custody Signal Reason Codes 1814 6.2. Generation of Administrative Records 1816 Whenever the application agent's administrative element is directed 1817 by the bundle protocol agent to generate an administrative record 1818 with reference to some bundle, the following procedure must be 1819 followed: 1821 Step 1: The administrative record must be constructed. If the 1822 referenced bundle is a fragment, the administrative record MUST 1823 contain the fragment offset and fragment length. 1825 Step 2: A request for transmission of a bundle whose payload is this 1826 administrative record MUST be presented to the bundle protocol 1827 agent. 1829 6.3. Reception of Custody Signals 1831 For each received custody signal that has the "custody transfer 1832 succeeded" flag set to 1, the administrative element of the 1833 application agent MUST direct the bundle protocol agent to follow 1834 the custody transfer success procedure in Section 5.11. 1836 For each received custody signal that has the "custody transfer 1837 succeeded" flag set to 0, the administrative element of the 1838 application agent MUST direct the bundle protocol agent to follow 1839 the custody transfer failure procedure in Section 5.12. 1841 7. Services Required of the Convergence Layer 1843 7.1. The Convergence Layer 1845 The successful operation of the end-to-end bundle protocol depends 1846 on the operation of underlying protocols at what is termed the 1847 "convergence layer"; these protocols accomplish communication 1848 between nodes. A wide variety of protocols may serve this purpose, 1849 so long as each convergence layer protocol adapter provides a 1850 defined minimal set of services to the bundle protocol agent. This 1851 convergence layer service specification enumerates those services. 1853 7.2. Summary of Convergence Layer Services 1855 Each convergence layer protocol adapter is expected to provide the 1856 following services to the bundle protocol agent: 1858 . sending a bundle to a bundle node that is reachable via the 1859 convergence layer protocol; 1861 . delivering to the bundle protocol agent a bundle that was sent 1862 by a bundle node via the convergence layer protocol. 1864 The convergence layer service interface specified here is neither 1865 exhaustive nor exclusive. That is, supplementary DTN protocol 1866 specifications (including, but not restricted to, the Bundle 1867 Security Protocol [BSPBPSEC]) may expect convergence layer adapters 1868 that serve BP implementations conforming to those protocols to 1869 provide additional services such as retransmitting data that were 1870 lost in transit, discarding bundle-conveying data units that the 1871 convergence layer protocol determines are corrupt or inauthentic, or 1872 reporting on the integrity and/or authenticity of delivered bundles. 1874 8. Security Considerations 1876 The bundle protocol has taken security into concern from the outset 1877 of its design. It was always assumed that security services would be 1878 needed in the use of the bundle protocol. As a result, the bundle 1879 protocol security architecture and the available security services 1880 are specified in an accompanying document, the Bundle Security 1881 Protocol specification [BSPBPSEC]; an informative overview of this 1882 architecture is provided in [SECO]. 1884 The bundle protocol has been designed with the notion that it will 1885 may be run over networks with scarce resources. For example, the 1886 networks might have limited bandwidth, limited connectivity, 1887 constrained storage in relay nodes, etc. Therefore, the bundle 1888 protocol must ensure that only those entities authorized to send 1889 bundles over such constrained environments are actually allowed to 1890 do so. All unauthorized entities should be prevented from consuming 1891 valuable resources as soon as practicable. 1893 Likewise, because of the potentially high latencies and delays 1894 involved in the networks that make use of the bundle protocol, data 1895 sources should be concerned with the integrity of the data received 1896 at the intended destination(s) and may also be concerned with 1897 ensuring confidentiality of the data as it traverses the network. 1898 Without integrity, the bundle payload data might be corrupted while 1899 in transit without the destination able to detect it. Similarly, the 1900 data source can be concerned with ensuring that the data can only be 1901 used by those authorized, hence the need for confidentiality. 1903 Internal to the bundle-aware overlay network, the bundle nodes 1904 should be concerned with the authenticity of other bundle nodes as 1905 well as the preservation of bundle payload data integrity as it is 1906 forwarded between bundle nodes. 1908 As a result, bundle security is concerned with the authenticity, 1909 integrity, and confidentiality of bundles conveyed among bundle 1910 nodes. This is accomplished via the use of two independent security- 1911 specific bundle blocks, which may be used together to provide 1912 multiple bundle security services or independently of one another, 1913 depending on perceived security threats, mandated security 1914 requirements, and security policies that must be enforced. 1916 To provide end-to-end bundle authenticity and integrity, the Block 1917 Integrity Block (BIB) is used. The BIB allows any security-enabled 1918 entity along the delivery path to ensure the integrity of the 1919 bundle's payload or any other block other than a Block 1920 Confidentiality Block. 1922 To provide payload confidentiality, the use of the Block 1923 Confidentiality Block (BCB) is available. The bundle payload, or any 1924 other block aside from the primary block and the Bundle Security 1925 Protocol blocks, may be encrypted to provide end-to-end payload 1926 confidentiality/privacy. 1928 Additionally, convergence-layer protocols that ensure authenticity 1929 of communication between adjacent nodes in BP network topology 1930 SHOULD be used where available, to minimize the ability of 1931 unauthenticated nodes to introduce inauthentic traffic into the 1932 network. 1934 Bundle security MUST NOT be invalidated by forwarding nodes even 1935 though they themselves might not use the Bundle Security Protocol. 1937 In particular, while blocks MAY be added to bundles transiting 1938 intermediate nodes, removal of blocks with the 'Discard block if it 1939 can't be processed' flag unset in the block processing control flags 1940 may cause security to fail. 1942 Inclusion of the Bundle Security Protocol in any Bundle Protocol 1943 implementation is RECOMMENDED. Use of the Bundle Security Protocol 1944 in Bundle Protocol operations is OPTIONAL. 1946 9. IANA Considerations 1948 The "dtn" and "ipn" URI schemes have been provisionally registered 1949 by IANA. See http://www.iana.org/assignments/uri-schemes.html for 1950 the latest details. 1952 Registries of scheme type numbers, extension block type numbers, and 1953 administrative record type numbers will be required. 1955 10. References 1957 10.1. Normative References 1959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1960 Requirement Levels", BCP 14, RFC 2119, March 1997. 1962 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1963 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 1964 January 2005. 1966 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 1967 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 1968 2015. 1970 10.2. Informative References 1972 [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 1973 4838, April 2007. 1975 [ASN1] "Abstract Syntax Notation One (ASN.1), "ASN.1 Encoding Rules: 1976 Specification of Basic Encoding Rules (BER), Canonical Encoding 1977 Rules (CER) and Distinguished Encoding Rules (DER)," ITU-T Rec. 1978 X.690 (2002) | ISO/IEC 8825- 1:2002", 2003. 1980 [BSPBPSEC] SymingtonBirrane, ES., "Bundle Security Protocol 1981 Specification", Work In Progress, October 2015. 1983 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1984 Identifiers (IRIs)", RFC 3987, January 2005. 1986 [RFC5050] Scott, M. and S. Burleigh, "Bundle Protocol 1987 Specification", RFC 5050, November 2007. 1989 [SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay- 1990 Tolerant Networking Security Overview", Work Progress, July 2007. 1992 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 1993 Challenged Internets", SIGCOMM 2003. 1995 [TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A Tutorial", 1996 . 1998 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 1999 historical background and perspectives" in "Journees systemes de 2000 reference spatio-temporels", 2004. 2002 11. Acknowledgments 2004 This work is freely adapted from [RFC5050], which was an effort of 2005 the Delay Tolerant Networking Research Group. The following DTNRG 2006 participants contributed significant technical material and/or 2007 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 2008 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 2009 Michael Demmer of the University of California at Berkeley, Robert 2010 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 2011 Kevin Fall of Intel ResearchCarnegie Mellon University, Stephen 2012 Farrell of Trinity College Dublin, Peter Lovell of SPARTA, Inc., 2013 Manikantan Ramadas of Ohio University, and Howard Weiss of SPARTA, 2014 Inc. 2016 This document was prepared using 2-Word-v2.0.template.dot. 2018 12. Significant Changes from RFC 5050 2020 Points on which this draft significantly differs from RFC 5050 2021 include the following: 2023 . Clarify the difference between transmission and forwarding. 2024 . Amplify discussion of custody transfer. Move current custodian 2025 to an extension block, of which there can be multiple 2026 occurrences (possible support for the MITRE idea of multiple 2027 concurrent custodians, from several years ago); define that 2028 block in this specification. 2029 . Introduce the concept of "node ID" as functionally distinct 2030 from endpoint ID, while having the same syntax. 2031 . Add ECOS features to primary block. 2032 . Restrict the scope of bundle prioritization to all bundles from 2033 the same source. 2034 . Restructure primary block, making it immutable. Add optional 2035 CRC and inventory. 2036 . Add optional CRCs to non-primary blocks. 2037 . Add block ID number to canonical block format (to support 2038 streamlined BSP). 2039 . Add bundle age extension block, defined in this specification. 2040 . Add previous node ID extension block, defined in this 2041 specification. 2042 . Add flow label block, *not* defined in this specification. 2043 . Add hop count extension block, defined in this specification. 2044 . Clean up a conflict between fragmentation and custody transfer 2045 that Ed Birrane pointed out. 2046 . Clarify that the class of service field indicates priority and 2047 increase its maximum value to 127. 2049 . Remove representation specifications from the document, making 2050 the protocol specification representation-neutral. 2052 13. Open Issues 2054 13.1. Application Agent 2056 Need to add a diagram explaining how the various components of the 2057 BPA interact. 2059 13.2. Alignment with ICN 2061 Is it necessary to modify the bundle transmission procedure to 2062 enable BP to be used for information-centric networking, i.e., 2063 delivering data to a node who requests that data after it has 2064 already been transmitted? Specifically, would a DTN ICN cache point 2065 "transmit" data to a client (i.e., source a new bundle) or would it 2066 merely "forward" a previously transmitted bundle of which it has 2067 retained a copy? 2069 13.3. Implementation Architectures 2071 Should the BP spec be divided into two documents? One to talk about 2072 conops and context and one that focuses specifically on the 2073 protocol? 2075 13.4. Extended class of service features 2077 Should these features (critical bundle, best-efforts forwarding 2078 requested, reliable forwarding requested) be omitted from the 2079 primary block? If they are omitted, should these application- 2080 selected CoS markings be supported in some other way? If the 2081 "critical" CoS feature is retained, should it have a different name? 2083 Note: a node selection (route computation) procedure might consider 2084 the availability of CLAs that match the bundle's CoS when selecting 2085 a node to forward to, and that is entirely the business of the route 2086 computation procedure. (Not all route computation procedures will 2087 do so.) 2089 13.5. 13.2. Primary block CRC type 2091 What are the best CRC options to support here? CRC-16-ARINC, CRC- 2092 16-CCITT, CRC-16-CDMA2000, CRC-16-DECT, etc.? 2094 13.6. Inventory 2096 Is a list of all types of blocks in the bundle as forwarded by the 2097 source node a good implementation of the requested "inventory" 2098 feature? If not, what would be better? 2100 13.7. Clearing flag 2102 Should a node that is able to process a given extension block be 2103 permitted to clear block's "Block was forwarded without being 2104 processed" flag? 2106 13.8. Time of forwarding 2108 Should the BPA control the time at which a bundle is to be forwarded 2109 to another node, or should that determination be left to the 2110 selected convergence-layer protocol adapter(s)? 2112 13.9. Block multiplicity 2114 Would it be good to restrict BP extensions to one extension block 2115 per extension per bundle? That is, should we require that all 2116 information needed to implement a given BP extension for a given 2117 bundle be contained in a single extension block? 2119 This would entail encapsulating any necessary multiplicity for a 2120 given extension (for example, multiple Metadata records) within a 2121 single block. 2123 Among the advantages: no need for block numbers (block type would 2124 always be sufficient to identify the block), therefore no need for a 2125 block number generation mechanism; shorter and simpler inventory; 2126 simpler extension implementation (all information is in one block, 2127 no need to search through extension blocks for additional relevant 2128 information). 2130 Among the disadvantages: very different from RFC 5050; would in some 2131 cases require that security blocks operate on data structures that 2132 are internal to extension blocks rather than always operate on 2133 entire extension blocks. 2135 Appendix A. For More Information 2137 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 2138 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 2140 Copyright (c) 2015 IETF Trust and the persons identified as authors 2141 of the code. All rights reserved. 2143 Redistribution and use in source and binary forms, with or without 2144 modification, is permitted pursuant to, and subject to the license 2145 terms contained in, the Simplified BSD License set forth in Section 2146 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2147 (http://trustee.ietf.org/license-info). 2149 Authors' Addresses 2151 Scott Burleigh 2152 Jet Propulsion Laboratory, California Institute of Technology 2153 4800 Oak Grove Dr. 2154 Pasadena, CA 91109-8099 2155 US 2156 Phone: +1 818 393 3353 2157 Email: Scott.Burleigh@jpl.nasa.gov 2159 Kevin Fall 2160 Carnegie Mellon University / Software Engineering Institute 2161 4500 Fifth Avenue 2162 Pittsburgh, PA 15213 2163 US 2164 Phone: +1 412 268 3304 2165 Email: kfall@cmu.edu 2167 Edward J. Birrane 2168 Johns Hopkins University Applied Physics Laboratory 2169 11100 Johns Hopkins Rd 2170 Laurel, MD 20723 2171 US 2172 Phone: +1 443 778 7423 2173 Email: Edward.Birrane@jhuapl.edu