idnits 2.17.1 draft-ietf-dtn-bpbis-00.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 (July 30, 2015) is 3193 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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: January 2016 Carnegie Mellon University / SEI 5 E. Birrane 6 APL, Johns Hopkins University 7 July 30, 2015 9 Bundle Protocol 10 draft-ietf-dtn-bpbis-00.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 July 21, 2015. 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 59 in Section 4.e of the Trust Legal Provisions and are provided 60 without 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...................................................4 72 2. Conventions used in this document..............................6 73 3. Service Description............................................6 74 3.1. Definitions...............................................6 75 3.2. Implementation Architectures.............................12 76 3.2.1. Bundle protocol application server..................12 77 3.2.2. Peer application nodes..............................13 78 3.2.3. Sensor network nodes................................13 79 3.2.4. Dedicated bundle router.............................13 80 3.3. Services Offered by Bundle Protocol Agents...............13 81 4. Bundle Format.................................................14 82 4.1. Self-Delimiting Numeric Values (SDNVs)...................14 83 4.2. Bundle Processing Control Flags..........................16 84 4.3. Block Processing Control Flags...........................18 85 4.4. Identifiers..............................................19 86 4.4.1. Endpoint ID.........................................19 87 4.4.2. Node ID.............................................20 88 4.5. Formats of Bundle Blocks.................................21 89 4.5.1. Primary Bundle Block................................23 90 4.5.2. Canonical Bundle Block Format.......................25 91 4.5.3. Bundle Payload Block................................26 92 4.6. Extension Blocks.........................................27 93 4.6.1. Current Custodian...................................27 94 4.6.2. Flow Label..........................................28 95 4.6.3. Previous Node ID....................................28 96 4.6.4. Bundle Age..........................................28 97 4.6.5. Hop Count...........................................28 98 5. Bundle Processing.............................................29 99 5.1. Generation of Administrative Records.....................29 100 5.2. Bundle Transmission......................................30 101 5.3. Bundle Dispatching.......................................30 102 5.4. Bundle Forwarding........................................31 103 5.4.1. Forwarding Contraindicated..........................33 104 5.4.2. Forwarding Failed...................................33 105 5.5. Bundle Expiration........................................34 106 5.6. Bundle Reception.........................................34 107 5.7. Local Bundle Delivery....................................35 108 5.8. Bundle Fragmentation.....................................36 109 5.9. Application Data Unit Reassembly.........................37 110 5.10. Custody Transfer........................................38 111 5.10.1. Custody Acceptance.................................38 112 5.10.2. Custody Release....................................39 113 5.11. Custody Transfer Success................................39 114 5.12. Custody Transfer Failure................................39 115 5.13. Bundle Deletion.........................................39 116 5.14. Discarding a Bundle.....................................40 117 5.15. Canceling a Transmission................................40 118 6. Administrative Record Processing..............................40 119 6.1. Administrative Records...................................40 120 6.1.1. Bundle Status Reports...............................41 121 6.1.2. Custody Signals.....................................45 122 6.2. Generation of Administrative Records.....................47 123 6.3. Reception of Custody Signals.............................48 124 7. Services Required of the Convergence Layer....................48 125 7.1. The Convergence Layer....................................48 126 7.2. Summary of Convergence Layer Services....................48 127 8. Security Considerations.......................................49 128 9. IANA Considerations...........................................50 129 10. References...................................................50 130 10.1. Normative References....................................50 131 10.2. Informative References..................................51 132 11. Acknowledgments..............................................51 133 12. Significant Changes From RFC 5050............................52 134 13. Open Issues..................................................52 135 13.1. Definitions section structure...........................52 136 13.2. Payload nomenclature....................................53 137 13.3. Application Agent.......................................53 138 13.4. Bundle Endpoint definition..............................53 139 13.5. Alignment with ICN......................................53 140 13.6. Implementation Architectures............................53 141 13.7. Security protocol name..................................54 142 13.8. Bundle format...........................................54 143 13.9. SDNVs...................................................54 144 13.10. Bundle Processing Control Flags........................54 145 13.11. Extended class of service features.....................54 146 13.12. Primary block CRC type.................................54 147 13.13. Inventory..............................................54 148 13.14. Block numbers..........................................55 149 13.15. Clearing flag..........................................55 150 13.16. Overriding BP spec.....................................55 151 13.17. Time of forwarding.....................................55 152 13.18. Block multiplicity.....................................55 153 Appendix A. For More Information.................................56 155 1. Introduction 157 Since the publication of the Bundle Protocol Specification 158 (Experimental RFC 5050[RFC5050]) in 2007, the Delay-Tolerant 159 Networking Bundle Protocol has been implemented in multiple 160 programming languages and deployed to a wide variety of computing 161 platforms for a wide range of successful exercises. This 162 implementation and deployment experience has demonstrated the 163 general utility of the protocol for challenged network operations. 165 It has also, as expected, identified opportunities for making the 166 protocol simpler, more capable, and easier to use. The present 167 document, standardizing the Bundle Protocol (BP), is adapted from 168 RFC 5050 in that context. 170 This document describes version 7 of BP. 172 Delay Tolerant Networking is a network architecture providing 173 communications in and/or through highly stressed environments. 174 Stressed networking environments include those with intermittent 175 connectivity, large and/or variable delays, and high bit error 176 rates. To provide its services, BP sits at the application layer of 177 some number of constituent networks, forming a store-carry-forward 178 overlay network. Key capabilities of BP include: 180 . Custodial forwarding 181 . Ability to cope with intermittent connectivity 182 . Ability to take advantage of scheduled, predicted, and 183 opportunistic connectivity (in addition to continuous 184 connectivity) 185 . Late binding of overlay network endpoint identifiers to 186 underlying constituent network addresses 188 For descriptions of these capabilities and the rationale for the DTN 189 architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial- 190 level overview of DTN concepts. 192 BP's location within the standard protocol stack is as shown in 193 Figure 1. BP uses underlying "native" network protocols for 194 communications within a given constituent network. 196 The interface between the bundle protocol and a specific underlying 197 protocol is termed a "convergence layer adapter". 199 Figure 1 shows three distinct transport and network protocols 200 (denoted T1/N1, T2/N2, and T3/N3). 202 +-----------+ +-----------+ 203 | BP app | | BP app | 204 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 205 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 206 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 207 | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | 208 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 209 | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | 210 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 211 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 212 +-----------+ +-------------+ +-------------+ +-----------+ 213 | | | | 214 |<---- A network ---->| |<---- A network ---->| 215 | | | | 217 Figure 1: The Bundle Protocol Sits at the Application Layer of the 218 Protocol Stack Model 220 This document describes the format of the protocol data units 221 (called bundles) passed between entities participating in BP 222 communications. 224 The entities are referred to as "bundle nodes". This document does 225 not address: 227 . Operations in the convergence layer adapters that bundle nodes 228 use to transport data through specific types of internets. 229 (However, the document does discuss the services that must be 230 provided by each adapter at the convergence layer.) 231 . The bundle route computation algorithm. 232 . Mechanisms for populating the routing or forwarding information 233 bases of bundle nodes. 234 . The mechanisms for securing bundles en-route. 236 . The mechanisms for managing bundle nodes. 238 2. Conventions used in this document 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 242 document are to be interpreted as described in RFC-2119 [RFC2119]. 244 In this document, these words will appear with that interpretation 245 only when in ALL CAPS. Lower case uses of these words are not to be 246 interpreted as carrying RFC-2119 significance. 248 3. Service Description 250 3.1. Definitions 252 Bundle - A bundle is a protocol data unit of BP, so named because 253 negotiation of the parameters of a data exchange may be impractical 254 in a delay-tolerant network: it is often better practice to "bundle" 255 with a unit of data all metadata that might be needed in order to 256 make the data immediately usable when delivered to applications. 257 Each bundle comprises a sequence of two or more "blocks" of protocol 258 data, which serve various purposes. Multiple instances of the same 259 bundle (the same unit of DTN protocol data) might exist concurrently 260 in different parts of a network -- possibly in different 261 representations and/or differing in some blocks -- in the memory 262 local to one or more bundle nodes and/or in transit between nodes. 263 In the context of the operation of a bundle node, a bundle is an 264 instance of some bundle in the network that is in that node's local 265 memory. 267 Bundle payload - A bundle payload (or simply "payload") is the 268 application data whose conveyance to the bundle's destination is the 269 purpose for the transmission of a given bundle. The terms "bundle 270 content", "bundle payload", and "payload" are used interchangeably 271 in this document. The "nominal" payload for a bundle forwarded in 272 response to a bundle transmission request is the application data 273 unit whose location is provided as a parameter to that request. The 274 nominal payload for a bundle forwarded in response to reception of 275 that bundle is the payload of the received bundle. 277 Fragment - A fragment is a bundle whose payload block contains a 278 fragmentary payload. A fragmentary payload is either the first N 279 bytes or the last N bytes of some other payload -- either a nominal 280 payload or a fragmentary payload -- of length M, such that 0 < N < 281 M. 283 Bundle node - A bundle node (or, in the context of this document, 284 simply a "node") is any entity that can send and/or receive bundles. 285 In the most familiar case, a bundle node is instantiated as a single 286 process running on a general-purpose computer, but in general the 287 definition is meant to be broader: a bundle node might alternatively 288 be a thread, an object in an object-oriented operating system, a 289 special-purpose hardware device, etc. Each bundle node has three 290 conceptual components, defined below: a "bundle protocol agent", a 291 set of zero or more "convergence layer adapters", and an 292 "application agent". 294 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 295 the node component that offers the BP services and executes the 296 procedures of the bundle protocol. The manner in which it does so is 297 wholly an implementation matter. For example, BPA functionality 298 might be coded into each node individually; it might be implemented 299 as a shared library that is used in common by any number of bundle 300 nodes on a single computer; it might be implemented as a daemon 301 whose services are invoked via inter-process or network 302 communication by any number of bundle nodes on one or more 303 computers; it might be implemented in hardware. 305 Convergence layer adapters - A convergence layer adapter (CLA) sends 306 and receives bundles on behalf of the BPA, utilizing the services 307 of some 'native' protocol stack that is supported in one of the 308 networks within which the node is functionally located. As such, 309 every CLA implements its own thin layer of protocol, interposed 310 between BP and the (usually "top") protocol(s) of the underlying 311 native protocol stack; this "CL protocol" may only serve to 312 multiplex and de-multiplex bundles to and from the underlying native 313 protocol, or it may offer additional CL-specific functionality. The 314 manner in which a CLA sends and receives bundles is wholly an 315 implementation matter, exactly as described for the BPA. The 316 definitions of CLAs and CL protocols are beyond the scope of this 317 specification. 319 Application agent - The application agent (AA) of a node is the node 320 component that utilizes the BP services to effect communication for 321 some purpose. The application agent in turn has two elements, an 322 administrative element and an application-specific element. The 323 application-specific element of an AA constructs, requests 324 transmission of, accepts delivery of, and processes application- 325 specific application data units; the only interface between the BPA 326 and the application-specific element of the AA is the BP service 327 interface. The administrative element of an AA constructs and 328 requests transmission of administrative records (including status 329 reports and custody signals), and it accepts delivery of and 330 processes any custody signals that the node receives. In addition to 331 the BP service interface, there is a (conceptual) private control 332 interface between the BPA and the administrative element of the AA 333 that enables each to direct the other to take action under specific 334 circumstances. In the case of a node that serves simply as a BP 335 "router", the AA may have no application-specific element at all. 336 The application-specific elements of other nodes' AAs may perform 337 arbitrarily complex application functions, perhaps even offering 338 multiplexed DTN communication services to a number of other 339 applications. As with the BPA, the manner in which the AA performs 340 its functions is wholly an implementation matter. 342 Administrative record - A BP administrative record is an application 343 data unit that is exchanged between the administrative elements of 344 nodes' application agents for some BP administrative purpose. The 345 formats of some fundamental administrative records (and of no other 346 application data units) are defined in this specification. 348 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 349 of zero or more bundle nodes that all identify themselves for BP 350 purposes by some common identifier, called a "bundle endpoint ID" 351 (or, in this document, simply "endpoint ID"; endpoint IDs are 352 described in detail in Section 4.4.4 below). The special case of an 353 endpoint that contains exactly one node is termed a "singleton" 354 endpoint. Singletons are the most familiar sort of endpoint, but in 355 general the endpoint notion is meant to be broader. For example, the 356 nodes in a sensor network might constitute a set of bundle nodes 357 that identify themselves by a single common endpoint ID and thus 358 form a single bundle endpoint. For a bundle to be considered 359 "delivered" to an endpoint, a minimum number of receiving nodes may 360 be required to receive it successfully. This lower limit is called 361 the minimum reception group, and is defined in the Transmission 362 discussion below. *Note* too that a given bundle node might 363 identify itself by multiple endpoint IDs and thus be a member of 364 multiple bundle endpoints. The destination of every bundle is an 365 endpoint, which may or may not be singleton. The source of every 366 bundle is a singleton endpoint. 368 Transmission - A transmission is an attempt by a node's BPA to cause 369 copies of a bundle to be delivered at all nodes in the minimum 370 reception group of some endpoint (the bundle's destination) in 371 response to a transmission request issued by the node's application 372 agent. The minimum reception group of an endpoint may be any one of 373 the following: (a) ALL of the nodes registered (see definition 374 below) in an endpoint that is permitted to contain multiple nodes 375 (in which case forwarding to the endpoint is functionally similar to 376 "multicast" operations in the Internet, though possibly very 377 different in implementation); (b) ANY N of the nodes registered in 378 an endpoint that is permitted to contain multiple nodes, where N is 379 in the range from zero to the cardinality of the endpoint; or (c) 380 THE SOLE NODE registered in a singleton endpoint (in which case 381 forwarding to the endpoint is functionally similar to "unicast" 382 operations in the Internet). The nature of the minimum reception 383 group for a given endpoint can be determined from the endpoint's ID 384 (again, see Section 4.4 below): for some endpoint ID "schemes", the 385 nature of the minimum reception group is fixed - in a manner that is 386 defined by the scheme - for all endpoints identified under the 387 scheme; for other schemes, the nature of the minimum reception group 388 is indicated by some lexical feature of the "scheme-specific part" 389 of the endpoint ID, in a manner that is defined by the scheme. Any 390 number of transmissions may be concurrently undertaken by the bundle 391 protocol agent of a given node. 393 Forwarding - When the bundle protocol agent of a node determines 394 that a bundle must be "forwarded" to a node (either a node that is a 395 member of the bundle's destination endpoint or some intermediate 396 forwarding node) in the course of completing the successful 397 transmission of that bundle, it invokes the services of a CLA in a 398 sustained effort to cause a copy of the bundle to be received by 399 that node. 401 Registration - A registration is the state machine characterizing a 402 given node's membership in a given endpoint. Any number of 403 registrations may be concurrently associated with a given endpoint, 404 and any number of registrations may be concurrently associated with 405 a given node. Any single registration must at any time be in one of 406 two states: Active or Passive. A registration always has an 407 associated "delivery failure action", the action that is to be taken 408 when a bundle that is "deliverable" (see below) subject to that 409 registration is received at a time when the registration is in the 410 Passive state. Delivery failure action must be one of the following: 412 . defer "delivery" (see below) of the bundle subject to this 413 registration until (a) this bundle is the least recently 414 received of all bundles currently deliverable subject to this 415 registration and (b) either the registration is polled or else 416 the registration is in the Active state; or 417 . "abandon" (see below) delivery of the bundle subject to this 418 registration. 420 An additional implementation-specific delivery deferral procedure 421 may optionally be associated with the registration. While the state 422 of a registration is Active, reception of a bundle that is 423 deliverable subject to this registration must cause the bundle to be 424 delivered automatically as soon as it is the next bundle that is due 425 for delivery according to the BPA's bundle delivery scheduling 426 policy, an implementation matter. While the state of a registration 427 is Passive, reception of a bundle that is deliverable subject to 428 this registration must cause delivery of the bundle to be abandoned 429 or deferred as mandated by the registration's current delivery 430 failure action; in the latter case, any additional delivery deferral 431 procedure associated with the registration must also be performed. 433 Delivery - Upon reception, the processing of a bundle that has been 434 received by a given node depends on whether or not the receiving 435 node is registered in the bundle's destination endpoint. If it is, 436 and if the payload of the bundle is non-fragmentary (possibly as a 437 result of successful payload reassembly from fragmentary payloads, 438 including the original payload of the received bundle), then the 439 bundle is normally "delivered" to the node's application agent 440 subject to the registration characterizing the node's membership in 441 the destination endpoint. A bundle is considered to have been 442 delivered at a node subject to a registration as soon as the 443 application data unit that is the payload of the bundle, together 444 with the value of the bundle's "Acknowledgement by application is 445 requested" flag and any other relevant metadata (an implementation 446 matter), has been presented to the node's application agent in a 447 manner consistent with the state of that registration and, as 448 applicable, the registration's delivery failure action. 450 Deliverability, Abandonment - A bundle is considered "deliverable" 451 subject to a registration if and only if (a) the bundle's 452 destination endpoint is the endpoint with which the registration is 453 associated, (b) the bundle has not yet been delivered subject to 454 this registration, and (c) delivery of the bundle subject to this 455 registration has not been abandoned. To "abandon" delivery of a 456 bundle subject to a registration is simply to declare it no longer 457 deliverable subject to that registration; normally only 458 registrations' registered delivery failure actions cause deliveries 459 to be abandoned. 461 Deletion, Discarding - A bundle protocol agent "discards" a bundle 462 by simply ceasing all operations on the bundle and functionally 463 erasing all references to it; the specific procedures by which this 464 is accomplished are an implementation matter. Bundles are discarded 465 silently; i.e., the discarding of a bundle does not result in 466 generation of an administrative record. "Retention constraints" are 467 elements of the bundle state that prevent a bundle from being 468 discarded; a bundle cannot be discarded while it has any retention 469 constraints. A bundle protocol agent "deletes" a bundle in response 470 to some anomalous condition by notifying the bundle's report-to node 471 of the deletion (provided such notification is warranted; see 472 Section 5.13 for details) and then arbitrarily removing all of the 473 bundle's retention constraints, enabling the bundle to be discarded. 475 Custody - A node "takes custody" of a bundle when it determines that 476 it will retain a copy of the bundle for some period, forwarding and 477 possibly re-forwarding the bundle as appropriate and destroying that 478 retained copy only when custody of that bundle is formally 479 "released". Custody of a bundle may only be taken if the destination 480 of the bundle is a singleton endpoint. A "custodial node" (or 481 "custodian") of a bundle is a node that has taken custody of the 482 bundle and has not yet released that custody. To "accept custody" 483 upon receiving a bundle is to take custody of the bundle, mark the 484 bundle in such a way as to indicate to nodes that subsequently 485 receive the bundle that it has taken custody, and notify all current 486 custodians of the bundle that it has taken custody. Custody may only 487 be released when either (a) notification is received that some other 488 node has accepted custody of the same bundle; (b) notification is 489 received that the bundle has been delivered at the (sole) node 490 registered in the bundle's destination endpoint; (c) the current 491 custodian chooses to fragment the bundle, releasing custody of the 492 original bundle and taking custody of the fragments instead, or (d) 493 the bundle is explicitly deleted for some reason, such as lifetime 494 expiration. To "refuse custody" of a bundle is to notify all current 495 custodians of that bundle that an opportunity to take custody of the 496 bundle has been declined. 498 The custody transfer mechanism in BP is primarily intended as a 499 means of recovering from forwarding failures. When a bundle arrives 500 at a node from which it cannot be forwarded, BP must recover from 501 this error. BP can "return" the bundle back toward some node for 502 forwarding along some different path in the network, or else it can 503 instead send a small "signal" bundle back to such a node, in the 504 event that this node has retained a copy of the bundle ("taken 505 custody") and is therefore able to re-forward the bundle without 506 receiving a copy. Custody transfer sharply reduces the network 507 traffic required for recovery from forwarding failures, at the cost 508 of increased buffer occupancy and state management at the custodial 509 nodes. 511 Note that custodial re-forwarding can also be initiated by 512 expiration of a timer prior to reception of a custody acceptance 513 signal. Since the absence of a custody acceptance signal might be 514 caused by failure to receive the bundle, rather than only a 515 disinclination to take custody, custody transfer can additionally 516 serve as an automated retransmission mechanism. Because custody 517 transfer's only remedy for loss of any part of a bundle is 518 retransmission of the entire bundle (not just the lost portion), 519 custody transfer is a less efficient automated retransmission 520 mechanism than the reliable transport protocols that are typically 521 available at the convergence layer; configuring BPAs to use reliable 522 convergence-layer protocols between nodes is generally the best 523 means of ensuring bundle delivery at the destination node(s). But 524 there are some use cases (typically involving unidirectional links) 525 in which custody transfer in BP may be a more cost-effective 526 solution for reliable transmission between two BP agents than 527 operating retransmission protocols at the convergence layer. 529 Embargo - Forwarding failures are not just operational anomalies; 530 they may also convey information about the network, i.e., a 531 forwarding failure may indicate a sustained lapse in forwarding 532 capability. Since forwarding a bundle to a dead end wastes time and 533 bandwidth, the bundle protocol agent may choose to manage such a 534 lapse by imposing a temporary "embargo" on subsequent forwarding 535 activity that is similar to the forwarding attempt that has been 536 seen to fail. Mechanisms for motivating, imposing, enforcing, and 537 lifting embargoes are beyond the scope of this document. 539 3.2. Implementation Architectures 541 The above definitions are intended to enable the bundle protocol's 542 operations to be specified in a manner that minimizes bias toward 543 any particular implementation architecture. To illustrate the range 544 of interoperable implementation models that might conform to this 545 specification, four example architectures are briefly described 546 below. 548 3.2.1. Bundle protocol application server 550 A single bundle protocol application server, constituting a single 551 bundle node, runs as a daemon process on each computer. The daemon's 552 functionality includes all functions of the bundle protocol agent, 553 all convergence layer adapters, and both the administrative and 554 application-specific elements of the application agent. The 555 application-specific element of the application agent functions as a 556 server, offering bundle protocol service over a local area network: 557 it responds to remote procedure calls from application processes (on 558 the same computer and/or remote computers) that need to communicate 559 via the bundle protocol. The server supports its clients by creating 560 a new (conceptual) node for each one and registering each such node 561 in a client-specified endpoint. The conceptual nodes managed by the 562 server function as clients' bundle protocol service access points. 564 3.2.2. Peer application nodes 566 Any number of bundle protocol application processes, each one 567 constituting a single bundle node, run on each computer. The 568 functionality of the bundle protocol agent, all convergence layer 569 adapters, and the administrative element of the application agent is 570 provided by a library to which each node process is dynamically 571 linked at run time. The application-specific element of each node's 572 application agent is node-specific application code. 574 3.2.3. Sensor network nodes 576 Each node of the sensor network is the self-contained implementation 577 of a single bundle node. All functions of the bundle protocol agent, 578 all convergence layer adapters, and the administrative element of 579 the application agent are implemented in simplified form in 580 hardware, while the application-specific element of each node's 581 application agent is implemented in a programmable microcontroller. 582 Forwarding is rudimentary: all bundles are forwarded on a hard-coded 583 default route. 585 3.2.4. Dedicated bundle router 587 Each computer constitutes a single bundle node that functions solely 588 as a high-performance bundle forwarder. Many standard functions of 589 the bundle protocol agent, the convergence layer adapters, and the 590 administrative element of the application agent are implemented in 591 specialized hardware, but some functions are implemented in a high- 592 speed processor to enable reprogramming as necessary. The node's 593 application agent has no application-specific element. Substantial 594 non-volatile storage resources are provided, and arbitrarily complex 595 forwarding algorithms are supported. 597 3.3. Services Offered by Bundle Protocol Agents 599 The BPA of each node is expected to provide the following services 600 to the node's application agent: 602 . commencing a registration (registering the node in an 603 endpoint); 604 . terminating a registration; 605 . switching a registration between Active and Passive states; 606 . transmitting a bundle to an identified bundle endpoint; 607 . canceling a transmission; 608 . polling a registration that is in the passive state; 609 . delivering a received bundle. 611 4. Bundle Format 613 Each bundle shall be a concatenated sequence of at least two block 614 structures. The first block in the sequence must be a primary bundle 615 block, and no bundle may have more than one primary bundle block. 616 Additional bundle protocol blocks of other types may follow the 617 primary block to support extensions to the bundle protocol, such as 618 the Bundle Security Protocol [BSP]. Exactly one of the blocks in the 619 sequence must be a payload block. The last block in the sequence 620 must have the "last block" flag (in its block processing control 621 flags) set to 1; for every other block in the bundle after the 622 primary block, this flag must be set to zero. 624 4.1. Self-Delimiting Numeric Values (SDNVs) 626 The design of the bundle protocol attempts to reconcile minimal 627 consumption of transmission bandwidth with: 629 . extensibility to address requirements not yet identified, and 630 . scalability across a wide range of network scales and payload 631 sizes. 633 A key strategic element in the design is the use of self-delimiting 634 numeric values (SDNVs). The SDNV encoding scheme is closely adapted 635 from the Abstract Syntax Notation One Basic Encoding Rules for sub- 636 identifiers within an object identifier value [ASN1]. An SDNV is a 637 numeric value encoded in N octets, the last of which has its most 638 significant bit (MSB) set to zero; the MSB of every other octet in 639 the SDNV must be set to 1. The value encoded in an SDNV is the 640 unsigned binary number obtained by concatenating into a single bit 641 string the 7 least significant bits of each octet of the SDNV. The 642 following examples illustrate the encoding scheme for various 643 hexadecimal values. 645 0xABC : 1010 1011 1100 647 is encoded as 649 {1 00 10101} {0 0111100} 651 = 10010101 00111100 653 0x1234 : 0001 0010 0011 0100 655 = 1 0010 0011 0100 657 is encoded as 658 {1 0 100100} {0 0110100} 660 = 10100100 00110100 662 0x4234 : 0100 0010 0011 0100 664 = 100 0010 0011 0100 666 is encoded as 668 {1 000000 1} {1 0000100} {0 0110100} 670 = 10000001 10000100 00110100 672 0x7F : 0111 1111 674 = 111 1111 676 is encoded as 678 {0 1111111} 680 = 01111111 682 Figure 2: SDNV Example 684 Note: Care must be taken to make sure that the value to be encoded 685 is (in concept) padded with high-order zero bits to make its bitwise 686 length a multiple of 7 before encoding. Also note that, while there 687 is no theoretical limit on the size of an SDNV field, the overhead 688 of the SDNV scheme is 1:7, i.e., one bit of overhead for every 7 689 bits of actual data to be encoded. Thus, a 7-octet value (a 56-bit 690 quantity with no leading zeroes) would be encoded in an 8-octet 691 SDNV; an 8-octet value (a 64-bit quantity with no leading zeroes) 692 would be encoded in a 10-octet SDNV (one octet containing the high- 693 order bit of the value padded with six leading zero bits, followed 694 by nine octets containing the remaining 63 bits of the value). 148 695 bits of overhead would be consumed in encoding a 1024-bit RSA 696 encryption key directly in an SDNV. In general, an N-bit quantity 697 with no leading zeroes is encoded in an SDNV occupying ceil(N/7) 698 octets, where ceil is the integer ceiling function. 700 Implementations of the bundle protocol may handle as an invalid 701 numeric value any SDNV that encodes an integer larger than (2^64 - 702 1). 704 An SDNV can be used to represent both very large and very small 705 integer values. However, SDNV is clearly not the best way to 706 represent every numeric value. For example, an SDNV is a poor way to 707 represent an integer whose value typically falls in the range 128 to 708 255. In general, though, we believe that SDNV representation of 709 numeric values in bundle blocks yields the smallest block sizes 710 without sacrificing scalability. 712 4.2. Bundle Processing Control Flags 714 The bundle processing control flags field in the primary bundle 715 block of each bundle is an SDNV; the value encoded in this SDNV is a 716 string of bits used to invoke selected bundle processing control 717 features. The significance of the value in each currently defined 718 position of this bit string is described here. Note that in the 719 figure and descriptions, the bit label numbers denote position (from 720 least significant ('0') to most significant) within the decoded bit 721 string, and not within the representation of the bits on the wire. 722 This is why the descriptions in this section and the next do not 723 follow standard RFC conventions with bit 0 on the left; if fields 724 are added in the future, the SDNV will grow to the left, and using 725 this representation allows the references here to remain valid. 727 2 1 0 729 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 |Status Report|Class of Svc.|CRC| General | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Figure 3: Bundle Processing Control Flags Bit Layout 739 The bits in positions 0 through 13 of the value of the bundle 740 processing control flags SDNV are flags that characterize the bundle 741 as follows: 743 0 -- Bundle is a fragment. 745 1 -- Payload is an administrative record. 747 2 -- Bundle must not be fragmented. 749 3 -- Custody transfer is requested. 751 4 -- Destination endpoint is a singleton. 753 5 -- Acknowledgement by application is requested. 755 6 -- Bundle is critical. 757 7 -- Best-efforts forwarding is requested. 759 8 -- Reliable forwarding is requested. 761 9-11 -- Reserved for future use. 763 The bits in positions 12 through 13 are used to indicate the type of 764 CRC that is present at the end of the primary block. The options 765 are: 767 0 -- No CRC. 769 1 -- CRC-8. 771 2 -- CRC-16. 773 3 -- CRC-32. 775 The bits in positions 14 through 20 are used to indicate the 776 bundle's class of service. They constitute a seven-bit priority 777 field indicating the bundle's priority, a value from 0 to 127, with 778 higher values being of higher priority (greater urgency). Within 779 this field, bit 20 is the most significant bit. 781 The bits in positions 21 through 27 are status report request flags. 782 These flags are used to request status reports as follows: 784 21 -- Request reporting of bundle reception. 786 22 -- Request reporting of custody acceptance. 788 23 -- Request reporting of bundle forwarding. 790 24 -- Request reporting of bundle delivery. 792 25 -- Request reporting of bundle deletion. 794 26 -- Reserved for future use. 796 27 -- Reserved for future use. 798 If the bundle processing control flags indicate that the bundle's 799 application data unit is an administrative record, then the custody 800 transfer requested flag must be zero and all status report request 801 flags must be zero. If the custody transfer requested flag is 1, 802 then the source node requests that every receiving node accept 803 custody of the bundle. If the bundle's source endpoint is the null 804 endpoint (see below), then the bundle is not uniquely identifiable 805 and all bundle protocol features that rely on bundle identity must 806 therefore be disabled: the bundle's custody transfer requested flag 807 must be zero, the "Bundle must not be fragmented" flag must be 1, 808 and all status report request flags must be zero. 810 4.3. Block Processing Control Flags 812 The block processing control flags field in every block other than 813 the primary bundle block is an SDNV; the value encoded in this SDNV 814 is a string of bits used to invoke selected block processing control 815 features. The significance of the values in all currently defined 816 positions of this bit string, in order from least significant 817 position in the decoded bit string (labeled '0') to most significant 818 (labeled '6'), is described here. 820 0 822 6 5 4 3 2 1 0 824 +-+-+-+-+-+-+-+ 826 | Flags | 828 +-+-+-+-+-+-+-+ 830 Figure 4: Block Processing Control Flags Bit Layout 832 0 - Block must be replicated in every fragment. 834 1 - Transmit status report if block can't be processed. 836 2 - Delete bundle if block can't be processed. 838 3 - Last block. 840 4 - Discard block if it can't be processed. 842 5 - Block was forwarded without being processed. 844 6 - Reserved for future use. 846 For each bundle whose primary block's bundle processing control 847 flags (see above) indicate that the bundle's application data unit 848 is an administrative record, the "Transmit status report if block 849 can't be processed" flag in the block processing flags field of 850 every other block in the bundle must be zero. 852 The 'Block must be replicated in every fragment' bit in the block 853 processing flags must be set to zero on all blocks that follow the 854 payload block. 856 4.4. Identifiers 858 4.4.1. Endpoint ID 860 The destinations of bundles are bundle endpoints, identified by text 861 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 862 (EID) conveyed in any bundle block takes the form of a Uniform 863 Resource Identifier (URI; [URI]). As such, each endpoint ID can be 864 characterized as having this general structure: 866 < scheme name > : < scheme-specific part, or "SSP" > 868 The scheme identified by the < scheme name > in an endpoint ID is a 869 set of syntactic and semantic rules that fully explain how to parse 870 and interpret the SSP. The set of allowable schemes is effectively 871 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 872 protocol endpoint ID. 874 As used for the purposes of the bundle protocol, the length of an 875 SSP must not exceed 1023 bytes. 877 Note that, although endpoint IDs are URIs, implementations of the BP 878 service interface may support expression of endpoint IDs in some 879 internationalized manner (e.g., Internationalized Resource 880 Identifiers (IRIs); see [RFC3987]). 882 The endpoint ID "dtn:none" identifies the "null endpoint", the 883 endpoint that by definition never has any members. 885 Whenever an endpoint ID appears in a bundle block, it is encoded not 886 in its native URI representation but rather in an encoded 887 representation that reduces consumption of transmission bandwidth. 888 The encoded representation of an endpoint ID is as follows: 890 . An SDNV identifying the scheme of the EID (as discussed below), 891 followed by 892 . the encoded representation of the EID's scheme-specific part. 894 The encoded representation of the null endpoint ID is scheme 895 identifier zero, followed by zero octets of scheme-specific part. 897 Every URI scheme used for forming any other EID is classified as 898 either "numeric", meaning that all information conveyed in the 899 scheme-specific part is to be encoded as a sequence of one or more 900 unsigned integers in SDNV representation, or else "non-numeric" 901 (otherwise). The scheme identifier numbers used in the encoded 902 representations of EIDs are assigned as follows: 904 . Scheme identifier zero is reserved for the null endpoint ID. 905 . Scheme identifier numbers in the range 1-63 are used 906 exclusively for numeric EID schemes. 907 . All other scheme identifier numbers are used exclusively for 908 non-numeric EID schemes. 910 Note that scheme of the EID is numeric if and only if the scheme 911 identifier is non-zero and the two high-order bits of the first 912 octet of the scheme identifier are both zero. 914 For each numeric EID scheme, the encoded representation of the EID's 915 scheme-specific part shall be a sequence of from 1 to 100 SDNVs as 916 mandated by the definition of the scheme. 918 For each non-numeric EID scheme, the encoded representation of the 919 EID's scheme-specific part shall comprise: 921 . a single SDNV indicating the length of the remainder of the 922 encoded representation of the scheme-specific part of the EID, 923 followed by 924 . the remainder of the encoded representation of the scheme- 925 specific part of the EID, formed according to the definition of 926 the scheme. If the scheme's definition does not include a 927 specification for encoded representation, then the EID's native 928 scheme-specific part appears here without alteration. 930 It is important to note that not all BP implementations are required 931 to implement the definitions of all EID schemes. The BP 932 implementations used to instantiate nodes in a given network must be 933 chosen with care in order for every node to be able to exchange 934 bundles with every other node. 936 4.4.2. Node ID 938 For many purposes of the Bundle Protocol it is important to identify 939 the node that is operative in some context. 941 As discussed in 3.1 above, nodes are distinct from endpoints; 942 specifically, an endpoint is a set of zero or more nodes. But 943 rather than define a separate namespace for node identifiers, we 944 instead use endpoint identifiers to identify nodes, subject to the 945 following restrictions: 947 . Every node must be a member of at least one singleton endpoint. 948 . The EID of any singleton endpoint of which a node is a member 949 may be used to identify that node. A "node ID" is an EID that 950 is used in this way. 951 . A node's membership in a given singleton endpoint must be 952 sustained at least until the nominal operation of the Bundle 953 Protocol no longer depends on the identification of that node 954 by that endpoint's ID. 956 4.5. Formats of Bundle Blocks 958 This section describes the formats of the primary block and payload 959 block. Rules for processing these blocks appear in Section 5 of this 960 document. 962 Note that supplementary DTN protocol specifications (including, but 963 not restricted to, the Bundle Security Protocol [BSP]) may require 964 that BP implementations conforming to those protocols construct and 965 process additional blocks. 967 The format of these two basic BP blocks is shown in Figure 5 below. 969 Primary Bundle Block 971 +---------+-----------------------+----------------+---------------+ 973 | Version | Block length | Bundle Processing flags (*) | 975 +---------+-----------------------+----------------+---------------+ 977 | Destination EID (*) | Source Node ID (*) | 979 +----------------+----------------+----------------+---------------+ 981 | Report-to EID (*) | Creation timestamp time (*) | 983 +----------------+----------------+----------------+---------------+ 985 | Creation Timestamp sequence number (*) | Lifetime (*) | 987 +----------------+----------------+----------------+---------------+ 988 | Inventory len. | Inventory (*) | [Fragment offset (*)] | 990 +----------------+----------------+----------------+---------------+ 992 | [Total application data unit length (*)] | [CRC (*)] | 994 +----------------+----------------+----------------+---------------+ 996 Bundle Payload Block 998 +----------------+----------------+----------------+---------------+ 1000 | Block type |Block number (*)| Proc. flags (*)| Blk length(*) | 1002 +----------------+----------------+----------------+---------------+ 1004 / Bundle payload (variable) / 1006 +------------------------------------------------------------------+ 1008 Figure 5: Basic Bundle Block Formats 1010 (*) Notes: 1012 The bundle processing control flags field in the Primary Bundle 1013 Block is an SDNV and is therefore of variable length. A two-octet 1014 SDNV is shown here for convenience in representation. 1016 The destination EID, source node ID, and report-to EID in the 1017 Primary Bundle Block are EIDs in encoded representation and are 1018 therefore of variable length. Two-octet fields are shown here for 1019 convenience in representation. 1021 The creation timestamp time in the Primary Bundle Block is an SDNV 1022 and is therefore of variable length. A two-octet SDNV is shown here 1023 for convenience in representation. 1025 The creation timestamp sequence number field in the Primary Bundle 1026 Block is an SDNV and is therefore of variable length. A three-octet 1027 SDNV is shown here for convenience in representation. 1029 The lifetime field in the Primary Bundle Block is an SDNV and is 1030 therefore of variable length. A one-octet SDNV is shown here for 1031 convenience in representation. 1033 The inventory field in the Primary Bundle Block is an array of block 1034 types (one octet each) whose length is given by the value of the 1035 Inventory Length field and is therefore variable. A one-octet 1036 inventory array is shown here for convenience in representation. 1038 The fragment offset field of the Primary Bundle Block is present 1039 only if the Fragment flag in the block's processing flags field is 1040 set to 1. It is an SDNV and is therefore of variable length; a two- 1041 octet SDNV is shown here for convenience in representation. 1043 The total application data unit length field of the Primary Bundle 1044 Block is present only if the Fragment flag in the block's processing 1045 flags field is set to 1. It is an SDNV and is therefore of variable 1046 length; a three-octet SDNV is shown here for convenience in 1047 representation. 1049 The CRC field of the Primary Bundle Block is present only if the CRC 1050 type field in the block's processing flags field is non-zero. Its 1051 actual length depends on the CRC type; a one-octet CRC is shown here 1052 for convenience in representation. 1054 The block processing control flags ("Proc. flags") field of the 1055 Payload Block is an SDNV and is therefore of variable length. A one- 1056 octet SDNV is shown here for convenience in representation. 1058 The block length ("Blk length") field of the Payload Block is an 1059 SDNV and is therefore of variable length. A one-octet SDNV is shown 1060 here for convenience in representation. 1062 4.5.1. Primary Bundle Block 1064 The primary bundle block contains the basic information needed to 1065 forward bundles to their destinations. The fields of the primary 1066 bundle block are: 1068 Version: A 4-bit field indicating the version of the bundle protocol 1069 that constructed this block. The present document describes version 1070 0x07 of the bundle protocol. 1072 Block Length: a 12-bit field that contains the aggregate length (in 1073 bytes) of all remaining fields of the primary block. Note that, 1074 although many fields of the primary bundle block are variable-length 1075 SDNVs, the lengths of all of these SDNVs are in practice limited; 1076 the lengths of the scheme-specific parts of non-numeric EIDs are 1077 likewise limited. These limitations make it reasonable to limit the 1078 total length of the primary block to 4095 octets. 1080 Bundle Processing Control Flags: The Bundle Processing Control Flags 1081 field is an SDNV that contains the bundle processing control flags 1082 discussed in Section 4.2 above. 1084 Destination EID: The Destination EID field contains the encoded 1085 representation of the endpoint ID of the bundle's destination, i.e., 1086 the endpoint containing the node(s) at which the bundle is to be 1087 delivered. 1089 Source node ID: The Source node ID field contains the encoded 1090 representation of an endpoint ID that identifies the node from which 1091 the bundle was initially transmitted, except that it may contain the 1092 null endpoint ID in the event that the bundle's source chooses to 1093 remain anonymous. 1095 Report-to EID: The Report-to EID field contains the encoded 1096 representation of the ID of the endpoint to which status reports 1097 pertaining to the forwarding and delivery of this bundle are to be 1098 transmitted. 1100 Creation Timestamp: The creation timestamp is a pair of SDNVs that, 1101 together with the source node ID and (if the bundle is a fragment) 1102 the fragment offset and payload length, serve to identify the 1103 bundle. The first SDNV of the timestamp is the bundle's creation 1104 time, while the second is the bundle's creation timestamp sequence 1105 number. Bundle creation time is the time -- expressed in seconds 1106 since the start of the year 2000, on the Coordinated Universal Time 1107 (UTC) scale [UTC] -- at which the transmission request was received 1108 that resulted in the creation of the bundle. Sequence count is the 1109 latest value (as of the time at which that transmission request was 1110 received) of a monotonically increasing positive integer counter 1111 managed by the source node's bundle protocol agent that may be reset 1112 to zero whenever the current time advances by one second. For nodes 1113 that lack accurate clocks (that is, nodes that are not at all 1114 moments able to determine the current UTC time to within 30 1115 seconds), bundle creation time MUST be set to zero and the counter 1116 used as the source of the bundle sequence count MUST NEVER be reset 1117 to zero. In either case, a source Bundle Protocol Agent must never 1118 create two distinct bundles with the same source node ID and bundle 1119 creation timestamp. The combination of source node ID and bundle 1120 creation timestamp serves to identify a single transmission request, 1121 enabling it to be acknowledged by the receiving application 1122 (provided the source node ID is not the null endpoint ID). 1124 Lifetime: The lifetime field is an SDNV that indicates the time at 1125 which the bundle's payload will no longer be useful, encoded as a 1126 number of seconds past the creation time. When bundle's age exceeds 1127 its lifetime, bundle nodes need no longer retain or forward the 1128 bundle; the bundle SHOULD be deleted from the network. 1130 Inventory: The Primary block may contain an accounting of all blocks 1131 that were in the bundle at the time it was transmitted from the 1132 source node. This accounting comprises an inventory list length (an 1133 SDNV) followed by an inventory list (an array of N octets, where N 1134 is the value of the inventory list length). This feature is 1135 optional: if the inventory is to be omitted, the inventory length 1136 must be set to zero. Otherwise the values of the octets in the 1137 inventory list must be the block types of all of the non-primary 1138 blocks in the bundle as originally transmitted, exactly one list 1139 element per block. Since a bundle may contain multiple instances of 1140 a given block type, multiple elements of the inventory list may have 1141 the same value. The order of block types appearing in the inventory 1142 list is undefined. 1144 Fragment Offset: If the Bundle Processing Control Flags of this 1145 Primary block indicate that the bundle is a fragment, then the 1146 Fragment Offset field is an SDNV indicating the offset from the 1147 start of the original application data unit at which the bytes 1148 comprising the payload of this bundle were located. If not, then the 1149 Fragment Offset field is omitted from the block. 1151 Total Application Data Unit Length: If the Bundle Processing Control 1152 Flags of this Primary block indicate that the bundle is a fragment, 1153 then the Total Application Data Unit Length field is an SDNV 1154 indicating the total length of the original application data unit of 1155 which this bundle's payload is a part. If not, then the Total 1156 Application Data Unit Length field is omitted from the block. 1158 CRC: If and only if the CRC type in the Bundle Processing Control 1159 Flags of this Primary block is non-zero, a CRC is appended to the 1160 primary block. The length of the CRC is 8 bits, 16 bits, or 32 bits 1161 as indicated by the CRC type. The CRC is computed over the 1162 concatenation of all bytes of the primary block including the CRC 1163 field itself, which for this purpose is temporarily populated with 1164 the value zero. 1166 4.5.2. Canonical Bundle Block Format 1168 Every bundle block of every type other than the primary bundle block 1169 comprises the following fields, in this order: 1171 . Block type code, expressed as an 8-bit unsigned binary integer. 1172 Bundle block type code 1 indicates that the block is a bundle 1173 payload block. Block type codes 2 through 10 are defined as 1174 noted later in this specification. Block type codes 192 1175 through 255 are not defined in this specification and are 1176 available for private and/or experimental use. All other values 1177 of the block type code are reserved for future use. 1178 . Block number, an unsigned integer expressed as an SDNV. The 1179 block number uniquely identifies the block within the bundle, 1180 enabling blocks (notably bundle security protocol blocks) to 1181 explicitly reference other blocks in the same bundle. Block 1182 numbers need not be in continuous sequence, and blocks need not 1183 appear in block number sequence in the bundle. The block number 1184 of the payload block is always zero. 1185 . Block processing control flags, an unsigned integer expressed 1186 as an SDNV. The individual bits of this integer are used to 1187 invoke selected block processing control features. 1188 . Block data length, an unsigned integer expressed as an SDNV. 1189 The Block data length field contains the aggregate length of 1190 all remaining fields of the block, i.e., the block-type- 1191 specific data fields. 1192 . Block-type-specific data fields, whose format and order are 1193 type-specific and whose aggregate length in octets is the value 1194 of the block data length field. All multi-byte block-type- 1195 specific data fields are represented in network byte order. 1197 +----------------+----------------+----------------+---------------+ 1199 | Block type |Block number (*)| Proc. Flags (*)| Blk length(*) | 1201 +----------------+----------------+----------------+---------------+ 1203 / Block body data (variable) / 1205 +------------------------------------------------------------------+ 1207 Figure 6: Block Layout 1209 4.5.3. Bundle Payload Block 1211 The fields of the bundle payload block are: 1213 Block Type: The Block Type field is a 1-byte field that indicates 1214 the type of the block. For the bundle payload block, this field 1215 contains the value 1. 1217 Block Number: The Block Number field is an SDNV that contains the 1218 unique identifying number of the block. The block number of the 1219 bundle payload block is always zero. 1221 Block Processing Control Flags: The Block Processing Control Flags 1222 field is an SDNV that contains the block processing control flags 1223 discussed in Section 4.3 above. 1225 Block Data Length: The Block Data Length field is an SDNV that 1226 contains the aggregate length of all remaining fields of the Payload 1227 block - which is to say, the length of the bundle's payload. 1229 Block-type-specific Data: The Block-type-specific Data field of the 1230 Payload Block contains the "payload", i.e., the application data 1231 carried by this bundle. 1233 That is, bundle payload blocks conform to the canonical format 1234 described in the previous section. 1236 4.6. Extension Blocks 1238 "Extension blocks" are all blocks other than the primary and payload 1239 blocks. Because not all extension blocks are defined in the Bundle 1240 Protocol specification (the present document), not all nodes 1241 conforming to this specification will necessarily instantiate Bundle 1242 Protocol implementations that include procedures for processing 1243 (that is, recognizing, parsing, acting on, and/or producing) all 1244 extension blocks. It is therefore possible for a node to receive a 1245 bundle that includes extension blocks that the node cannot process. 1247 Whenever a bundle is forwarded that contains one or more extension 1248 blocks that could not be processed, the "Block was forwarded without 1249 being processed" flag must be set to 1 within the block processing 1250 flags of each such block. For each block flagged in this way, the 1251 flag may optionally be cleared (i.e., set to zero) by another node 1252 that subsequently receives the bundle and is able to process that 1253 block; the specifications defining the various extension blocks are 1254 expected to define the circumstances under which this flag may be 1255 cleared, if any. 1257 The extension blocks of the Bundle Security Protocol (block types 2, 1258 3, and 4) are defined separately in the Bundle Security Protocol 1259 specification (work in progress). 1261 The following extension blocks are defined in the current document. 1263 4.6.1. Current Custodian 1265 The Current Custodian block, block type 5, identifies a node that is 1266 known to have accepted custody of the bundle. The block-type- 1267 specific data of this block is the encoded representation of the 1268 node ID of a custodian. The bundle MAY contain one or more 1269 occurrences of this type of block. 1271 4.6.2. Flow Label 1273 The Flow Label block, block type 6, indicates the flow label that is 1274 intended to govern transmission of the bundle by convergence-layer 1275 adapters. The syntax and semantics of BP flow labels are beyond the 1276 scope of this document. 1278 4.6.3. Previous Node ID 1280 The Previous Node ID block, block type 7, identifies the node that 1281 forwarded this bundle to the local node; its block-type-specific 1282 data is the encoded representation of the node ID of that node. If 1283 the local node is the source of the bundle, then the bundle MUST NOT 1284 contain any Previous Node ID block. Otherwise the bundle MUST 1285 contain one (1) occurrence of this type of block. If present, the 1286 Previous Node ID block MUST be the FIRST block following the primary 1287 block, as the processing of other extension blocks may depend on its 1288 value. 1290 4.6.4. Bundle Age 1292 The Bundle Age block, block type 9, contains the number of seconds 1293 that have elapsed between the time the bundle was created and time 1294 at which it was most recently forwarded. It is intended for use by 1295 nodes lacking access to an accurate clock, to aid in determining the 1296 time at which a bundle's lifetime expires. The block-type-specific 1297 data of this block is an SDNV containing the age of the bundle (the 1298 sum of all known intervals of the bundle's residence at forwarding 1299 nodes, up to the time at which the bundle was most recently 1300 forwarded) in seconds. If the bundle's creation time is zero, then 1301 the bundle MUST contain exactly one (1) occurrence of this type of 1302 block; otherwise, the bundle MAY contain at most one (1) occurrence 1303 of this type of block. 1305 4.6.5. Hop Count 1307 The Hop Count block, block type 10, contains two SDNVs, hop limit 1308 and hop count, in that order. It is mainly intended as a safety 1309 mechanism, a means of identifying bundles for removal from the 1310 network that can never be delivered due to a persistent forwarding 1311 error: a bundle may be deleted when its hop count exceeds its hop 1312 limit. Procedures for determining the appropriate hop limit for a 1313 block are beyond the scope of this specification. A bundle MAY 1314 contain at most one (1) occurrence of this type of block. 1316 5. Bundle Processing 1318 The bundle processing procedures mandated in this section and in 1319 Section 6 govern the operation of the Bundle Protocol Agent and the 1320 Application Agent administrative element of each bundle node. They 1321 are neither exhaustive nor exclusive. That is, supplementary DTN 1322 protocol specifications (including, but not restricted to, the 1323 Bundle Security Protocol [BSP]) may require that additional measures 1324 be taken at specified junctures in these procedures. Such additional 1325 measures shall not override or supersede the mandated bundle 1326 protocol procedures, except that they may in some cases make these 1327 procedures moot by requiring, for example, that implementations 1328 conforming to the supplementary protocol terminate the processing of 1329 a given incoming or outgoing bundle due to a fault condition 1330 recognized by that protocol. 1332 5.1. Generation of Administrative Records 1334 All transmission of bundles is in response to bundle transmission 1335 requests presented by nodes' application agents. When required to 1336 "generate" an administrative record (such as a bundle status report 1337 or a custody signal), the bundle protocol agent itself is 1338 responsible for causing a new bundle to be transmitted, conveying 1339 that record. In concept, the bundle protocol agent discharges this 1340 responsibility by directing the administrative element of the node's 1341 application agent to construct the record and request its 1342 transmission as detailed in Section 6 below. In practice, the manner 1343 in which administrative record generation is accomplished is an 1344 implementation matter, provided the constraints noted in Section 6 1345 are observed. 1347 Under some circumstances, the requesting of status reports could 1348 result in an unacceptable increase in the bundle traffic in the 1349 network. For this reason, the generation of status reports is 1350 mandatory only in one case, the deletion of a bundle for which 1351 custody transfer is requested. In all other cases, the decision on 1352 whether or not to generate a requested status report is left to the 1353 discretion of the bundle protocol agent. Mechanisms that could 1354 assist in making such decisions, such as pre-placed agreements 1355 authorizing the generation of status reports under specified 1356 circumstances, are beyond the scope of this specification. 1358 Notes on administrative record terminology: 1360 . A "bundle reception status report" is a bundle status report 1361 with the "reporting node received bundle" flag set to 1. 1363 . A "custody acceptance status report" is a bundle status report 1364 with the "reporting node accepted custody of bundle" flag set 1365 to 1. 1366 . A "bundle forwarding status report" is a bundle status report 1367 with the "reporting node forwarded the bundle" flag set to 1. 1368 . A "bundle delivery status report" is a bundle status report 1369 with the "reporting node delivered the bundle" flag set to 1. 1370 . A "bundle deletion status report" is a bundle status report 1371 with the "reporting node deleted the bundle" flag set to 1. 1372 . A "Succeeded" custody signal is a custody signal with the 1373 "custody transfer succeeded" flag set to 1. 1374 . A "Failed" custody signal is a custody signal with the "custody 1375 transfer succeeded" flag set to zero. 1376 . A "current custodian" of a bundle is a node identified in a 1377 Current Custodian extension block of that bundle. 1379 5.2. Bundle Transmission 1381 The steps in processing a bundle transmission request are: 1383 Step 1: If custody transfer is requested for this bundle 1384 transmission then the destination must be a singleton endpoint. If, 1385 moreover, custody acceptance by the source node is required but the 1386 conditions under which custody of the bundle may be accepted are not 1387 satisfied, then the request cannot be honored and all remaining 1388 steps of this procedure must be skipped. 1390 Step 2: Transmission of the bundle is initiated. An outbound bundle 1391 must be created per the parameters of the bundle transmission 1392 request, with the retention constraint "Dispatch pending". The 1393 source node ID of the bundle must be either the EID of a singleton 1394 endpoint whose only member is the node of which the BPA is a 1395 component or else the null endpoint ID, indicating that the source 1396 of the bundle is anonymous. 1398 Step 3: Processing proceeds from Step 1 of Section 5.4. 1400 5.3. Bundle Dispatching 1402 The steps in dispatching a bundle are: 1404 Step 1: If the bundle's destination endpoint is an endpoint of which 1405 the node is a member, the bundle delivery procedure defined in 1406 Section 5.7 must be followed. 1408 Step 2: Processing proceeds from Step 1 of Section 5.4. 1410 5.4. Bundle Forwarding 1412 The steps in forwarding a bundle are: 1414 Step 1: The retention constraint "Forward pending" must be added to 1415 the bundle, and the bundle's "Dispatch pending" retention constraint 1416 must be removed. 1418 Step 2: The bundle protocol agent must determine whether or not 1419 forwarding is contraindicated for any of the reasons listed in 1420 Figure 12. In particular: 1422 . The bundle protocol agent must determine which node(s) to 1423 forward the bundle to. The bundle protocol agent may choose 1424 either to forward the bundle directly to its destination 1425 node(s) (if possible) or to forward the bundle to some other 1426 node(s) for further forwarding. The manner in which this 1427 decision is made may depend on the scheme name in the 1428 destination endpoint ID and/or other state but in any case is 1429 beyond the scope of this document. If the BPA elects to forward 1430 the bundle to some other node(s) for further forwarding: 1431 o If the "Bundle is critical" flag (in the bundle processing 1432 flags) is set to 1, then ALL nodes that have some 1433 plausible prospect of forwarding the bundle to its 1434 destination node(s) SHOULD be selected for this purpose. 1435 o If the agent finds it impossible to select any node(s) to 1436 forward the bundle to, then forwarding is contraindicated. 1437 . Provided the bundle protocol agent succeeded in selecting the 1438 node(s) to forward the bundle to, the bundle protocol agent 1439 must select the convergence layer adapter(s) whose services 1440 will enable the node to send the bundle to those nodes. If 1441 both the "Best-efforts forwarding requested" and the "Reliable 1442 forwarding is requested" bundle processing flags are set to 1, 1443 then all selected CLAs MUST be for bundle streaming CL 1444 protocols such as the proposed Bundle Streaming Service 1445 Protocol. Otherwise, if only the "Reliable forwarding is 1446 requested" bundle processing flag is set to 1, then all 1447 selected CLAs MUST be for reliable protocols such as TCP/IP. 1448 Otherwise, if only the "Best-efforts forwarding requested" 1449 bundle processing flag is set to 1, then all selected CLAs MUST 1450 be for best-efforts protocols such as UDP/IP. Otherwise, any 1451 available CLAs may be selected. The manner in which specific 1452 appropriate convergence layer adapters are selected is beyond 1453 the scope of this document. If the agent finds it impossible to 1454 select appropriate convergence layer adapters to use in 1455 forwarding this bundle, then forwarding is contraindicated. 1457 Step 3: If forwarding of the bundle is determined to be 1458 contraindicated for any of the reasons listed in Figure 12, then the 1459 Forwarding Contraindicated procedure defined in Section 5.4.1 must 1460 be followed; the remaining steps of Section 5 are skipped at this 1461 time. 1463 Step 4: If the bundle's custody transfer requested flag (in the 1464 bundle processing flags field) is set to 1, then the custody 1465 transfer procedure defined in Section 5.10.2 must be followed. 1467 Step 5: For each node selected for forwarding, the bundle protocol 1468 agent must invoke the services of the selected convergence layer 1469 adapter(s) in order to effect the sending of the bundle to that 1470 node. Determining the time at which the bundle is to be sent by each 1471 convergence layer adapter is an implementation matter. Note that: 1473 . The order in which convergence layer adapters send bundles 1474 SHOULD normally conform to the priority indicated in each 1475 bundle's bundle processing control flags field: all bundles of 1476 priority 255 sent from any single source should be sent before 1477 all bundles of priority 254 sent from the same source and so 1478 on. 1479 . But if the bundle contains a flow label extension block then 1480 that flow label value may identify overriding procedures for 1481 determining the order in which convergence layer adapters must 1482 send bundles, e.g., considering bundle source when determining 1483 the order in which bundles are sent. The definition of such 1484 procedures is beyond the scope of this specification. 1485 . If the bundle has a bundle age block, then at the last possible 1486 moment before the CLA initiates conveyance of the bundle node 1487 via the CL protocol the bundle age value MUST be increased by 1488 the difference between the current time and the time at which 1489 the bundle was received (or, if the local node is the source of 1490 the bundle, created). 1492 Step 6: When all selected convergence layer adapters have informed 1493 the bundle protocol agent that they have concluded their data 1494 sending procedures with regard to this bundle: 1496 . If the "request reporting of bundle forwarding" flag in the 1497 bundle's status report request field is set to 1, then a bundle 1498 forwarding status report should be generated, destined for the 1499 bundle's report-to endpoint ID. If the bundle has the retention 1500 constraint "custody accepted" and all of the nodes to which the 1501 bundle was forwarded are known to be unable to send bundles 1502 back to this node, then the reason code on this bundle 1503 forwarding status report must be "forwarded over unidirectional 1504 link"; otherwise, the reason code must be "no additional 1505 information". 1506 . The bundle's "Forward pending" retention constraint must be 1507 removed. 1509 5.4.1. Forwarding Contraindicated 1511 The steps in responding to contraindication of forwarding for some 1512 reason are: 1514 Step 1: The bundle protocol agent must determine whether or not to 1515 declare failure in forwarding the bundle for this reason. Note: this 1516 decision is likely to be influenced by the reason for which 1517 forwarding is contraindicated. 1519 Step 2: If forwarding failure is declared, then the Forwarding 1520 Failed procedure defined in Section 5.4.2 MUST be followed. 1522 Otherwise, (a) if the bundle's custody transfer requested flag (in 1523 the bundle processing flags field) is set to 1, then the custody 1524 transfer procedure defined in Section 5.10 MUST be followed; (b) 1525 when -- at some future time - the forwarding of this bundle ceases 1526 to be contraindicated, processing proceeds from Step 5 of Section 1527 5.4. 1529 5.4.2. Forwarding Failed 1531 The steps in responding to a declaration of forwarding failure for 1532 some reason are: 1534 Step 1: If the bundle's custody transfer requested flag (in the 1535 bundle processing flags field) is set to 1, custody transfer failure 1536 must be handled. The bundle protocol agent MUST handle the custody 1537 transfer failure by generating a "Failed" custody signal for the 1538 bundle, destined for the bundle's current custodian(s); the custody 1539 signal must contain a reason code corresponding to the reason for 1540 which forwarding was determined to be contraindicated. (Note that 1541 discarding the bundle will not delete it from the network, since 1542 each current custodian still has a copy.) 1544 If the bundle's custody transfer requested flag (in the bundle 1545 processing flags field) is set to 0, then the bundle protocol agent 1546 MAY forward the bundle back to the node that sent it, as identified 1547 by the Previous Node ID block. 1549 Step 2: If the bundle's destination endpoint is an endpoint of which 1550 the node is a member, then the bundle's "Forward pending" retention 1551 constraint must be removed. Otherwise, the bundle must be deleted: 1552 the bundle deletion procedure defined in Section 5.13 must be 1553 followed, citing the reason for which forwarding was determined to 1554 be contraindicated. 1556 5.5. Bundle Expiration 1558 A bundle expires when the bundle's age exceeds its lifetime as 1559 specified in the primary bundle block. Bundle age MAY be determined 1560 by subtracting the bundle's creation timestamp time from the current 1561 time if (a) that timestamp time is not zero and (b) the local node's 1562 clock is known to be accurate (as discussed in section 4.5.1 above); 1563 otherwise bundle age MUST be obtained from the Bundle Age extension 1564 block. Bundle expiration MAY occur at any point in the processing 1565 of a bundle. When a bundle expires, the bundle protocol agent MUST 1566 delete the bundle for the reason "lifetime expired": the bundle 1567 deletion procedure defined in Section 5.13 MUST be followed. 1569 5.6. Bundle Reception 1571 The steps in processing a bundle received from another node are: 1573 Step 1: The retention constraint "Dispatch pending" must be added to 1574 the bundle. 1576 Step 2: If the "request reporting of bundle reception" flag in the 1577 bundle's status report request field is set to 1, then a bundle 1578 reception status report with reason code "No additional information" 1579 should be generated, destined for the bundle's report-to endpoint 1580 ID. 1582 Step 3: For each block in the bundle that is an extension block that 1583 the bundle protocol agent cannot process: 1585 . If the block processing flags in that block indicate that a 1586 status report is requested in this event, then a bundle 1587 reception status report with reason code "Block unintelligible" 1588 should be generated, destined for the bundle's report-to 1589 endpoint ID. 1590 . If the block processing flags in that block indicate that the 1591 bundle must be deleted in this event, then the bundle protocol 1592 agent must delete the bundle for the reason "Block 1593 unintelligible"; the bundle deletion procedure defined in 1594 Section 5.13 must be followed and all remaining steps of the 1595 bundle reception procedure must be skipped. 1596 . If the block processing flags in that block do NOT indicate 1597 that the bundle must be deleted in this event but do indicate 1598 that the block must be discarded, then the bundle protocol 1599 agent must remove this block from the bundle. 1600 . If the block processing flags in that block indicate NEITHER 1601 that the bundle must be deleted NOR that the block must be 1602 discarded, then the bundle protocol agent must set to 1 the 1603 "Block was forwarded without being processed" flag in the block 1604 processing flags of the block. 1606 Step 4: If the bundle's custody transfer requested flag (in the 1607 bundle processing flags field) is set to 1 and the bundle has the 1608 same source node ID, creation timestamp, and (if the bundle is a 1609 fragment) fragment offset and payload length as another bundle that 1610 (a) has not been discarded and (b) currently has the retention 1611 constraint "Custody accepted", custody transfer redundancy must be 1612 handled. Otherwise, processing proceeds from Step 5. The bundle 1613 protocol agent must handle custody transfer redundancy by generating 1614 a "Failed" custody signal for this bundle with reason code 1615 "Redundant reception", destined for this bundle's current custodian, 1616 and removing this bundle's "Dispatch pending" retention constraint. 1618 Step 5: Processing proceeds from Step 1 of Section 5.3. 1620 5.7. Local Bundle Delivery 1622 The steps in processing a bundle that is destined for an endpoint of 1623 which this node is a member are: 1625 Step 1: If the received bundle is a fragment, the application data 1626 unit reassembly procedure described in Section 5.9 must be followed. 1627 If this procedure results in reassembly of the entire original 1628 application data unit, processing of this bundle (whose fragmentary 1629 payload has been replaced by the reassembled application data unit) 1630 proceeds from Step 2; otherwise, the retention constraint 1631 "Reassembly pending" must be added to the bundle and all remaining 1632 steps of this procedure must be skipped. 1634 Step 2: Delivery depends on the state of the registration whose 1635 endpoint ID matches that of the destination of the bundle: 1637 . If the registration is in the Active state, then the bundle 1638 must be delivered subject to this registration (see Section 3.1 1639 above) as soon as all previously received bundles that are 1640 deliverable subject to this registration have been delivered. 1641 . If the registration is in the Passive state, then the 1642 registration's delivery failure action must be taken (see 1643 Section 3.1 above). 1645 Step 3: As soon as the bundle has been delivered: 1647 . If the "request reporting of bundle delivery" flag in the 1648 bundle's status report request field is set to 1, then a bundle 1649 delivery status report should be generated, destined for the 1650 bundle's report-to endpoint ID. Note that this status report 1651 only states that the payload has been delivered to the 1652 application agent, not that the application agent has processed 1653 that payload. 1654 . If the bundle's custody transfer requested flag (in the bundle 1655 processing flags field) is set to 1, custodial delivery must be 1656 reported. The bundle protocol agent must report custodial 1657 delivery by generating a "Succeeded" custody signal for the 1658 bundle, destined for the bundle's current custodian(s). 1660 5.8. Bundle Fragmentation 1662 It may at times be advantageous for bundle protocol agents to reduce 1663 the sizes of bundles in order to forward them. This might be the 1664 case, for example, if a node to which a bundle is to be forwarded is 1665 accessible only via intermittent contacts and no upcoming contact is 1666 long enough to enable the forwarding of the entire bundle. 1668 The size of a bundle can be reduced by "fragmenting" the bundle. To 1669 fragment a bundle whose payload is of size M is to replace it with 1670 two "fragments" -- new bundles with the same source node ID and 1671 creation timestamp as the original bundle -- whose payloads are the 1672 first N and the last (M - N) bytes of the original bundle's payload, 1673 where 0 < N < M. Note that fragments may themselves be fragmented, 1674 so fragmentation may in effect replace the original bundle with more 1675 than two fragments. (However, there is only one 'level' of 1676 fragmentation, as in IP fragmentation.) 1678 Any bundle that has any Current Custodian extension block citing any 1679 node other than the local node MUST NOT be fragmented. This 1680 restriction aside, any bundle whose primary block's bundle 1681 processing flags do NOT indicate that it must not be fragmented may 1682 be fragmented at any time, for any purpose, at the discretion of the 1683 bundle protocol agent. 1685 Fragmentation shall be constrained as follows: 1687 . The concatenation of the payloads of all fragments produced by 1688 fragmentation must always be identical to the payload of the 1689 bundle that was fragmented. Note that the payloads of fragments 1690 resulting from different fragmentation episodes, in different 1691 parts of the network, may be overlapping subsets of the 1692 original bundle's payload. 1693 . The bundle processing flags in the primary block of each 1694 fragment must differ from those of the bundle that is being 1695 fragmented, in that they must indicate that the bundle is a 1696 fragment, and both fragment offset and total application data 1697 unit length must be provided at the end of each fragment's 1698 primary bundle block. Additionally, the CRC of the bundle that 1699 is being fragmented, if any, must be replaced in each fragment 1700 by a new CRC computed for the primary block of that fragment. 1701 . The primary blocks of the fragments will differ from that of 1702 the fragmented bundle as noted above. 1703 . The payload blocks of fragments will differ from that of the 1704 fragmented bundle as noted above. 1705 . If the bundle being fragmented is not a fragment or is the 1706 fragment with offset zero, then all extension blocks of the 1707 bundle being fragmented MUST be replicated in the fragment 1708 whose offset is zero. 1709 . Each extension block whose "Block must be replicated in every 1710 fragment" flag, in the block processing flags, is set to 1 MUST 1711 be replicated in every fragment. 1712 . Beyond these rules, replication of extension blocks in the 1713 fragments is an implementation matter. 1714 . If the local node had taken custody of the fragmented bundle, 1715 then the BPA MUST release custody of the fragmented bundle 1716 before fragmentation occurs and MUST take custody of every 1717 fragment. 1719 5.9. Application Data Unit Reassembly 1721 If the concatenation -- as informed by fragment offsets and payload 1722 lengths -- of the payloads of all previously received fragments with 1723 the same source node ID and creation timestamp as this fragment, 1724 together with the payload of this fragment, forms a byte array whose 1725 length is equal to the total application data unit length in the 1726 fragment's primary block, then: 1728 . This byte array -- the reassembled application data unit -- 1729 must replace the payload of this fragment. 1730 . For each fragmentary bundle whose payload is a subset of the 1731 reassembled application data unit, for which custody transfer 1732 is requested but the BPA has not yet taken custody, the BPA 1733 must take custody of that bundle. 1734 . The BPA must then release custody of all fragments whose 1735 payload is a subset of the reassembled application data unit, 1736 for which it has taken custody. 1738 . The "Reassembly pending" retention constraint must be removed 1739 from every other fragment whose payload is a subset of the 1740 reassembled application data unit. 1742 Note: reassembly of application data units from fragments occurs at 1743 the nodes that are members of destination endpoints as necessary; an 1744 application data unit may also be reassembled at some other node on 1745 the path to the destination. 1747 5.10. Custody Transfer 1749 The decision as to whether or not to accept custody of a bundle is 1750 an implementation matter that may involve both resource and policy 1751 considerations. 1753 If the bundle protocol agent elects to accept custody of the bundle, 1754 then it must follow the custody acceptance procedure defined in 1755 Section 5.10.1. 1757 5.10.1. Custody Acceptance 1759 Procedures for acceptance of custody of a bundle are defined as 1760 follows. 1762 The retention constraint "Custody accepted" must be added to the 1763 bundle. 1765 If the "request reporting of custody acceptance" flag in the 1766 bundle's status report request field is set to 1, a custody 1767 acceptance status report should be generated, destined for the 1768 report-to endpoint ID of the bundle. However, if a bundle reception 1769 status report was generated for this bundle (Step 1 of Section 5.6), 1770 then this report SHOULD be generated by simply turning on the 1771 "Reporting node accepted custody of bundle" flag in that earlier 1772 report's status flags byte. 1774 The bundle protocol agent must generate a "Succeeded" custody signal 1775 for the bundle, destined for the bundle's current custodian(s). 1777 The bundle protocol agent must assert the new current custodian for 1778 the bundle. It does so by inserting a new Current Custodian 1779 extension block whose value is the node ID of the local node or by 1780 changing the value of an existing Current Custodian extension block 1781 to the local node ID. 1783 The bundle protocol agent may set a custody transfer countdown timer 1784 for this bundle; upon expiration of this timer prior to expiration 1785 of the bundle itself and prior to custody transfer success for this 1786 bundle, the custody transfer failure procedure detailed in Section 1787 5.12 may be followed. The manner in which the countdown interval for 1788 such a timer is determined is an implementation matter. 1790 The bundle should be retained in persistent storage if possible. 1792 5.10.2. Custody Release 1794 When custody of a bundle is released, the "Custody accepted" 1795 retention constraint must be removed from the bundle and any custody 1796 transfer timer that has been established for this bundle should be 1797 destroyed. 1799 5.11. Custody Transfer Success 1801 Upon receipt of a "Succeeded" custody signal at a node that is a 1802 custodial node of the bundle identified in the custody signal, 1803 custody of the bundle must be released as described in Section 1804 5.10.2. 1806 5.12. Custody Transfer Failure 1808 Custody transfer is determined to have failed at a custodial node 1809 for that bundle when either (a) that node's custody transfer timer 1810 for that bundle (if any) expires or (b) a "Failed" custody signal 1811 for that bundle is received at that node. 1813 Upon determination of custody transfer failure, the action taken by 1814 the bundle protocol agent is implementation-specific and may depend 1815 on the nature of the failure. For example, if custody transfer 1816 failure was inferred from expiration of a custody transfer timer or 1817 was asserted by a "Failed" custody signal with the "Depleted 1818 storage" reason code, the bundle protocol agent might choose to re- 1819 forward the bundle, possibly on a different route (Section 5.4). 1820 Receipt of a "Failed" custody signal with the "Redundant reception" 1821 reason code, on the other hand, might cause the bundle protocol 1822 agent to release custody of the bundle and to revise its algorithm 1823 for computing countdown intervals for custody transfer timers. 1825 5.13. Bundle Deletion 1827 The steps in deleting a bundle are: 1829 Step 1: If the retention constraint "Custody accepted" currently 1830 prevents this bundle from being discarded, then: 1832 . Custody of the node is released as described in Section 5.10.2. 1833 . A bundle deletion status report citing the reason for deletion 1834 must be generated, destined for the bundle's report-to endpoint 1835 ID. 1837 Otherwise, if the "request reporting of bundle deletion" flag in the 1838 bundle's status report request field is set to 1, then a bundle 1839 deletion status report citing the reason for deletion should be 1840 generated, destined for the bundle's report-to endpoint ID. 1842 Step 2: All of the bundle's retention constraints must be removed. 1844 5.14. Discarding a Bundle 1846 As soon as a bundle has no remaining retention constraints it may be 1847 discarded. 1849 5.15. Canceling a Transmission 1851 When requested to cancel a specified transmission, where the bundle 1852 created upon initiation of the indicated transmission has not yet 1853 been discarded, the bundle protocol agent must delete that bundle 1854 for the reason "transmission cancelled". For this purpose, the 1855 procedure defined in Section 5.13 must be followed. 1857 6. Administrative Record Processing 1859 6.1. Administrative Records 1861 Administrative records are standard application data units that are 1862 used in providing some of the features of the Bundle Protocol. Two 1863 types of administrative records have been defined to date: bundle 1864 status reports and custody signals. Note that additional types of 1865 administrative records may be defined by supplementary DTN protocol 1866 specification documents. 1868 Every administrative record consists of a five-bit record type code 1869 followed by three bits of administrative record flags, followed by 1870 record content in type-specific format. Record type codes are 1871 defined as follows: 1873 +---------+--------------------------------------------+ 1875 | Value | Meaning | 1877 +=========+============================================+ 1878 | 00001 | Bundle status report. | 1880 +---------+--------------------------------------------+ 1882 | 00010 | Custody signal. | 1884 +---------+--------------------------------------------+ 1886 | (other) | Reserved for future use. | 1888 +---------+--------------------------------------------+ 1890 Figure 8: Administrative Record Type Codes 1892 +---------+--------------------------------------------+ 1894 | Value | Meaning | 1896 +=========+============================================+ 1898 | 0001 | Record is for a fragment; fragment | 1900 | | offset and length fields are present. | 1902 +---------+--------------------------------------------+ 1904 | (other) | Reserved for future use. | 1906 +---------+--------------------------------------------+ 1908 Figure 9: Administrative Record Flags 1910 The contents of the two types of administrative records defined in 1911 the present document are described below. 1913 6.1.1. Bundle Status Reports 1915 The transmission of 'bundle status reports' under specified 1916 conditions is an option that can be invoked when transmission of a 1917 bundle is requested. These reports are intended to provide 1918 information about how bundles are progressing through the system, 1919 including notices of receipt, custody transfer, forwarding, final 1920 delivery, and deletion. They are transmitted to the Report-to 1921 endpoints of bundles. 1923 +----------------+----------------+----------------+---------------+ 1924 | Status Flags | Reason code | Fragment offset (*) (if 1926 +----------------+----------------+----------------+---------------+ 1928 present) | Fragment length (*) (if present) | 1930 +----------------+----------------+----------------+---------------+ 1932 | Source node ID of bundle X (*) | 1934 +----------------+----------------+----------------+---------------+ 1936 | Copy of bundle X's Creation Timestamp time (*) | 1938 +----------------+----------------+----------------+---------------+ 1940 | Copy of bundle X's Creation Timestamp sequence number (*) | 1942 +----------------+----------------+----------------+---------------+ 1944 Figure 10: Bundle Status Report Format 1946 (*) Notes: 1948 The Fragment Offset field, if present, is an SDNV and is therefore 1949 variable length. A three-octet SDNV is shown here for convenience in 1950 representation. 1952 The Fragment Length field, if present, is an SDNV and is therefore 1953 variable length. A three-octet SDNV is shown here for convenience in 1954 representation. 1956 The Source Node ID and Creation Timestamp fields replicate the 1957 Source Node ID and Creation Timestamp fields in the primary block of 1958 the subject bundle. As such they are of variable length. Four-octet 1959 values are shown here for convenience in representation. 1961 The fields in a bundle status report are: 1963 Status Flags: A 1-byte field containing the following flags: 1965 +----------+--------------------------------------------+ 1967 | Value | Meaning | 1969 +==========+============================================+ 1970 | 00000001 | Reporting node received bundle. | 1972 +----------+--------------------------------------------+ 1974 | 00000010 | Reporting node accepted custody of bundle. | 1976 +----------+--------------------------------------------+ 1978 | 00000100 | Reporting node forwarded the bundle. | 1980 +----------+--------------------------------------------+ 1982 | 00001000 | Reporting node delivered the bundle. | 1984 +----------+--------------------------------------------+ 1986 | 00010000 | Reporting node deleted the bundle. | 1988 +----------+--------------------------------------------+ 1990 | 00100000 | Unused. | 1992 +----------+--------------------------------------------+ 1994 | 01000000 | Unused. | 1996 +----------+--------------------------------------------+ 1998 | 10000000 | Unused. | 2000 +----------+--------------------------------------------+ 2002 Figure 11: Status Flags for Bundle Status Reports 2004 Reason Code: A 1-byte field explaining the value of the flags in the 2005 status flags byte. The list of status report reason codes provided 2006 here is neither exhaustive nor exclusive; supplementary DTN protocol 2007 specifications (including, but not restricted to, the Bundle 2008 Security Protocol [BSP]) may define additional reason codes. Status 2009 report reason codes are defined as follows: 2011 +---------+--------------------------------------------+ 2013 | Value | Meaning | 2015 +=========+============================================+ 2016 | 0x00 | No additional information. | 2018 +---------+--------------------------------------------+ 2020 | 0x01 | Lifetime expired. | 2022 +---------+--------------------------------------------+ 2024 | 0x02 | Forwarded over unidirectional link. | 2026 +---------+--------------------------------------------+ 2028 | 0x03 | Transmission canceled. | 2030 +---------+--------------------------------------------+ 2032 | 0x04 | Depleted storage. | 2034 +---------+--------------------------------------------+ 2036 | 0x05 | Destination endpoint ID unintelligible. | 2038 +---------+--------------------------------------------+ 2040 | 0x06 | No known route to destination from here. | 2042 +---------+--------------------------------------------+ 2044 | 0x07 | No timely contact with next node on route. | 2046 +---------+--------------------------------------------+ 2048 | 0x08 | Block unintelligible. | 2050 +---------+--------------------------------------------+ 2052 | (other) | Reserved for future use. | 2054 +---------+--------------------------------------------+ 2056 Figure 12: Status Report Reason Codes 2058 Fragment Offset: If the bundle fragment bit is set in the status 2059 flags, then the offset (within the original application data unit) 2060 of the payload of the bundle that caused the status report to be 2061 generated is included here. 2063 Fragment length: If the bundle fragment bit is set in the status 2064 flags, then the length of the payload of the subject bundle is 2065 included here. 2067 Source Node ID of Subject Bundle: The source node ID of the bundle 2068 that caused the status report to be generated. 2070 Creation Timestamp of Subject Bundle: A copy of the creation 2071 timestamp of the bundle that caused the status report to be 2072 generated. 2074 6.1.2. Custody Signals 2076 Custody signals are administrative records that effect custody 2077 transfer operations. They are transmitted to the nodes that are the 2078 current custodians of bundles. 2080 Custody signals have the following format. 2082 Custody signal regarding bundle 'X': 2084 +----------------+----------------+----------------+---------------+ 2086 | Status | Fragment offset (*) (if present) | 2088 +----------------+----------------+----------------+---------------+ 2090 | Fragment length (*) (if present) | 2092 +----------------+----------------+----------------+---------------+ 2094 | Source node ID of bundle X (*) | 2096 +----------------+----------------+----------------+---------------+ 2098 | Copy of bundle X's Creation Timestamp time (*) | 2100 +----------------+----------------+----------------+---------------+ 2102 | Copy of bundle X's Creation Timestamp sequence number (*) | 2104 +----------------+----------------+----------------+---------------+ 2106 Figure 13: Custody Signal Format 2108 (*) Notes: 2110 The Fragment Offset field, if present, is an SDNV and is therefore 2111 variable length. A three-octet SDNV is shown here for convenience in 2112 representation. 2114 The Fragment Length field, if present, is an SDNV and is therefore 2115 variable length. A four-octet SDNV is shown here for convenience in 2116 representation. 2118 The Source Node ID and Creation Timestamp fields replicate the 2119 Source Node ID and Creation Timestamp fields in the primary block of 2120 the subject bundle. As such they are of variable length. Four-octet 2121 values are shown here for convenience in representation. 2123 The fields in a custody signal are: 2125 Status: A 1-byte field containing a 1-bit "custody transfer 2126 succeeded" flag followed by a 7-bit reason code explaining the value 2127 of that flag. Custody signal reason codes are defined as follows: 2129 +---------+--------------------------------------------+ 2131 | Value | Meaning | 2133 +=========+============================================+ 2135 | 0x00 | No additional information. | 2137 +---------+--------------------------------------------+ 2139 | 0x01 | Reserved for future use. | 2141 +---------+--------------------------------------------+ 2143 | 0x02 | Reserved for future use. | 2145 +---------+--------------------------------------------+ 2147 | 0x03 | Redundant (reception by a node that is a | 2149 | | custodial node for this bundle). | 2151 +---------+--------------------------------------------+ 2153 | 0x04 | Depleted storage. | 2155 +---------+--------------------------------------------+ 2156 | 0x05 | Destination endpoint ID unintelligible. | 2158 +---------+--------------------------------------------+ 2160 | 0x06 | No known route destination from here. | 2162 +---------+--------------------------------------------+ 2164 | 0x07 | No timely contact with next node on route. | 2166 +---------+--------------------------------------------+ 2168 | 0x08 | Block unintelligible. | 2170 +---------+--------------------------------------------+ 2172 | (other) | Reserved for future use. | 2174 +---------+--------------------------------------------+ 2176 Figure 14: Custody Signal Reason Codes 2178 Fragment offset: If the bundle fragment bit is set in the status 2179 flags, then the offset (within the original application data unit) 2180 of the payload of the bundle that caused the custody signal to be 2181 generated is included here. 2183 Fragment length: If the bundle fragment bit is set in the status 2184 flags, then the length of the payload of the subject bundle is 2185 included here. 2187 Source Node ID of Subject Bundle: The source node ID of the bundle 2188 that caused the custody signal to be generated. 2190 Creation Timestamp of Subject Bundle: A copy of the creation 2191 timestamp of the bundle to which the signal applies. 2193 6.2. Generation of Administrative Records 2195 Whenever the application agent's administrative element is directed 2196 by the bundle protocol agent to generate an administrative record 2197 with reference to some bundle, the following procedure must be 2198 followed: 2200 Step 1: The administrative record must be constructed. If the 2201 referenced bundle is a fragment, the administrative record must have 2202 the Fragment flag set and must contain the fragment offset and 2203 fragment length fields. The value of the fragment offset field must 2204 be the value of the referenced bundle's fragment offset, and the 2205 value of the fragment length field must be the length of the 2206 referenced bundle's payload. 2208 Step 2: A request for transmission of a bundle whose payload is this 2209 administrative record must be presented to the bundle protocol 2210 agent. 2212 6.3. Reception of Custody Signals 2214 For each received custody signal that has the "custody transfer 2215 succeeded" flag set to 1, the administrative element of the 2216 application agent must direct the bundle protocol agent to follow 2217 the custody transfer success procedure in Section 5.11. 2219 For each received custody signal that has the "custody transfer 2220 succeeded" flag set to 0, the administrative element of the 2221 application agent must direct the bundle protocol agent to follow 2222 the custody transfer failure procedure in Section 5.12. 2224 7. Services Required of the Convergence Layer 2226 7.1. The Convergence Layer 2228 The successful operation of the end-to-end bundle protocol depends 2229 on the operation of underlying protocols at what is termed the 2230 "convergence layer"; these protocols accomplish communication 2231 between nodes. A wide variety of protocols may serve this purpose, 2232 so long as each convergence layer protocol adapter provides a 2233 defined minimal set of services to the bundle protocol agent. This 2234 convergence layer service specification enumerates those services. 2236 7.2. Summary of Convergence Layer Services 2238 Each convergence layer protocol adapter is expected to provide the 2239 following services to the bundle protocol agent: 2241 . sending a bundle to a bundle node that is reachable via the 2242 convergence layer protocol; 2243 . delivering to the bundle protocol agent a bundle that was sent 2244 by a bundle node via the convergence layer protocol. 2246 The convergence layer service interface specified here is neither 2247 exhaustive nor exclusive. That is, supplementary DTN protocol 2248 specifications (including, but not restricted to, the Bundle 2249 Security Protocol [BSP]) may expect convergence layer adapters that 2250 serve BP implementations conforming to those protocols to provide 2251 additional services such as retransmitting data that were lost in 2252 transit, discarding bundle-conveying data units that the convergence 2253 layer protocol determines are corrupt or inauthentic, or reporting 2254 on the integrity and/or authenticity of delivered bundles. 2256 8. Security Considerations 2258 The bundle protocol has taken security into concern from the outset 2259 of its design. It was always assumed that security services would be 2260 needed in the use of the bundle protocol. As a result, the bundle 2261 protocol security architecture and the available security services 2262 are specified in an accompanying document, the Bundle Security 2263 Protocol specification [BSP]; an informative overview of this 2264 architecture is provided in [SECO]. 2266 The bundle protocol has been designed with the notion that it will 2267 be run over networks with scarce resources. For example, the 2268 networks might have limited bandwidth, limited connectivity, 2269 constrained storage in relay nodes, etc. Therefore, the bundle 2270 protocol must ensure that only those entities authorized to send 2271 bundles over such constrained environments are actually allowed to 2272 do so. All unauthorized entities should be prevented from consuming 2273 valuable resources as soon as practicable. 2275 Likewise, because of the potentially high latencies and delays 2276 involved in the networks that make use of the bundle protocol, data 2277 sources should be concerned with the integrity of the data received 2278 at the intended destination(s) and may also be concerned with 2279 ensuring confidentiality of the data as it traverses the network. 2280 Without integrity, the bundle payload data might be corrupted while 2281 in transit without the destination able to detect it. Similarly, the 2282 data source can be concerned with ensuring that the data can only be 2283 used by those authorized, hence the need for confidentiality. 2285 Internal to the bundle-aware overlay network, the bundle nodes 2286 should be concerned with the authenticity of other bundle nodes as 2287 well as the preservation of bundle payload data integrity as it is 2288 forwarded between bundle nodes. 2290 As a result, bundle security is concerned with the authenticity, 2291 integrity, and confidentiality of bundles conveyed among bundle 2292 nodes. This is accomplished via the use of two independent security- 2293 specific bundle blocks, which may be used together to provide 2294 multiple bundle security services or independently of one another, 2295 depending on perceived security threats, mandated security 2296 requirements, and security policies that must be enforced. 2298 To provide end-to-end bundle authenticity and integrity, the Block 2299 Integrity Block (BIB) is used. The BIB allows any security-enabled 2300 entity along the delivery path to ensure the integrity of the 2301 bundle's payload or any other block other than a Block 2302 Confidentiality Block. 2304 To provide payload confidentiality, the use of the Block 2305 Confidentiality Block (BCB) is available. The bundle payload, or any 2306 other block aside from the primary block and the Bundle Security 2307 Protocol blocks, may be encrypted to provide end-to-end payload 2308 confidentiality/privacy. 2310 Additionally, convergence-layer protocols that ensure authenticity 2311 of communication between adjacent nodes in BP network topology 2312 SHOULD be used where available, to minimize the ability of 2313 unauthenticated nodes to introduce inauthentic traffic into the 2314 network. 2316 Bundle security must not be invalidated by forwarding nodes even 2317 though they themselves might not use the Bundle Security Protocol. 2319 In particular, while blocks may be added to bundles transiting 2320 intermediate nodes, removal of blocks with the 'Discard block if it 2321 can't be processed' flag unset in the block processing control flags 2322 may cause security to fail. 2324 Inclusion of the Bundle Security Protocol in any Bundle Protocol 2325 implementation is RECOMMENDED. Use of the Bundle Security Protocol 2326 in Bundle Protocol operations is OPTIONAL. 2328 9. IANA Considerations 2330 The "dtn" and "ipn" URI schemes have been provisionally registered 2331 by IANA. See http://www.iana.org/assignments/uri-schemes.html for 2332 the latest details. 2334 Registries of scheme type numbers, extension block type numbers, and 2335 administrative record type numbers will be required. 2337 10. References 2339 10.1. Normative References 2341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2342 Requirement Levels", BCP 14, RFC 2119, March 1997. 2344 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2345 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 2346 January 2005. 2348 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2349 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 2350 2015. 2352 10.2. Informative References 2354 [ARCH] V. Cerf et. al., "Delay-Tolerant Network Architecture", RFC 2355 4838, April 2007. 2357 [ASN1] "Abstract Syntax Notation One (ASN.1), "ASN.1 Encoding Rules: 2358 Specification of Basic Encoding Rules (BER), Canonical Encoding 2359 Rules (CER) and Distinguished Encoding Rules (DER)," ITU-T Rec. 2360 X.690 (2002) | ISO/IEC 8825- 1:2002", 2003. 2362 [BSP] Symington, S., "Bundle Security Protocol Specification", Work 2363 Progress, October 2007. 2365 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 2366 Identifiers (IRIs)", RFC 3987, January 2005. 2368 [RFC5050] Scott, M. and S. Burleigh, "Bundle Protocol 2369 Specification", RFC 5050, November 2007. 2371 [SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay- 2372 Tolerant Networking Security Overview", Work Progress, July 2007. 2374 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 2375 Challenged Internets", SIGCOMM 2003. 2377 [TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A Tutorial", 2378 . 2380 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 2381 historical background and perspectives" in "Journees systemes de 2382 reference spatio-temporels", 2004. 2384 11. Acknowledgments 2386 This work is freely adapted from [RFC5050], which was an effort of 2387 the Delay Tolerant Networking Research Group. The following DTNRG 2388 participants contributed significant technical material and/or 2389 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 2390 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 2391 Michael Demmer of the University of California at Berkeley, Robert 2392 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 2393 Kevin Fall of Intel Research, Stephen Farrell of Trinity College 2394 Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of Ohio 2395 University, and Howard Weiss of SPARTA, Inc. 2397 This document was prepared using 2-Word-v2.0.template.dot. 2399 12. Significant Changes From RFC 5050 2401 Points on which this draft significantly differs from RFC 5050 2402 include the following: 2404 . Clarify the difference between transmission and forwarding. 2405 . Amplify discussion of custody transfer. Move current custodian 2406 to an extension block, of which there can be multiple 2407 occurrences (possible support for the MITRE idea of multiple 2408 concurrent custodians, from several years ago); define that 2409 block in this specification. 2410 . Introduce the concept of "node ID" as functionally distinct 2411 from endpoint ID, while having the same syntax. 2412 . Introduce a new method of encoding endpoint IDs (including node 2413 IDs) in a transmitted bundle, replacing both the "dictionary" 2414 and the CBHE compression mechanism. 2415 . Add ECOS features to primary block. 2416 . Restrict the scope of bundle prioritization to all bundles from 2417 the same source. 2418 . Restructure primary block, making it immutable. Add optional 2419 CRC and inventory. 2420 . Add optional CRCs to non-primary blocks. 2421 . Add block ID number to canonical block format (to support 2422 streamlined BSP). 2423 . Add bundle age extension block, defined in this specification. 2424 . Add previous node ID extension block, defined in this 2425 specification. 2426 . Add flow label block, *not* defined in this specification. 2427 . Add hop count extension block, defined in this specification. 2428 . Clean up a disconnect between fragmentation and custody 2429 transfer that Ed pointed out. 2430 . Remove "DTN time" values from admin records. 2432 13. Open Issues 2434 13.1. Definitions section structure 2436 Would it be better to restrict the Definitions section to 2437 definitions only, and move description, conceptual operation, 2438 potential implementation, justification, and commentary to one or 2439 more additional sections? Or would fractionating this information 2440 across multiple sections would make it harder to grasp? 2442 13.2. Payload nomenclature 2444 It has been proposed that (a) there is no need to define "nominal 2445 payload" and (b) "partial" payload would be better than 2446 "fragmentary" payload. (The term "nominal payload" is used in the 2447 definition of fragmentation.) 2449 13.3. Application Agent 2451 Does the discussion of Application Agent functionality need to be in 2452 the BP spec? If so, should there be a diagram explaining how the 2453 various components of the BPA interact? 2455 13.4. Bundle Endpoint definition 2457 Is the source of a bundle always a node, or do we want to define a 2458 way in which a set of nodes (an endpoint) can collectively transmit 2459 a bundle? Does the latter trace back to a use case we need to 2460 support? 2462 Is a bundle custodian always a node, or do we want to define a way 2463 in which a set of nodes (an endpoint) can collectively take custody 2464 of a bundle? Does the latter trace back to a use case we need to 2465 support?. 2467 13.5. Alignment with ICN 2469 Is it necessary to modify the bundle transmission procedure to 2470 enable BP to be used for information-centric networking, i.e., 2471 delivering data to a node who requests that data after it has 2472 already been transmitted? Specifically, would a DTN ICN cache point 2473 "transmit" data to a client (i.e., source a new bundle) or would it 2474 merely "forward" a previously transmitted bundle of which it has 2475 retained a copy? 2477 13.6. Implementation Architectures 2479 Should the BP spec be divided into two documents? One to talk about 2480 conops and context and one that focuses specifically on the 2481 protocol? 2483 13.7. Security protocol name 2485 Will the name of the DTN security protocol be Bundle Security 2486 Protocol or Streamlined Bundle Security Protocol? 2488 13.8. Bundle format 2490 Should the rules for defining block structure be presented at the 2491 start of section 4 or in the discussion of the payload block and the 2492 "last block" flag? Should we require that the payload block always 2493 be the last block of the bundle, so that the "last block" flag is no 2494 longer needed? (This would make reactive fragmentation easier.) 2496 13.9. SDNVs 2498 Should the SDNV discussion in 4.1 be deleted? 2500 13.10. Bundle Processing Control Flags 2502 Should the bit numbering convention described in section 4.2 be 2503 moved to another location in the document? 2505 13.11. Extended class of service features 2507 Should these features (critical bundle, best-efforts forwarding 2508 requested, reliable forwarding requested) be omitted from the 2509 primary block? If they are omitted, should these application- 2510 selected CoS markings be supported in some other way? If the 2511 "critical" CoS feature is retained, should it have a different 2512 name? 2514 Note: a node selection (route computation) procedure might consider 2515 the availability of CLAs that match the bundle's CoS when selecting 2516 a node to forward to, and that is entirely the business of the route 2517 computation procedure. (Not all route computation procedures will 2518 do so.) 2520 13.12. Primary block CRC type 2522 What are the best CRC options to support here? CRC-16-ARINC, CRC- 2523 16-CCITT, CRC-16-CDMA2000, CRC-16-DECT, etc.? Are there more than 4? 2525 13.13. Inventory 2527 Is a list of the block types of all blocks in the bundle as 2528 forwarded by the source node a good implementation of the requested 2529 "inventory" feature? If not, what would be better? 2531 13.14. Block numbers 2533 Should the payload always have block number zero? 2535 13.15. Clearing flag 2537 Should an node that is able to process a given extension block be 2538 permitted to clear block's "Block was forwarded without being 2539 processed" flag? 2541 13.16. Overriding BP spec 2543 Is a supplementary DTN protocol specification allowed to override or 2544 supersede the BP specification (other than making some BP procedures 2545 moot by requiring that the processing of a bundle be terminated 2546 under fault conditions recognized by that protocol)? 2548 13.17. Time of forwarding 2550 Should the BPA control the time at which a bundle is to be forwarded 2551 to another node, or should that determination be left to the 2552 selected convergence-layer protocol adapter(s)? 2554 13.18. Block multiplicity 2556 Would it be good to restrict BP extensions to one extension block 2557 per extension per bundle? That is, should we require that all 2558 information needed to implement a given BP extension for a given 2559 bundle be contained in a single extension block? 2561 This would entail encapsulating any necessary multiplicity for a 2562 given extension (for example, multiple Metadata records) within a 2563 single block. 2565 Among the advantages: no need for block numbers (block type would 2566 always be sufficient to identify the block), therefore no need for a 2567 block number generation mechanism; shorter and simpler inventory; 2568 simpler extension implementation (all information is in one block, 2569 no need to search through extension blocks for additional relevant 2570 information). 2572 Among the disadvantages: very different from RFC 5050; would in some 2573 cases require that security blocks operate on data structures that 2574 are internal to extension blocks rather than always operate on 2575 entire extension blocks. 2577 Appendix A. For More Information 2579 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 2580 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 2582 Copyright (c) 2015 IETF Trust and the persons identified as authors 2583 of the code. All rights reserved. 2585 Redistribution and use in source and binary forms, with or without 2586 modification, is permitted pursuant to, and subject to the license 2587 terms contained in, the Simplified BSD License set forth in Section 2588 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2589 (http://trustee.ietf.org/license-info). 2591 Authors' Addresses 2593 Scott Burleigh 2594 Jet Propulsion Laboratory, California Institute of Technology 2595 4800 Oak Grove Dr. 2596 Pasadena, CA 91109-8099 2597 US 2598 Phone: +1 818 393 3353 2599 EMail: Scott.Burleigh@jpl.nasa.gov 2601 Kevin Fall 2602 Carnegie Mellon University / Software Engineering Institute 2603 4500 Fifth Avenue 2604 Pittsburgh, PA 15213 2605 US 2606 Phone: +1 412 268 3304 2607 Email: kfall@cmu.edu 2609 Edward J. Birrane 2610 Johns Hopkins University Applied Physics Laboratory 2611 11100 Johns Hopkins Rd 2612 Laurel, MD 20723 2613 US 2614 Phone: +1 443 778 7423 2615 Email: Edward.Birrane@jhuapl.edu