idnits 2.17.1 draft-irtf-dtnrg-bundle-spec-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2247. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 17, 2007) is 6218 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'IPR' is defined on line 2119, but no explicit reference was found in the text == Unused Reference: 'RGTS' is defined on line 2125, but no explicit reference was found in the text == Unused Reference: 'NTP' is defined on line 2152, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3979 (ref. 'IPR') (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 3978 (ref. 'RGTS') (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 4395 (ref. 'URIREG') (Obsoleted by RFC 7595) == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-02 -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) == Outdated reference: A later version (-06) exists of draft-irtf-dtnrg-sec-overview-02 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IRTF Delay Tolerant Networking K. Scott 3 Research Group The MITRE Corporation 4 Internet-Draft S. Burleigh 5 Intended status: Experimental NASA Jet Propulsion Laboratory 6 Expires: October 19, 2007 April 17, 2007 8 Bundle Protocol Specification 9 draft-irtf-dtnrg-bundle-spec-09.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 19, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes the end-to-end protocol, block formats, and 43 abstract service description for the exchange of messages (bundles) 44 in Delay Tolerant Networking (DTN). 46 This document was produced within the IRTF's Delay Tolerant 47 Networking Research Group (DTNRG) and represents the consensus of all 48 of the active contributors to this Group. See http://www.dtnrg.org 49 for more information. 51 Table of Contents 53 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Service Description . . . . . . . . . . . . . . . . . . . . . 7 56 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.2. Implementation architectures . . . . . . . . . . . . . . . 11 58 3.3. Services offered by bundle protocol agents . . . . . . . . 13 59 4. Bundle Format . . . . . . . . . . . . . . . . . . . . . . . . 14 60 4.1. Self-Delimiting Numeric Values (SDNVs) . . . . . . . . . . 14 61 4.2. Bundle Processing Control Flags . . . . . . . . . . . . . 16 62 4.3. Block Processing Control Flags . . . . . . . . . . . . . . 17 63 4.4. Endpoint IDs . . . . . . . . . . . . . . . . . . . . . . . 18 64 4.5. Formats of Bundle Blocks . . . . . . . . . . . . . . . . . 19 65 4.5.1. Primary Bundle Block . . . . . . . . . . . . . . . . . 21 66 4.5.2. Canonical Bundle Block Format . . . . . . . . . . . . 24 67 4.5.3. Bundle Payload Block . . . . . . . . . . . . . . . . . 25 68 4.6. Extension Blocks . . . . . . . . . . . . . . . . . . . . . 26 69 4.7. Dictionary revision . . . . . . . . . . . . . . . . . . . 26 70 5. Bundle Processing . . . . . . . . . . . . . . . . . . . . . . 27 71 5.1. Generation of administrative records . . . . . . . . . . . 27 72 5.2. Bundle Transmission . . . . . . . . . . . . . . . . . . . 28 73 5.3. Bundle Dispatching . . . . . . . . . . . . . . . . . . . . 29 74 5.4. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 29 75 5.4.1. Forwarding Contraindicated . . . . . . . . . . . . . . 31 76 5.4.2. Forwarding Failed . . . . . . . . . . . . . . . . . . 31 77 5.5. Bundle Expiration . . . . . . . . . . . . . . . . . . . . 32 78 5.6. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 32 79 5.7. Local Bundle Delivery . . . . . . . . . . . . . . . . . . 33 80 5.8. Bundle Fragmentation . . . . . . . . . . . . . . . . . . . 34 81 5.9. Application Data Unit Reassembly . . . . . . . . . . . . . 35 82 5.10. Custody Transfer . . . . . . . . . . . . . . . . . . . . . 36 83 5.10.1. Custody Acceptance . . . . . . . . . . . . . . . . . . 36 84 5.10.2. Custody Release . . . . . . . . . . . . . . . . . . . 37 85 5.11. Custody Transfer Success . . . . . . . . . . . . . . . . . 37 86 5.12. Custody Transfer Failure . . . . . . . . . . . . . . . . . 37 87 5.13. Bundle Deletion . . . . . . . . . . . . . . . . . . . . . 38 88 5.14. Discarding a Bundle . . . . . . . . . . . . . . . . . . . 38 89 5.15. Canceling a Transmission . . . . . . . . . . . . . . . . . 38 90 5.16. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 39 91 6. Administrative Record Processing . . . . . . . . . . . . . . . 40 92 6.1. Administrative Records . . . . . . . . . . . . . . . . . . 40 93 6.1.1. Bundle Status Reports . . . . . . . . . . . . . . . . 41 94 6.1.2. Custody Signals . . . . . . . . . . . . . . . . . . . 44 95 6.2. Generation of Administrative Records . . . . . . . . . . . 47 96 6.3. Reception of Custody Signals . . . . . . . . . . . . . . . 47 97 7. Services Required of the Convergence Layer . . . . . . . . . . 48 98 7.1. The Convergence Layer . . . . . . . . . . . . . . . . . . 48 99 7.2. Summary of Convergence Layer Services . . . . . . . . . . 48 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 52 104 10.2. Informative References . . . . . . . . . . . . . . . . . . 52 105 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 54 106 Appendix B. Comments . . . . . . . . . . . . . . . . . . . . . . 55 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 108 Intellectual Property and Copyright Statements . . . . . . . . . . 57 110 1. Requirements notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Introduction 118 This document describes version 6 of the Delay Tolerant Networking 119 (DTN) "bundle" protocol (BP). Delay Tolerant Networking is an end- 120 to-end architecture providing communications in and/or through highly 121 stressed environments. Stressed networking environments include 122 those with intermittent connectivity, large and/or variable delays, 123 and high bit error rates. To provide its services, BP sits at the 124 application layer of some number of constituent internets, forming a 125 store-and-forward overlay network. Key capabilities of BP include: 127 o Custody-based retransmission 129 o Ability to cope with intermittent connectivity 131 o Ability to take advantage of scheduled, predicted, and 132 opportunistic connectivity (in addition to continuous 133 connectivity) 135 o Late binding of overlay network endpoint identifiers to 136 constituent internet addresses 138 For descriptions of these capabilities and the rationale for the DTN 139 architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial-level 140 overview of DTN concepts. 142 BP's location within the standard protocol stack is as shown in 143 Figure 1. BP uses the "native" internet protocols for communications 144 within a given internet. Note that "internet" in the preceding is 145 used in a general sense and does not necessarily refer to TCP/IP. 146 The interface between the common bundle protocol and a specific 147 internetwork protocol suite is termed a "convergence layer adapter". 148 Figure 1 shows three distinct transport and network protocols 149 (denoted T1/N1, T2,N2, and T3/N3). 151 +-----------+ +-----------+ 152 | BP app | | BP app | 153 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 154 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 155 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 156 | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | 157 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 158 | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | 159 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 160 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 161 +-----------+ +-------------+ +-------------+ +-----------+ 162 | | | | 163 |<--- An internet --->| |<--- An internet --->| 164 | | | | 166 Figure 1: The bundle protocol sits at the application layer of the 167 Internet model. 169 This document describes the format of the protocol data units (called 170 bundles) passed between entities participating in BP communications. 171 The entities are referred to as "bundle nodes". This document does 172 not address: 174 o Operations in the convergence layer adapters that bundle nodes use 175 to transport data through specific types of internet. (However, 176 the document does discuss the services that must be provided by 177 each adapter at the convergence layer.) 179 o The bundle routing algorithm. 181 o Mechanisms for populating the routing or forwarding information 182 bases of bundle nodes. 184 3. Service Description 186 3.1. Definitions 188 Bundle - A bundle is a protocol data unit of the DTN bundle 189 protocol. Each bundle comprises a sequence of two or more 190 "blocks" of protocol data, which serve various purposes. Multiple 191 instances of the same bundle (the same unit of DTN protocol data) 192 might exist concurrently in different parts of a network - 193 possibly in different representations - in the memory local to one 194 or more bundle nodes and/or in transit between nodes. In the 195 context of the operation of a bundle node, a bundle is an instance 196 of some bundle in the network that is in that node's local memory. 198 Bundle payload - A bundle payload (or simply "payload") is the 199 application data whose conveyance to the bundle's destination is 200 the purpose for the transmission of a given bundle. The terms 201 "bundle content", "bundle payload", and "payload" are used 202 interchangeably in this document. The "nominal" payload for a 203 bundle forwarded in response to a bundle transmission request is 204 the application data unit whose location is provided as a 205 parameter to that request. The nominal payload for a bundle 206 forwarded in response to reception of that bundle is the payload 207 of the received bundle. 209 Fragment - A fragment is a bundle whose payload block contains a 210 fragmentary payload. A fragmentary payload is either the first N 211 bytes or the last N bytes of some other payload - either a nominal 212 payload or a fragmentary payload - of length M, such that 0 < N < 213 M. 215 Bundle node - A bundle node (or, in the context of this document, 216 simply a "node") is any entity that can send and/or receive 217 bundles. In the most familiar case a bundle node is instantiated 218 as a single process running on a general-purpose computer, but in 219 general the definition is meant to be broader: a bundle node might 220 alternatively be a thread, an object in an object-oriented 221 operating system, a special-purpose hardware device, etc. Each 222 bundle node has three conceptual components, defined below: a 223 "bundle protocol agent", a set of zero or more "convergence layer 224 adapters", and an "application agent". 226 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 227 the node component that offers the BP services and executes the 228 procedures of the Bundle Protocol. The manner in which it does so 229 is wholly an implementation matter. For example, BPA 230 functionality might be coded into each node individually; it might 231 be implemented as a shared library that is used in common by any 232 number of bundle nodes on a single computer; it might be 233 implemented as a daemon whose services are invoked via inter- 234 process or network communication by any number of bundle nodes on 235 one or more computers; it might be implemented in hardware. 237 Convergence layer adapters - A convergence layer adapter (CLA) sends 238 and receives bundles on behalf of the BPA, utilizing the services 239 of some 'native' internet protocol that is supported in one of the 240 internets within which the node is functionally located. The 241 manner in which a CLA sends and receives bundles is wholly an 242 implementation matter, exactly as described for the BPA. 244 Application agent - The application agent (AA) of a node is the node 245 component that utilizes the BP services to effect communication 246 for some purpose. The application agent in turn has two elements, 247 an administrative element and an application-specific element. 248 The application-specific element of an AA constructs, requests 249 transmission of, accepts delivery of, and processes application- 250 specific application data units; the only interface between the 251 BPA and the application-specific element of the AA is the BP 252 service interface. The administrative element of an AA constructs 253 and requests transmission of administrative records (status 254 reports and custody signals), and it accepts delivery of and 255 processes any custody signals that the node receives. In addition 256 to the BP service interface, there is a (conceptual) private 257 control interface between the BPA and the administrative element 258 of the AA that enables each to direct the other to take action 259 under specific circumstances. In the case of a node that serves 260 simply as a "router" in the overlay network, the AA may have no 261 application-specific element at all. The application-specific 262 elements of other nodes' AAs may perform arbitrarily complex 263 application functions, perhaps even offering multiplexed DTN 264 communication services to a number of other applications. As with 265 the BPA, the manner in which the AA performs its functions is 266 wholly an implementation matter; in particular, the administrative 267 element of an AA might be built into the library or daemon or 268 hardware that implements the BPA, and the application-specific 269 element of an AA might be implemented either in software or in 270 hardware. 272 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 273 of zero or more bundle nodes that all identify themselves for BP 274 purposes by some single text string, called a "bundle endpoint ID" 275 (or, in this document, simply "endpoint ID"; endpoint IDs are 276 described in detail in 3.4 below). The special case of an 277 endpoint that never contains more than one node is termed a 278 "singleton" endpoint; every bundle node must be a member of at 279 least one singleton endpoint. Singletons are the most familiar 280 sort of endpoint, but in general the endpoint notion is meant to 281 be broader. For example, the nodes in a sensor network might 282 constitute a set of bundle nodes that identify themselves by a 283 single common endpoint ID and thus form a single bundle endpoint. 284 **Note** too that a given bundle node might identify itself by 285 multiple endpoint IDs and thus be a member of multiple bundle 286 endpoints. 288 Forwarding - When the bundle protocol agent of a node determines 289 that a bundle must be "forwarded" to an endpoint, it causes the 290 bundle to be sent to all of the nodes that the bundle protocol 291 agent currently believes are in the "minimum reception group" of 292 that endpoint. The minimum reception group of an endpoint may be 293 any one of the following: (a) ALL of the nodes registered in an 294 endpoint that is permitted to contain multiple nodes (in which 295 case forwarding to the endpoint is functionally similar to 296 "multicast" operations in the Internet, though possibly very 297 different in implementation); (b) ANY N of the nodes registered in 298 an endpoint that is permitted to contain multiple nodes, where N 299 is in the range from zero to the cardinality of the endpoint (in 300 which case forwarding to the endpoint is functionally similar to 301 "anycast" operations in the Internet); (c) THE SOLE NODE 302 registered in a singleton endpoint (in which case forwarding to 303 the endpoint is functionally similar to "unicast" operations in 304 the Internet). The nature of the minimum reception group for a 305 given endpoint can be determined from the endpoint's ID (again, 306 see 3.4 below): for some endpoint ID "schemes", the nature of the 307 minimum reception group is fixed - in a manner that is defined by 308 the scheme - for all endpoints identified under the scheme; for 309 other schemes, the nature of the minimum reception group is 310 indicated by some lexical feature of the "scheme-specific part" of 311 the endpoint ID, in a manner that is defined by the scheme. 313 Registration - A registration is the state machine characterizing a 314 given node's membership in a given endpoint. Any number of 315 registrations may be concurrently associated with a given 316 endpoint, and any number of registrations may be concurrently 317 associated with a given node. Any single registration must at any 318 time be in one of two states: Active, Passive. A registration 319 always has an associated "delivery failure action", the action 320 that is to be taken when a bundle that is "deliverable" (see 321 below) subject to that registration is received at a time when the 322 registration is in the Passive state. Delivery failure action 323 must be one of the following: 325 * defer "delivery" (see below) of the bundle subject to this 326 registration until (a) this bundle is the least recently 327 received of all bundles currently deliverable subject to this 328 registration and (b) either the registration is polled or else 329 the registration is in Active state; 331 * "abandon" (see below) delivery of the bundle subject to this 332 registration. 334 An additional implementation-specific delivery deferral procedure 335 may optionally be associated with the registration. While the 336 state of a registration is Active, reception of a bundle that is 337 deliverable subject to this registration must cause the bundle to 338 be delivered automatically as soon as it is the least recently 339 received bundle that is currently deliverable subject to the 340 registration. While the state of a registration is Passive, 341 reception of a bundle that is deliverable subject to this 342 registration must cause delivery of the bundle to be abandoned or 343 deferred as mandated by the registration's current delivery 344 failure action; in the latter case, any additional delivery 345 deferral procedure associated with the registration must also be 346 performed. 348 Delivery - Upon reception, the processing of a bundle that has been 349 sent to a given node depends on whether or not the receiving node 350 is registered in the bundle's destination endpoint; if it is, and 351 if the payload of the bundle is non-fragmentary (possibly as a 352 result of successful payload reassembly from fragmentary payloads, 353 including the original payload of the received bundle), then the 354 bundle is normally "delivered" to the node's application agent 355 subject to the registration characterizing the node's membership 356 in the destination endpoint. A bundle is considered to have been 357 delivered at a node subject to a registration as soon as the 358 application data unit that is the payload of the bundle, together 359 with the value of the bundle's "Acknowledgement by application is 360 requested" flag and any other relevant metadata (an implementation 361 matter), has been presented to the node's application agent in a 362 manner consistent with the state of that registration and, as 363 applicable, the registration's delivery failure action. 365 Deliverability, Abandonment - A bundle is considered "deliverable" 366 subject to a registration if and only if (a) the bundle's 367 destination endpoint is the endpoint with which the registration 368 is associated, (b) the bundle has not yet been delivered subject 369 to this registration, and (c) delivery of the bundle subject to 370 this registration has not been abandoned. To "abandon" delivery 371 of a bundle subject to a registration is simply to declare it no 372 longer deliverable subject to that registration; normally only 373 registrations' registered delivery failure actions cause 374 deliveries to be abandoned. 376 Deletion, Discarding - A bundle protocol agent "discards" a bundle 377 by simply ceasing all operations on the bundle and functionally 378 erasing all references to it; the specific procedures by which 379 this is accomplished are an implementation matter. Bundles are 380 discarded silently, i.e., the discarding of a bundle does not 381 result in generation of an administrative record. "Retention 382 constraints" are elements of bundle state that prevent a bundle 383 from being discarded; a bundle cannot be discarded while it has 384 any retention constraints. A bundle protocol agent "deletes" a 385 bundle in response to some anomalous condition by notifying the 386 bundle's report-to endpoint of the deletion (provided such 387 notification is warranted; see 4.13 for details) and then 388 arbitrarily removing all of the bundle's retention constraints, 389 enabling the bundle to be discarded. 391 Transmission - A transmission is a sustained effort by a node's 392 bundle protocol agent to cause a bundle to be sent to all nodes in 393 the minimum reception group of some endpoint (which may be the 394 bundle's destination or may be some intermediate forwarding 395 endpoint) in response to a transmission request issued by the 396 node's application agent. Any number of transmissions may be 397 concurrently undertaken by the bundle protocol agent of a given 398 node. 400 Custody - To "accept custody" upon forwarding a bundle is to commit 401 to retaining a copy of the bundle - possibly re-forwarding the 402 bundle when the necessity to do so is determined - until custody 403 of that bundle is "released". Custody of a bundle whose 404 destination is a singleton endpoint is released when either (a) 405 notification is received that some other node has accepted custody 406 of the same bundle, (b) notification is received that the bundle 407 has been delivered at the (sole) node registered in the bundle's 408 destination endpoint, or (c) the bundle is explicitly deleted for 409 some reason, such as lifetime expiration. The condition(s) under 410 which custody of a bundle whose destination is not a singleton 411 endpoint may be released are not defined in this specification. 412 To "refuse custody" of a bundle is to decide not to accept custody 413 of the bundle. A "custodial node" of a bundle is a node that has 414 accepted custody of the bundle and has not yet released that 415 custody. A "custodian" of a bundle is a singleton endpoint whose 416 sole member is one of the bundle's custodial nodes. 418 3.2. Implementation architectures 420 The above definitions are intended to enable the bundle protocol's 421 operations to be specified in a manner that minimizes bias toward any 422 particular implementation architecture. To illustrate the range of 423 interoperable implementation models that might conform to this 424 specification, four example architectures are briefly described 425 below. 427 1. Bundle protocol application server 429 A single bundle protocol application server, constituting a 430 single bundle node, runs as a daemon process on each computer. 431 The daemon's functionality includes all functions of the bundle 432 protocol agent, all convergence layer adapters, and both the 433 administrative and application-specific elements of the 434 application agent. The application-specific element of the 435 application agent functions as a server, offering bundle protocol 436 service over a local area network: it responds to remote 437 procedure calls from application processes (on the same computer 438 and/or remote computers) that need to communicate via the bundle 439 protocol. The server supports its clients by creating a new 440 (conceptual) node for each one and registering each such node in 441 a client-specified endpoint; the conceptual nodes managed by the 442 server function as clients' Bundle Protocol service access 443 points. 445 2. Peer application nodes 447 Any number of bundle protocol application processes, each one 448 constituting a single bundle node, run in ad-hoc fashion on each 449 computer. The functionality of the bundle protocol agent, all 450 convergence layer adapters, and the administrative element of the 451 application agent is provided by a library to which each node 452 process is dynamically linked at run time; the application- 453 specific element of each node's application agent is node- 454 specific application code. 456 3. Sensor network nodes 458 Each node of the sensor network is the self-contained 459 implementation of a single bundle node. All functions of the 460 bundle protocol agent, all convergence layer adapters, and the 461 administrative element of the application agent are implemented 462 in simplified form in ASICs, while the application-specific 463 element of each node's application agent is implemented in a 464 programmable microcontroller. Forwarding is rudimentary: all 465 bundles are forwarded on a hard-coded default route. 467 4. Dedicated bundle router 469 Each computer constitutes a single bundle node that functions 470 solely as a high-performance bundle forwarder. Many standard 471 functions of the bundle protocol agent, the convergence layer 472 adapters, and the administrative element of the application agent 473 are implemented in ASICs, but some functions are implemented in a 474 high-speed processor to enable reprogramming as necessary. The 475 node's application agent has no application-specific element. 476 Substantial non-volatile storage resources are provided, and 477 arbitrarily complex forwarding algorithms are supported. 479 3.3. Services offered by bundle protocol agents 481 The bundle protocol agent of each node is expected to provide the 482 following services to the node's application agent: 484 o commencing a registration (registering a node in an endpoint); 486 o terminating a registration; 488 o switching a registration between Active and Passive state; 490 o transmitting a bundle to an identified bundle endpoint; 492 o canceling a transmission; 494 o polling a registration that is in passive state; 496 o delivering a received bundle. 498 4. Bundle Format 500 Each bundle shall be a concatenated sequence of at least two block 501 structures. The first block in the sequence must be a primary bundle 502 block, and no bundle may have more than one primary bundle block. 503 Additional bundle protocol blocks of other types may follow the 504 primary block to support extensions to the Bundle Protocol, such as 505 the Bundle Security Protocol [BSP]. At most one of the blocks in the 506 sequence may be a payload block. The last block in the sequence must 507 have the "last block" flag (in its block processing control flags) 508 set to 1; for every other block in the bundle after the primary 509 block, this flag must be set to zero. 511 4.1. Self-Delimiting Numeric Values (SDNVs) 513 The design of the bundle protocol attempts to reconcile minimal 514 consumption of transmission bandwidth with: 516 o extensibility to address requirements not yet identified, and 518 o scalability across a wide range of network scales and payload 519 sizes. 521 A key strategic element in the design is the use of self-delimiting 522 numeric values (SDNVs). The SDNV encoding scheme is closely adapted 523 from the Abstract Syntax Notation One Basic Encoding Rules for 524 subidentifiers within an object identifier value [ASN1]. An SDNV is 525 a numeric value encoded in N octets, the last of which has its most 526 significant bit (MSB) set to zero; the MSB of every other octet in 527 the SDNV must be set to 1. The value encoded in an SDNV is the 528 unsigned binary number obtained by concatenating into a single bit 529 string the 7 least significant bits of each octet of the SDNV. 531 The following examples illustrate the encoding scheme for various 532 hexadecimal values. 534 0xABC : 1010 1011 1100 535 is encoded as 536 {1 00 10101} {0 0111100} 537 = 10010101 00111100 539 0x1234 : 0001 0010 0011 0100 540 = 1 0010 0011 0100 541 is encoded as 542 {1 0 100100} {0 0110100} 543 = 10100100 00110100 545 0x4234 : 0100 0010 0011 0100 546 = 100 0010 0011 0100 547 is encoded as 548 {1 000000 1} {1 0000100} {0 0110100} 549 = 10000001 10000100 00110100 551 0x7F : 0111 1111 552 = 111 1111 553 is encoded as 554 {0 1111111} 555 = 01111111 557 Figure 2: SDNV Example 559 Note: Care must be taken to make sure that the value to be encoded is 560 (in concept) padded with high-order zero bits to make its bitwise 561 length a multiple of 7 before encoding. Also note that, while there 562 is no theoretical limit on the size of an SDNV field, the overhead of 563 the SDNV scheme is 1:7, i.e., one bit of overhead for every 7 bits of 564 actual data to be encoded. Thus a 7-octet value (a 56-bit quantity 565 with no leading zeroes) would be encoded in an 8-octet SDNV; an 566 8-octet value (a 64-bit quantity with no leading zeroes) would be 567 encoded in a 10-octet SDNV (one octet containing the high-order bit 568 of the value padded with six leading zero bits, followed by nine 569 octets containing the remaining 63 bits of the value). 148 bits of 570 overhead would be consumed in encoding a 1024-bit RSA encryption key 571 directly in an SDNV. In general, an N-bit quantity with no leading 572 zeroes is encoded in an SDNV occupying ceil(N/7) octets, where ceil 573 is the integer ceiling function. 575 Implementations of the Bundle Protocol may handle as an invalid 576 numeric value any SDNV that encodes an integer that is larger than 577 (2^64 - 1). 579 An SDNV can be used to represent both very large and very small 580 integer values. However, SDNV is clearly not the best way to 581 represent every numeric value. For example, an SDNV is a poor way to 582 represent an integer whose value typically falls in the range 128 to 583 255. In general, though, we believe that SDNV representation of 584 numeric values in bundle blocks yields the smallest block sizes 585 without sacrificing scalability. 587 4.2. Bundle Processing Control Flags 589 The bundle processing control flags field in the primary bundle block 590 of each bundle is an SDNV; the value encoded in this SDNV is a string 591 of bits used to invoke selected bundle processing control features. 592 The significance of the value in each currently defined position of 593 this bit string is described here. Note that in the figure and 594 descriptions, the bit label numbers denote position (from least 595 significant ('0') to most significant) within the decoded bit string, 596 and not within the representation of the bits on the wire. This is 597 why the descriptions in this section and the next do not follow 598 standard RFC conventions with bit 0 on the left; if fields are added 599 in the future, the SDNV will grow to the left, and using this 600 representation allows the references here to remain valid. 602 2 1 0 603 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 |Status Report|Class of Svc.| General | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Figure 3: Bundle processing control flags bit layout 610 The bits in positions 0 through 6 are flags that characterize the 611 bundle as follows: 613 0 -- Bundle is a fragment. 615 1 -- Application data unit is an administrative record. 617 2 -- Bundle must not be fragmented. 619 3 -- Custody transfer is requested. 621 4 -- Destination endpoint is a singleton. 623 5 -- Acknowledgement by application is requested. 625 6 -- Reserved for future use. 627 The bits in positions 7 through 13 are used to indicate the bundle's 628 class of service. The bits in positions 8 and 7 constitute a two-bit 629 priority field indicating the bundle's priority, with higher values 630 being of higher priority: 00 = bulk, 01 = normal, 10 = expedited, 11 631 is reserved for future use. Within this field, bit 8 is the most 632 significant bit. The bits in positions 9 through 13 are reserved for 633 future use. 635 The bits in positions 14 through 20 are status report request flags. 636 These flags are used to request status reports as follows: 638 14 -- Request reporting of bundle reception. 640 15 -- Request reporting of custody acceptance. 642 16 -- Request reporting of bundle forwarding. 644 17 -- Request reporting of bundle delivery. 646 18 -- Request reporting of bundle deletion. 648 19 -- Reserved for future use. 650 20 -- Reserved for future use. 652 If the bundle processing control flags indicate that the bundle's 653 application data unit is an administrative record, then the custody 654 transfer requested flag must be zero and all status report request 655 flags must be zero. If the custody transfer requested flag is 1 then 656 the sending node requests that the receiving node accept custody of 657 the bundle. If the bundle's source endpoint ID is "dtn:none" (see 658 below), then the bundle is not uniquely identifiable and all bundle 659 protocol features that rely on bundle identity must therefore be 660 disabled: the bundle's custody transfer requested flag must be zero, 661 the "bundle must not be fragmented" flag must be 1, and all status 662 report request flags must be zero. 664 4.3. Block Processing Control Flags 666 The block processing control flags field in every block other than 667 the primary bundle block is an SDNV; the value encoded in this SDNV 668 is a string of bits used to invoke selected block processing control 669 features. The significance of the values in all currently defined 670 positions of this bit string, in order from least-significant 671 position in the decoded bit string (labeled '0') to most-significant 672 (labeled '6'), are described here. 674 0 675 6 5 4 3 2 1 0 676 +-+-+-+-+-+-+-+ 677 | Flags | 678 +-+-+-+-+-+-+-+ 680 Figure 4: Block processing control flags bit layout 682 0 - Block must be replicated in every fragment. 684 1 - Transmit status report if block can't be processed. 686 2 - Delete bundle if block can't be processed. 688 3 - Last block. 690 4 - Discard block if it can't be processed. 692 5 - Block was forwarded without being processed. 694 6 - Block contains an EID-reference field. 696 For each bundle whose primary block's bundle processing control flags 697 (see above) indicate that the bundle's application data unit is an 698 administrative record, the "Transmit status report if block can't be 699 processed" flag in the block processing flags field of every other 700 block in the bundle must be zero. 702 The 'Block must be replicated in every fragment' bit in the block 703 processing flags must be set to zero on all blocks that follow the 704 payload block. 706 4.4. Endpoint IDs 708 The destinations of bundles are bundle endpoints, identified by text 709 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 710 conveyed in any bundle block takes the form of a Uniform Resource 711 Identifier (URI; [URI]). As such, each endpoint ID can be 712 characterized as having this general structure: 714 < scheme name > : < scheme-specific part, or "SSP" > 716 As used for the purposes of the bundle protocol, neither the length 717 of a scheme name nor the length of an SSP may exceed 1023 bytes. 719 Bundle blocks cite a number of endpoint IDs for various purposes of 720 the bundle protocol. Many, though not necessarily all, of the 721 endpoint IDs referred to in the blocks of a given bundle are conveyed 722 in the "dictionary" byte array in the bundle's primary block. This 723 array is simply the concatenation of any number of null-terminated 724 scheme names and SSPs. 726 "Endpoint ID references" are used to cite endpoint IDs that are 727 contained in the dictionary; all endpoint ID citations in the primary 728 bundle block are endpoint ID references, and other bundle blocks may 729 contain endpoint ID references as well. Each endpoint ID reference 730 is an ordered pair of SDNVs: 732 o The first SDNV contains the offset within the dictionary of the 733 first character of the referenced endpoint ID's scheme name. 735 o The second SDNV contains the offset within the dictionary of the 736 first character of the referenced endpoint ID's SSP. 738 This encoding enables a degree of block compression: when the source 739 and report-to of a bundle are the same endpoint, for example, the 740 text of that endpoint's ID may be cited twice yet appear only once in 741 the dictionary. 743 The scheme identified by the < scheme name > in an endpoint ID is a 744 set of syntactic and semantic rules that fully explain how to parse 745 and interpret the SSP. The set of allowable schemes is effectively 746 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 747 protocol endpoint ID. In addition, a single additional scheme is 748 defined by the present document: 750 o The "dtn" scheme, which is used at minimum in the representation 751 of the null endpoint ID "dtn:none". The forwarding of a bundle to 752 the null endpoint is never contraindicated, and the minimum 753 reception group for the null endpoint is the empty set. 755 Note that, although the endpoint IDs conveyed in bundle blocks are 756 expressed as URIs, implementations of the BP service interface may 757 support expression of endpoint IDs in some internationalized manner 758 (e.g., IRIs; see RFC 3987). 760 4.5. Formats of Bundle Blocks 762 This section describes the formats of the primary block and payload 763 block. Rules for processing these blocks appear in Section 5 of this 764 document. 766 Note that supplementary DTN protocol specifications (including, but 767 not restricted to, the Bundle Security Protocol [BSP]) may require 768 that BP implementations conforming to those protocols construct and 769 process additional blocks. 771 The format of the two basic BP blocks is shown in Figure 5 below. 773 Primary Bundle Block 774 +----------------+----------------+----------------+----------------+ 775 | Version | Proc. Flags (*) | 776 +----------------+----------------+----------------+----------------+ 777 | Block length (*) | 778 +----------------+----------------+---------------------------------+ 779 | Destination scheme offset (*) | Destination SSP offset (*) | 780 +----------------+----------------+----------------+----------------+ 781 | Source scheme offset (*) | Source SSP offset (*) | 782 +----------------+----------------+----------------+----------------+ 783 | Report-to scheme offset (*) | Report-to SSP offset (*) | 784 +----------------+----------------+----------------+----------------+ 785 | Custodian scheme offset (*) | Custodian SSP offset (*) | 786 +----------------+----------------+----------------+----------------+ 787 | Creation Timestamp time (*) | 788 +---------------------------------+---------------------------------+ 789 | Creation Timestamp sequence number (*) | 790 +---------------------------------+---------------------------------+ 791 | Lifetime (*) | 792 +----------------+----------------+----------------+----------------+ 793 | Dictionary length (*) | 794 +----------------+----------------+----------------+----------------+ 795 | Dictionary byte array (variable) | 796 +----------------+----------------+---------------------------------+ 797 | [Fragment offset (*)] | 798 +----------------+----------------+---------------------------------+ 799 | [Total application data unit length (*)] | 800 +----------------+----------------+---------------------------------+ 802 Bundle Payload Block 803 +----------------+----------------+----------------+----------------+ 804 | Block type | Proc. Flags (*)| Block length(*) | 805 +----------------+----------------+----------------+----------------+ 806 / Bundle Payload (variable) / 807 +-------------------------------------------------------------------+ 809 Figure 5: Bundle Block Formats 811 (*) Notes: 813 The bundle processing control ("Proc.") flags field in the Primary 814 Bundle Block is an SDNV and is therefore variable-length. A three- 815 octet SDNV is shown here for convenience in representation. 817 The block length field of the Primary Bundle Block is an SDNV and is 818 therefore variable-length. A four-octet SDNV is shown here for 819 convenience in representation. 821 Each of the eight offset fields in the Primary Bundle Block is an 822 SDNV and is therefore variable-length. Two-octet SDNVs are shown 823 here for convenience in representation. 825 The Creation Timestamp time field in the Primary Bundle Block is an 826 SDNV and is therefore variable-length. A four-octet SDNV is shown 827 here for convenience in representation. 829 The Creation Timestamp sequence number field in the Primary Bundle 830 Block is an SDNV and is therefore variable-length. A four-octet SDNV 831 is shown here for convenience in representation. 833 The Lifetime field in the Primary Bundle Block is an SDNV and is 834 therefore variable-length. A four-octet SDNV is shown here for 835 convenience in representation. 837 The dictionary length field of the Primary Bundle Block is an SDNV 838 and is therefore variable-length. A four-octet SDNV is shown here 839 for convenience in representation. 841 The fragment offset field of the Primary Bundle Block is present only 842 if the Fragment flag in the block's processing flags byte is set to 843 1. It is an SDNV and is therefore variable-length; a four-octet SDNV 844 is shown here for convenience in representation. 846 The total application data unit length field of the Primary Bundle 847 Block is present only if the Fragment flag in the block's processing 848 flags byte is set to 1. It is an SDNV and is therefore variable- 849 length; a four-octet SDNV is shown here for convenience in 850 representation. 852 The block processing control ("Proc.") flags field of the Payload 853 Block is an SDNV and is therefore variable-length. A one-octet SDNV 854 is shown here for convenience in representation. 856 The block length field of the Payload Block is an SDNV and is 857 therefore variable-length. A two-octet SDNV is shown here for 858 convenience in representation. 860 4.5.1. Primary Bundle Block 862 The primary bundle block contains the basic information needed to 863 route bundles to their destinations. The fields of the primary 864 bundle block are: 866 Version: A 1-byte field indicating the version of the bundle 867 protocol that constructed this block. The present document 868 describes version 0x05 of the bundle protocol. 870 Bundle Processing Control Flags: The Bundle Processing Control 871 Flags field is an SDNV that contains the bundle processing control 872 flags discussed in Section 4.2 above. 874 Block Length: The Block Length field is an SDNV that contains the 875 aggregate length of all remaining fields of the block. 877 Destination Scheme Offset: The Destination Scheme Offset field 878 contains the offset within the dictionary byte array of the scheme 879 name of the endpoint ID of the bundle's destination, i.e., the 880 endpoint containing the node(s) at which the bundle is to be 881 delivered. 883 Destination SSP Offset: The Destination SSP Offset field contains 884 the offset within the dictionary byte array of the scheme-specific 885 part of the endpoint ID of the bundle's destination. 887 Source Scheme Offset: The Source Scheme Offset field contains the 888 offset within the dictionary byte array of the scheme name of the 889 endpoint ID of the bundle's nominal source, i.e., the endpoint 890 nominally containing the node from which the bundle was initially 891 transmitted. 893 Source SSP Offset: The Source SSP Offset field contains the offset 894 within the dictionary byte array of the scheme-specific part of 895 the endpoint ID of the bundle's nominal source. 897 Report-to Scheme Offset: The Report-to Scheme Offset field contains 898 the offset within the dictionary byte array of the scheme name of 899 the ID of the endpoint to which status reports pertaining to the 900 forwarding and delivery of this bundle are to be transmitted. 902 Report-to SSP Offset: The Report-to SSP Offset field contains the 903 offset within the dictionary byte array of the scheme-specific 904 part of the ID of the endpoint to which status reports pertaining 905 to the forwarding and delivery of this bundle are to be 906 transmitted. 908 Custodian Scheme Offset: The "current custodian endpoint ID" of a 909 primary bundle block identifies an endpoint whose membership 910 includes the node that most recently accepted custody of the 911 bundle upon forwarding this bundle. The Custodian Scheme Offset 912 field contains the offset within the dictionary byte array of the 913 scheme name of the current custodian endpoint ID. 915 Custodian SSP Offset: The Destination SSP Offset field contains the 916 offset within the dictionary byte array of the scheme-specific 917 part of the current custodian endpoint ID. 919 Creation Timestamp: The creation timestamp is a pair of SDNVs that, 920 together with the source endpoint ID and (if the bundle is a 921 fragment) the fragment offset and payload length, serve to 922 identify the bundle. The first SDNV of the timestamp is the 923 bundle's creation time while the second is the bundle's creation 924 timestamp sequence number. Bundle creation time is the time - 925 expressed in seconds since the start of the year 2000, on the 926 Coordinated Universal Time (UTC) scale [UTC] - at which the 927 transmission request was received that resulted in the creation of 928 the bundle. Sequence count is the latest value (as of the time at 929 which that transmission request was received) of a monotonically 930 increasing positive integer counter managed by the source node's 931 bundle protocol agent that may be reset to zero whenever the 932 current time advances by one second. A source Bundle Protocol 933 Agent must never create two distinct bundles with the same source 934 endpoint ID and bundle creation timestamp. The combination of 935 source endpoint ID and bundle creation timestamp therefore serves 936 to identify a single transmission request, enabling it to be 937 acknowledged by the receiving application (provided the source 938 endpoint ID is not "dtn:none"). 940 Lifetime: The lifetime field is an SDNV that indicates the time at 941 which the bundle's payload will no longer be useful, encoded as a 942 number of seconds past the creation time. When the current time 943 is greater than the creation time plus the lifetime, bundle nodes 944 need no longer retain or forward the bundle; the bundle may be 945 deleted from the network. 947 Dictionary Length: The Dictionary Length field is an SDNV that 948 contains the length of the dictionary byte array. 950 Dictionary: The Dictionary field is an array of bytes formed by 951 concatenating the null-terminated scheme names and SSPs of all 952 endpoint IDs referenced by any fields in this Primary Block 953 together with, potentially, other endpoint IDs referenced by 954 fields in other TBD DTN protocol blocks. Its length is given by 955 the value of the Dictionary Length field. 957 Fragment Offset: If the Bundle Processing Control Flags of this 958 Primary block indicate that the bundle is a fragment, then the 959 Fragment Offset field is an SDNV indicating the offset from the 960 start of the original application data unit at which the bytes 961 comprising the payload of this bundle were located. If not, then 962 the Fragment Offset field is omitted from the block. 964 Total Application Data Unit Length: If the Bundle Processing 965 Control Flags of this Primary block indicate that the bundle is a 966 fragment, then the Total Application Data Unit Length field is an 967 SDNV indicating the total length of the original application data 968 unit of which this bundle's payload is a part. If not, then the 969 Total Application Data Unit Length field is omitted from the 970 block. 972 4.5.2. Canonical Bundle Block Format 974 Every bundle block of every type other than the primary bundle block 975 comprises the following fields, in this order: 977 o Block type code, expressed as an 8-bit unsigned binary integer. 978 Bundle block type code 1 indicates that the block is a bundle 979 payload block. Block type codes 192 through 255 are not defined 980 in this specification and are available for private and/or 981 experimental use. All other values of the block type code are 982 reserved for future use. 984 o Block processing control flags, an unsigned integer expressed as 985 an SDNV. The individual bits of this integer are used to invoke 986 selected block processing control features. 988 o Block EID reference count and EID references (optional). If and 989 only if the block references EID elements in the primary block's 990 dictionary, the 'block contains an EID-reference field' flag in 991 the block processing control flags is set to 1 and the block 992 includes an EID reference field consisting of a count of EID 993 references expressed as an SDNV followed by the EID references 994 themselves. Each EID reference is a pair of SDNVs. The first 995 SDNV of each EID reference contains the offset of a scheme name in 996 the primary block's dictionary, and the second SDNV of each 997 reference contains the offset of a scheme-specific part in the 998 dictionary. 1000 o Block data length, an unsigned integer expressed as an SDNV. The 1001 Block data length field contains the aggregate length of all 1002 remaining fields of the block, i.e., the block-type-specific data 1003 fields. 1005 o Block-type-specific data fields, whose format and order are type- 1006 specific and whose aggregate length in octets is the value of the 1007 block data length field. All multi-byte block-type-specific data 1008 fields are represented in network byte order. 1010 +-----------+-----------+-----------+-----------+ 1011 |Block type | Block processing ctrl flags (SDNV)| 1012 +-----------+-----------+-----------+-----------+ 1013 | Block length (SDNV) | 1014 +-----------+-----------+-----------+-----------+ 1015 / Block body data (variable) / 1016 +-----------+-----------+-----------+-----------+ 1018 Figure 6: Block layout without EID reference list. 1020 +-----------+-----------+-----------+-----------+ 1021 |Block Type | Block processing ctrl flags (SDNV)| 1022 +-----------+-----------+-----------+-----------+ 1023 | EID Reference Count (SDNV) | 1024 +-----------+-----------+-----------+-----------+ 1025 | Ref_scheme_1 (SDNV) | Ref_ssp_1 (SDNV) | 1026 +-----------+-----------+-----------+-----------+ 1027 | Ref_scheme_2 (SDNV) | Ref_ssp_2 (SDNV) | 1028 +-----------+-----------+-----------+-----------+ 1029 | Block length (SDNV) | 1030 +-----------+-----------+-----------+-----------+ 1031 / Block body data (variable) / 1032 +-----------+-----------+-----------+-----------+ 1034 Figure 7: Block layout showing two EID references. 1036 4.5.3. Bundle Payload Block 1038 The fields of the bundle payload block are: 1040 Block Type: The Block Type field is a 1-byte field that indicates 1041 the type of the block. For the bundle payload block this field 1042 contains the value 1. 1044 Block Processing Control Flags: The Block Processing Control Flags 1045 field is an SDNV that contains the block processing control flags 1046 discussed in Section 4.3 above. 1048 Block Length: The Block Length field is an SDNV that contains the 1049 aggregate length of all remaining fields of the block - which is 1050 to say, the length of the bundle's payload. 1052 Payload: The application data carried by this bundle. 1054 That is, bundle payload blocks follow the canonical format of the 1055 previous section with the restriction that the 'block contains an 1056 EID-reference field' bit of the block processing control flags is 1057 never set. The block body data for payload blocks is the application 1058 data carried by the bundle. 1060 4.6. Extension Blocks 1062 "Extension blocks" are all blocks other than the primary and payload 1063 blocks. Because extension blocks are not defined in the Bundle 1064 Protocol specification (the present document), not all nodes 1065 conforming to this specification will necessarily instantiate Bundle 1066 Protocol implementations that include procedures for processing (that 1067 is, recognizing, parsing, acting on, and/or producing) all extension 1068 blocks. It is therefore possible for a node to receive a bundle that 1069 includes extension blocks which the node cannot process. 1071 Whenever a bundle is forwarded that contains one or more extension 1072 blocks that could not be processed, the "Block was forwarded without 1073 being processed" flag must be set to 1 within the block processing 1074 flags of each such block. For each block flagged in this way, the 1075 flag may optionally be cleared (i.e., set to zero) by another node 1076 that subsequently receives the bundle and is able to process that 1077 block; the specifications defining the various extension blocks are 1078 expected to define the circumstances under which this flag may be 1079 cleared, if any. 1081 4.7. Dictionary revision 1083 Any strings (scheme names and SSPs) in a bundle's dictionary that are 1084 not referenced from the bundle's primary block nor from the block EID 1085 reference field of any extension block may be removed from the 1086 dictionary at the time the bundle is forwarded. 1088 Whenever removal of a string from the dictionary causes the offsets 1089 (within the dictionary byte array) of any other strings to change, 1090 all endpoint ID references that refer to those strings must be 1091 adjusted at the same time. Note that these references may be in the 1092 primary block and/or in the block EID reference fields of extension 1093 blocks. 1095 5. Bundle Processing 1097 The bundle processing procedures mandated in this section and in 1098 Section 6 govern the operation of the Bundle Protocol Agent and the 1099 Application Agent administrative element of each bundle node. They 1100 are neither exhaustive nor exclusive. That is, supplementary DTN 1101 protocol specifications (including, but not restricted to, the Bundle 1102 Security Protocol [BSP]) may require that additional measures be 1103 taken at specified junctures in these procedures. Such additional 1104 measures shall not override or supersede the mandated bundle protocol 1105 procedures, except that they may in some cases make these procedures 1106 moot by requiring, for example, that implementations conforming to 1107 the supplementary protocol terminate the processing of a given 1108 incoming or outgoing bundle due to a fault condition recognized by 1109 that protocol. 1111 5.1. Generation of administrative records 1113 All initial transmission of bundles is in response to bundle 1114 transmission requests presented by nodes' application agents. When 1115 required to "generate" an administrative record (a bundle status 1116 report or a custody signal), the bundle protocol agent itself is 1117 responsible for causing a new bundle to be transmitted, conveying 1118 that record. In concept, the bundle protocol agent discharges this 1119 responsibility by directing the administrative element of the node's 1120 application agent to construct the record and request its 1121 transmission as detailed in Section 6 below; in practice, the manner 1122 in which administrative record generation is accomplished is an 1123 implementation matter, provided the constraints noted in Section 6 1124 are observed. 1126 Under some circumstances the requesting of status reports could 1127 result in an unacceptable increase in the bundle traffic in the 1128 network. For this reason, the generation of status reports is 1129 mandatory only in one case, the deletion of a bundle for which 1130 custody transfer is requested. In all other cases the decision on 1131 whether or not to generate a requested status report is left to the 1132 discretion of the bundle protocol agent. Mechanisms that could 1133 assist in making such decisions, such as pre-placed agreements 1134 authorizing the generation of status reports under specified 1135 circumstances, are beyond the scope of this specification. 1137 Notes on administrative record terminology: 1139 o A "bundle reception status report" is a bundle status report with 1140 the "reporting node received bundle" flag set to 1. 1142 o A "custody acceptance status report" is a bundle status report 1143 with the "reporting node accepted custody of bundle" flag set to 1144 1. 1146 o A "bundle forwarding status report" is a bundle status report with 1147 the "reporting node forwarded the bundle" flag set to 1. 1149 o A "bundle delivery status report" is a bundle status report with 1150 the "reporting node delivered the bundle" flag set to 1. 1152 o A "bundle deletion status report" is a bundle status report with 1153 the "reporting node deleted the bundle" flag set to 1. 1155 o A "Succeeded" custody signal is a custody signal with the "custody 1156 transfer succeeded" flag set to 1. 1158 o A "Failed" custody signal is a custody signal with the "custody 1159 transfer succeeded" flag set to zero. 1161 o The "current custodian" of a bundle is the endpoint identified by 1162 the current custodian endpoint ID in the bundle's primary block. 1164 5.2. Bundle Transmission 1166 The steps in processing a bundle transmission request are: 1168 Step 1: If custody transfer is requested for this bundle 1169 transmission and, moreover, custody acceptance by the source node 1170 is required, then either the bundle protocol agent must commit to 1171 accepting custody of the bundle - in which case processing 1172 proceeds from Step 2 - or else the request cannot be honored and 1173 all remaining steps of this procedure must be skipped. The bundle 1174 protocol agent must not commit to accepting custody of a bundle if 1175 the conditions under which custody of the bundle may be accepted 1176 are not satisfied. The conditions under which a node may accept 1177 custody of a bundle whose destination is not a singleton endpoint 1178 are not defined in this specification. 1180 Step 2: Transmission of the bundle is initiated. An outbound 1181 bundle must be created per the parameters of the bundle 1182 transmission request, with current custodian endpoint ID set to 1183 the null endpoint ID "dtn:none" and with the retention constraint 1184 "Dispatch pending". The source endpoint ID of the bundle must be 1185 either the ID of an endpoint of which the node is a member or else 1186 the null endpoint ID "dtn:none". 1188 Step 3: Processing proceeds from Step 1 of Section 5.4. 1190 5.3. Bundle Dispatching 1192 The steps in dispatching a bundle are: 1194 Step 1: If the bundle's destination endpoint is an endpoint of 1195 which the node is a member, the bundle delivery procedure defined 1196 in Section 5.7 must be followed. 1198 Step 2: Processing proceeds from Step 1 of section Section 5.4. 1200 5.4. Bundle Forwarding 1202 The steps in forwarding a bundle are: 1204 Step 1: The retention constraint "Forward pending" must be added to 1205 the bundle, and the bundle's "Dispatch pending" retention 1206 constraint must be removed. 1208 Step 2: The bundle protocol agent must determine whether or not 1209 forwarding is contraindicated for any of the reasons listed in 1210 Figure 12. In particular: 1212 * The bundle protocol agent must determine which endpoint(s) to 1213 forward the bundle to. The bundle protocol agent may choose 1214 either to forward the bundle directly to its destination 1215 endpoint (if possible) or else to forward the bundle to some 1216 other endpoint(s) for further forwarding. The manner in which 1217 this decision is made may depend on the scheme name in the 1218 destination endpoint ID but in any case is beyond the scope of 1219 this document. If the agent finds it impossible to select any 1220 endpoint(s) to forward the bundle to, then forwarding is 1221 contraindicated. 1223 * Provided the bundle protocol agent succeeded in selecting the 1224 endpoint(s) to forward the bundle to, the bundle protocol agent 1225 must select the convergence layer adapter(s) whose services 1226 will enable the node to send the bundle to the nodes of the 1227 minimum reception group of each selected endpoint. The manner 1228 in which the appropriate convergence layer adapters are 1229 selected may depend on the scheme name in the destination 1230 endpoint ID but in any case is beyond the scope of this 1231 document. If the agent finds it impossible to select 1232 convergence layer adapters to use in forwarding this bundle, 1233 then forwarding is contraindicated. 1235 Step 3: If forwarding of the bundle is determined to be 1236 contraindicated for any of the reasons listed in Figure 12, then 1237 the Forwarding Contraindicated procedure defined in Section 5.4.1 1238 must be followed; the remaining steps of Section 5 are skipped at 1239 this time. 1241 Step 4: If the bundle's custody transfer requested flag (in the 1242 bundle processing flags field) is set to 1 then the custody 1243 transfer procedure defined in Section 5.10.2 must be followed. 1245 Step 5: For each endpoint selected for forwarding, the bundle 1246 protocol agent must invoke the services of the selected 1247 convergence layer adapter(s) in order to effect the sending of the 1248 bundle to the nodes constituting the minimum reception group of 1249 that endpoint. Determining the time at which the bundle is to be 1250 sent by each convergence layer adapter is an implementation 1251 matter. 1253 To keep from possibly invalidating bundle security, the sequencing 1254 of the blocks in a forwarded bundle must not be changed as it 1255 transits a node; received blocks must be transmitted in the same 1256 relative order as that in which they were received. While blocks 1257 may be added to bundles as they transit intermeditate nodes, 1258 removal of blocks that do not have their 'Discard block if it 1259 can't be processed' flag in the block processing control flags set 1260 to 1 may cause security to fail. 1262 Step 6: When all selected convergence layer adapters have informed 1263 the bundle protocol agent that they have concluded their data 1264 sending procedures with regard to this bundle: 1266 * If the "request reporting of bundle forwarding" flag in the 1267 bundle's status report request field is set to 1, then a bundle 1268 forwarding status report should be generated, destined for the 1269 bundle's report-to endpoint ID. If the bundle has the 1270 retention constraint "custody accepted" and all of the nodes in 1271 the minimum reception group of the endpoint selected for 1272 forwarding are known to be unable to send bundles back to this 1273 node, then the reason code on this bundle forwarding status 1274 report must be "forwarded over unidirectional link"; otherwise 1275 the reason code must be "no additional information". 1277 * The bundle's "Forward pending" retention constraint must be 1278 removed. 1280 5.4.1. Forwarding Contraindicated 1282 The steps in responding to contraindication of forwarding for some 1283 reason are: 1285 Step 1: The bundle protocol agent must determine whether or not to 1286 declare failure in forwarding the bundle for this reason. Note: 1287 this decision is likely to be influenced by the reason for which 1288 forwarding is contraindicated. 1290 Step 2: If forwarding failure is declared, then the Forwarding 1291 Failed procedure defined in 4.4.2 must be followed. Otherwise, 1292 (a) if the bundle's custody transfer requested flag (in the bundle 1293 processing flags field) is set to 1 then the custody transfer 1294 procedure defined in Section 5.10 must be followed; (b) when - at 1295 some future time - the forwarding of this bundle ceases to be 1296 contraindicated, processing proceeds from Step 5 of Section 5.4. 1298 5.4.2. Forwarding Failed 1300 The steps in responding to a declaration of forwarding failure for 1301 some reason are: 1303 Step 1: If the bundle's custody transfer requested flag (in the 1304 bundle processing flags field) is set to 1, custody transfer 1305 failure must be handled. Procedures for handling failure of 1306 custody transfer for a bundle whose destination is not a singleton 1307 endpoint are not defined in this specification. For a bundle 1308 whose destination is a singleton endpoint, the bundle protocol 1309 agent must handle the custody transfer failure by generating a 1310 "Failed" custody signal for the bundle, destined for the bundle's 1311 current custodian; the custody signal must contain a reason code 1312 corresponding to the reason for which forwarding was determined to 1313 be contraindicated. (Note that discarding the bundle will not 1314 delete it from the network, since the current custodian still has 1315 a copy.) 1317 Step 2: If the bundle's destination endpoint is an endpoint of 1318 which the node is a member, then the bundle's "Forward pending" 1319 retention constraint must be removed. Otherwise the bundle must 1320 be deleted: the bundle deletion procedure defined in 4.13 must be 1321 followed, citing the reason for which forwarding was determined to 1322 be contraindicated. 1324 5.5. Bundle Expiration 1326 A bundle expires when the current time is greater than the bundle's 1327 creation time plus its lifetime as specified in the primary bundle 1328 block. Bundle expiration may occur at any point in the processing of 1329 a bundle. When a bundle expires, the bundle protocol agent must 1330 delete the bundle for the reason "lifetime expired": the bundle 1331 deletion procedure defined in Section 5.13 must be followed. 1333 5.6. Bundle Reception 1335 The steps in processing a bundle received from another node are: 1337 Step 1: The retention constraint "Dispatch pending" must be added 1338 to the bundle. 1340 Step 2: If the "request reporting of bundle reception" flag in the 1341 bundle's status report request field is set to 1, then a bundle 1342 reception status report with reason code "No additional 1343 information" should be generated, destined for the bundle's 1344 report-to endpoint ID. 1346 Step 3: For each block in the bundle that is an extension block 1347 that the bundle protocol agent cannot process: 1349 * If the block processing flags in that block indicate that a 1350 status report is requested in this event, then a bundle 1351 reception status report with reason code "Block unintelligible" 1352 should be generated, destined for the bundle's report-to 1353 endpoint ID. 1355 * If the block processing flags in that block indicate that the 1356 bundle must be deleted in this event, then the bundle protocol 1357 agent must delete the bundle for the reason "Block 1358 unintelligible"; the bundle deletion procedure defined in 4.13 1359 must be followed and all remaining steps of the bundle 1360 reception procedure must be skipped. 1362 * If the block processing flags in that block do NOT indicate 1363 that the bundle must be deleted in this event but do indicate 1364 that the block must be discarded, then the bundle protocol 1365 agent must remove this block from the bundle. 1367 * If the block processing flags in that block indicate NEITHER 1368 that the bundle must be deleted NOR that the block must be 1369 discarded, then the bundle protocol agent must set to 1 the 1370 "Block was forwarded without being processed" flag in the block 1371 processing flags of the block. 1373 Step 4: If the bundle's custody transfer requested flag (in the 1374 bundle processing flags field) is set to 1 and the bundle has the 1375 same source endpoint ID, creation timestamp, and (if the bundle is 1376 a fragment) fragment offset and payload length as another bundle 1377 that (a) has not been discarded and (b) currently has the 1378 retention constraint "Custody accepted", custody transfer 1379 redundancy must be handled; otherwise, processing proceeds from 1380 Step 5. Procedures for handling redundancy in custody transfer 1381 for a bundle whose destination is not a singleton endpoint are not 1382 defined in this specification. For a bundle whose destination is 1383 a singleton endpoint, the bundle protocol agent must handle 1384 custody transfer redundancy by generating a "Failed" custody 1385 signal for this bundle with reason code "Redundant reception", 1386 destined for this bundle's current custodian, and removing this 1387 bundle's "Dispatch pending" retention constraint. 1389 Step 5: Processing proceeds from Step 1 of Section 5.3. 1391 5.7. Local Bundle Delivery 1393 The steps in processing a bundle that is destined for an endpoint of 1394 which this node is a member are: 1396 Step 1: If the received bundle is a fragment, the application data 1397 unit reassembly procedure described in Section 5.9 must be 1398 followed. If this procedure results in reassembly of the entire 1399 original application data unit, processing of this bundle (whose 1400 fragmentary payload has been replaced by the reassembled 1401 application data unit) proceeds from Step 2; otherwise the 1402 retention constraint "Reassembly pending" must be added to the 1403 bundle and all remaining steps of this procedure are skipped. 1405 Step 2: Delivery depends on the state of the registration whose 1406 endpoint ID matches that of the destination of the bundle: 1408 * If the registration is in the Active state, then the bundle 1409 must be delivered subject to this registration (see Section 3.1 1410 above) as soon as all previously received bundles that are 1411 deliverable subject to this registration have been delivered. 1413 * If the registration is in the Passive state, then the 1414 registration's delivery failure action must be taken (see 1415 Section 3.1 above). 1417 Step 3: As soon as the bundle has been delivered: 1419 * If the "request reporting of bundle delivery" flag in the 1420 bundle's status report request field is set to 1, then a bundle 1421 delivery status report should be generated, destined for the 1422 bundle's report-to endpoint ID. Note that this status report 1423 only states that the payload has been delivered to the 1424 application agent, not that the application agent has processed 1425 that payload. 1427 * If the bundle's custody transfer requested flag (in the bundle 1428 processing flags field) is set to 1, custodial delivery must be 1429 reported. Procedures for reporting custodial delivery for a 1430 bundle whose destination is not a singleton endpoint are not 1431 defined in this specification. For a bundle whose destination 1432 is a singleton endpoint, the bundle protocol agent must report 1433 custodial delivery by generating a "Succeeded" custody signal 1434 for the bundle, destined for the bundle's current custodian. 1436 5.8. Bundle Fragmentation 1438 It may at times be necessary for bundle protocol agents to reduce the 1439 sizes of bundles in order to forward them. This might be the case, 1440 for example, if the endpoint to which a bundle is to be forwarded is 1441 accessible only via intermittent contacts and no upcoming contact is 1442 long enough to enable the forwarding of the entire bundle. 1444 The size of a bundle can be reduced by "fragmenting" the bundle. To 1445 fragment a bundle whose payload is of size M is to replace it with 1446 two "fragments" - new bundles with the same source endpoint ID and 1447 creation timestamp as the original bundle - whose payloads are the 1448 first N and the last (M - N) bytes of the original bundle's payload, 1449 where 0 < N < M. Note that fragments may themselves be fragmented, so 1450 fragmentation may in effect replace the original bundle with more 1451 than two fragments. (However, there is only one 'level' of 1452 fragmentation, as in IP fragmentation.) 1454 Any bundle whose primary block's bundle processing flags do NOT 1455 indicate that it must not be fragmented may be fragmented at any 1456 time, for any purpose, at the discretion of the bundle protocol 1457 agent. 1459 Fragmentation shall be constrained as follows: 1461 o The concatenation of the payloads of all fragments produced by 1462 fragmentation must always be identical to the payload of the 1463 bundle that was fragmented. Note that the payloads of fragments 1464 resulting from different fragmentation episodes, in different 1465 parts of the network, may be overlapping subsets of the original 1466 bundle's payload. 1468 o The bundle processing flags in the primary block of each fragment 1469 must be modified to indicate that the bundle is a fragment, and 1470 both fragment offset and total application data unit length must 1471 be provided at the end of each fragment's primary bundle block. 1473 o The primary blocks of the fragments will differ from that of the 1474 fragmented bundle as noted above. 1476 o The payload blocks of fragments will differ from that of the 1477 fragmented bundle as noted above. 1479 o All blocks that precede the payload block at the time of 1480 fragmentation must be replicated in the fragment with the lowest 1481 offset. 1483 o All blocks that follow the payload block at the time of 1484 fragmentation must be replicated in the fragment with the highest 1485 offset. 1487 o If the 'Block must be replicated in every fragment' bit is set to 1488 one then the block must be replicated in every fragment. 1490 o If the 'Block must be replicated in every fragment' bit is set to 1491 zero, the block should be replicated in only one fragment. 1493 o The relative order of all blocks that are present in a fragment 1494 must be the same as in the bundle prior to fragmentation. 1496 5.9. Application Data Unit Reassembly 1498 If the concatenation - as informed by fragment offsets and payload 1499 lengths - of the payloads of all previously received fragments with 1500 the same source endpoint ID and creation timestamp as this fragment, 1501 together with the payload of this fragment, forms a byte array whose 1502 length is equal to the total application data unit length in the 1503 fragment's primary block, then: 1505 o This byte array - the reassembled application data unit - must 1506 replace the payload of this fragment. 1508 o The "Reassembly pending" retention constraint must be removed from 1509 every other fragment whose payload is a subset of the reassembled 1510 application data unit. 1512 Note: reassembly of application data units from fragments occurs at 1513 destination endpoints as necessary; an application data unit may also 1514 be reassembled at some other endpoint on the route to the 1515 destination. 1517 5.10. Custody Transfer 1519 The conditions under which a node may accept custody of a bundle 1520 whose destination is not a singleton endpoint are not defined in this 1521 specification. 1523 The decision as to whether or not to accept custody of a bundle whose 1524 destination is a singleton endpoint is an implementation matter which 1525 may involve both resource and policy considerations; however, if the 1526 bundle protocol agent has committed to accepting custody of the 1527 bundle (as described in Step 1 of Section 5.2) then custody must be 1528 accepted. 1530 If the bundle protocol agent elects to accept custody of the bundle, 1531 then it must follow the custody acceptance procedure defined in 1532 Section 5.10.1. 1534 5.10.1. Custody Acceptance 1536 Procedures for acceptance of custody of a bundle whose destination is 1537 not a singleton endpoint are not defined in this specification. 1539 Procedures for acceptance of custody of a bundle whose destination is 1540 a singleton endpoint are defined as follows. 1542 The retention constraint "Custody accepted" must be added to the 1543 bundle. 1545 If the "request custody acceptance reporting" flag in the bundle's 1546 status report request field is set to 1, a custody acceptance status 1547 report should be generated, destined for the report-to endpoint ID of 1548 the bundle. However, if a bundle reception status report was 1549 generated for this bundle (step 1 of Section 5.6) then this report 1550 should be generated by simply turning on the "Reporting node accepted 1551 custody of bundle" flag in that earlier report's status flags byte. 1553 The bundle protocol agent must generate a "Succeeded" custody signal 1554 for the bundle, destined for the bundle's current custodian. 1556 The bundle protocol agent must assert the new current custodian for 1557 the bundle. It does so by changing the current custodian endpoint ID 1558 in the bundle's primary block to the endpoint ID of one of the 1559 singleton endpoints in which the node is registered. This may entail 1560 appending that endpoint ID's null-terminated scheme name and SSP to 1561 the dictionary byte array in the bundle's primary block, and in some 1562 case it may also enable the (optional) removal of the current 1563 custodian endpoint ID's scheme name and/or SSP from the dictionary. 1565 The bundle protocol agent may set a custody transfer countdown timer 1566 for this bundle; upon expiration of this timer prior to expiration of 1567 the bundle itself and prior to custody transfer success for this 1568 bundle, the custody transfer failure procedure detailed in section 1569 Section 5.12 must be followed. The manner in which the countdown 1570 interval for such a timer is determined is an implementation matter. 1572 The bundle should be retained in persistent storage if possible. 1574 5.10.2. Custody Release 1576 Procedures for release of custody of a bundle whose destination is 1577 not a singleton endpoint are not defined in this specification. 1579 When custody of a bundle is released, where the destination of the 1580 bundle is a singleton endpoint, the "Custody accepted" retention 1581 constraint must be removed from the bundle and any custody transfer 1582 timer that has been established for this bundle must be destroyed. 1584 5.11. Custody Transfer Success 1586 Procedures for determining custody transfer success for a bundle 1587 whose destination is not a singleton endpoint are not defined in this 1588 specification. 1590 Upon receipt of a "Succeeded" custody signal at a node that is a 1591 custodial node of the bundle identified in the custody signal, where 1592 the destination of the bundle is a singleton endpoint, custody of the 1593 bundle must be released as described in Section 5.10.2. 1595 5.12. Custody Transfer Failure 1597 Procedures for determining custody transfer failure for a bundle 1598 whose destination is not a singleton endpoint are not defined in this 1599 specification. Custody transfer for a bundle whose destination is a 1600 singleton endpoint is determined to have failed at a custodial node 1601 for that bundle when either (a) that node's custody transfer timer 1602 for that bundle (if any) expires or (b) a "Failed" custody signal for 1603 that bundle is received at that node. 1605 Upon determination of custody transfer failure, the action taken by 1606 the bundle protocol agent is implementation-specific and may depend 1607 on the nature of the failure. For example, if custody transfer 1608 failure was inferred from expiration of a custody transfer timer or 1609 was asserted by a "Failed" custody signal with the "Depleted storage" 1610 reason code, the bundle protocol agent might choose to re-forward the 1611 bundle, possibly on a different route (Section 5.4). Receipt of a 1612 "Failed" custody signal with the "Redundant reception" reason code, 1613 on the other hand, might cause the bundle protocol agent to release 1614 custody of the bundle and to revise its algorithm for computing 1615 countdown intervals for custody transfer timers. 1617 5.13. Bundle Deletion 1619 The steps in deleting a bundle are: 1621 Step 1: If the retention constraint "Custody accepted" currently 1622 prevents this bundle from being discarded, and the destination of 1623 the bundle is a singleton endpoint, then: 1625 * Custody of the node is released as described in Section 5.10.2. 1627 * A bundle deletion status report citing the reason for deletion 1628 must be generated, destined for the bundle's report-to endpoint 1629 ID. 1631 Otherwise, if the "request reporting of bundle deletion" flag in 1632 the bundle's status report request field is set to 1, then a 1633 bundle deletion status report citing the reason for deletion 1634 should be generated, destined for the bundle's report-to endpoint 1635 ID. 1637 Step 2: All of the bundle's retention constraints must be removed. 1639 5.14. Discarding a Bundle 1641 As soon as a bundle has no remaining retention constraints it may be 1642 discarded. 1644 5.15. Canceling a Transmission 1646 When requested to cancel a specified transmission, where the bundle 1647 created upon initiation of the indicated transmission has not yet 1648 been discarded, the bundle protocol agent must delete that bundle for 1649 the reason "transmission canceled". For this purpose, the procedure 1650 defined in Section 5.13 must be followed. 1652 5.16. Polling 1654 When requested to poll a specified registration that is in Passive 1655 state, the bundle protocol agent must immediately deliver the least 1656 recently received bundle that is deliverable subject to the indicated 1657 registration, if any. 1659 6. Administrative Record Processing 1661 6.1. Administrative Records 1663 Administrative records are standard application data units that are 1664 used in providing some of the features of the Bundle Protocol. Two 1665 types of administrative records have been defined to date: bundle 1666 status reports and custody signals. 1668 Every administrative record consists of a four-bit record type code 1669 followed by four bits of administrative record flags, followed by 1670 record content in type-specific format. Record type codes are 1671 defined as follows: 1673 +---------+--------------------------------------------+ 1674 | Value | Meaning | 1675 +=========+============================================+ 1676 | 0001 | Bundle status report. | 1677 +---------+--------------------------------------------+ 1678 | 0010 | Custody signal. | 1679 +---------+--------------------------------------------+ 1680 | (other) | Reserved for future use. | 1681 +---------+--------------------------------------------+ 1683 Figure 8: Administrative Record Type Codes. 1685 +---------+--------------------------------------------+ 1686 | Value | Meaning | 1687 +=========+============================================+ 1688 | 0001 | Record is for a fragment; fragment | 1689 | | offset and length fields are present. | 1690 +---------+--------------------------------------------+ 1691 | (other) | Reserved for future use. | 1692 +---------+--------------------------------------------+ 1694 Figure 9: Administrative Record Flags. 1696 All time values in administrative records are UTC times expressed in 1697 "DTN time" representation. A DTN time consists of an SDNV indicating 1698 the number of seconds since the start of the year 2000, followed by 1699 an SDNV indicating the number of nanoseconds since the start of the 1700 indicated second. 1702 The contents of the various types of administrative records are 1703 described below. 1705 6.1.1. Bundle Status Reports 1707 The transmission of 'bundle status reports' under specified 1708 conditions is an option that can be invoked when transmission of a 1709 bundle is requested. These reports are intended to provide 1710 information about how bundles are progressing through the system, 1711 including notices of receipt, custody transfer, forwarding, final 1712 delivery, and deletion. They are transmitted to the Report-to 1713 endpoints of bundles. 1715 +----------------+----------------+----------------+----------------+ 1716 | Status Flags | Reason code | Fragment offset (*) (if 1717 +----------------+----------------+----------------+----------------+ 1718 present) | Fragment length (*) (if present) | 1719 +----------------+----------------+----------------+----------------+ 1720 | Time of receipt of bundle X (a DTN time, if present) | 1721 +----------------+----------------+----------------+----------------+ 1722 | Time of custody acceptance of bundle X (a DTN time, if present) | 1723 +----------------+----------------+----------------+----------------+ 1724 | Time of forwarding of bundle X (a DTN time, if present) | 1725 +----------------+----------------+----------------+----------------+ 1726 | Time of delivery of bundle X (a DTN time, if present) | 1727 +----------------+----------------+----------------+----------------+ 1728 | Time of deletion of bundle X (a DTN time, if present) | 1729 +----------------+----------------+----------------+----------------+ 1730 | Copy of bundle X's Creation Timestamp time (*) | 1731 +----------------+----------------+----------------+----------------+ 1732 | Copy of bundle X's Creation Timestamp sequence number (*) | 1733 +----------------+----------------+----------------+----------------+ 1734 | Length of X's source endpoint ID (*) | Source 1735 +----------------+---------------------------------+ + 1736 endpoint ID of bundle X (variable) | 1737 +----------------+----------------+----------------+----------------+ 1739 Figure 10: Bundle status report format 1741 (*) Notes: 1743 The Fragment Offset field, if present, is an SDNV and is therefore 1744 variable-length. A three-octet SDNV is shown here for convenience in 1745 representation. 1747 The Fragment Length field, if present, is an SDNV and is therefore 1748 variable-length. A three-octet SDNV is shown here for convenience in 1749 representation. 1751 The Creation Timestamp fields replicate the Creation Timestamp fields 1752 in the primary block of the subject bundle. As such they are SDNVs 1753 (see 3.5.1 above) and are therefore variable-length. Four-octet 1754 SDNVs are shown here for convenience in representation. 1756 The source endpoint ID length field is an SDNV and is therefore 1757 variable-length. A three-octet SDNV is shown here for convenience in 1758 representation. 1760 The fields in a bundle status report are: 1762 Status Flags: A 1-byte field containing the following flags: 1764 +----------+--------------------------------------------+ 1765 | Value | Meaning | 1766 +==========+============================================+ 1767 | 00000001 | Reporting node received bundle. | 1768 +----------+--------------------------------------------+ 1769 | 00000010 | Reporting node accepted custody of bundle.| 1770 +----------+--------------------------------------------+ 1771 | 00000100 | Reporting node forwarded the bundle. | 1772 +----------+--------------------------------------------+ 1773 | 00001000 | Reporting node delivered the bundle. | 1774 +----------+--------------------------------------------+ 1775 | 00010000 | Reporting node deleted the bundle. | 1776 +----------+--------------------------------------------+ 1777 | 00100000 | Unused. | 1778 +----------+--------------------------------------------+ 1779 | 01000000 | Unused. | 1780 +----------+--------------------------------------------+ 1781 | 10000000 | Unused. | 1782 +----------+--------------------------------------------+ 1784 Figure 11: Status Flags for Bundle Status Reports 1786 Reason Code: A 1-byte field explaining the value of the flags in 1787 the status flags byte. The list of status report reason codes 1788 provided here is neither exhaustive nor exclusive; supplementary 1789 DTN protocol specifications (including, but not restricted to, the 1790 Bundle Security Protocol [BSP]) may define additional reason 1791 codes. Status report reason codes are defined as follows: 1793 +---------+--------------------------------------------+ 1794 | Value | Meaning | 1795 +=========+============================================+ 1796 | 0x00 | No additional information. | 1797 +---------+--------------------------------------------+ 1798 | 0x01 | Lifetime expired. | 1799 +---------+--------------------------------------------+ 1800 | 0x02 | Forwarded over unidirectional link. | 1801 +---------+--------------------------------------------+ 1802 | 0x03 | Transmission canceled. | 1803 +---------+--------------------------------------------+ 1804 | 0x04 | Depleted storage. | 1805 +---------+--------------------------------------------+ 1806 | 0x05 | Destination endpoint ID unintelligible. | 1807 +---------+--------------------------------------------+ 1808 | 0x06 | No known route to destination from here. | 1809 +---------+--------------------------------------------+ 1810 | 0x07 | No timely contact with next node on route.| 1811 +---------+--------------------------------------------+ 1812 | 0x08 | Block unintelligible. | 1813 +---------+--------------------------------------------+ 1814 | (other) | Reserved for future use. | 1815 +---------+--------------------------------------------+ 1817 Figure 12: Status Report Reason Codes 1819 Fragment Offset: If the bundle fragment bit is set in the status 1820 flags, then the offset (within the original application data unit) 1821 of the payload of the bundle that caused the status report to be 1822 generated is included here. 1824 Fragment length: If the bundle fragment bit is set in the status 1825 flags, then the length of the payload of the subject bundle is 1826 included here. 1828 Time of Receipt (if present): If the bundle-received bit is set in 1829 the status flags, then a DTN time indicating the time at which the 1830 bundle was received at the reporting node is included here. 1832 Time of Custody Acceptance (if present): If the custody-accepted 1833 bit is set in the status flags, then a DTN time indicating the 1834 time at which custody was accepted at the reporting node is 1835 included here. 1837 Time of Forward (if present): If the bundle-forwarded bit is set in 1838 the status flags, then a DTN time indicating the time at which the 1839 bundle was first forwarded at the reporting node is included here. 1841 Time of Delivery (if present): If the bundle-delivered bit is set 1842 in the status flags, then a DTN time indicating the time at which 1843 the bundle was delivered at the reporting node is included here. 1845 Time of Deletion (if present): If the bundle-deleted bit is set in 1846 the status flags, then a DTN time indicating the time at which the 1847 bundle was deleted at the reporting node is included here. 1849 Creation Timestamp of Subject Bundle: A copy of the creation 1850 timestamp of the bundle that caused the status report to be 1851 generated. 1853 Length of Source Endpoint ID: The length in bytes of the source 1854 endpoint ID of the bundle that caused the status report to be 1855 generated. 1857 Source Endpoint ID text: The text of the source endpoint ID of the 1858 bundle that caused the status report to be generated. 1860 6.1.2. Custody Signals 1862 Custody signals are administrative records that effect custody 1863 transfer operations. They are transmitted to the endpoints that are 1864 the current custodians of bundles. 1866 Custody signals have the following format. 1868 Custody Signal regarding bundle 'X': 1870 +----------------+----------------+----------------+----------------+ 1871 | Status | Fragment offset (*) (if present) | 1872 +----------------+----------------+----------------+----------------+ 1873 | Fragment length (*) (if present) | 1874 +----------------+----------------+----------------+----------------+ 1875 | Time of signal (a DTN time) | 1876 +----------------+----------------+----------------+----------------+ 1877 | Copy of bundle X's Creation Timestamp time (*) | 1878 +----------------+----------------+----------------+----------------+ 1879 | Copy of bundle X's Creation Timestamp sequence number (*) | 1880 +----------------+----------------+----------------+----------------+ 1881 | Length of X's source endpoint ID (*) | Source 1882 +----------------+---------------------------------+ + 1883 endpoint ID of bundle X (variable) | 1884 +----------------+----------------+----------------+----------------+ 1886 Figure 13: Custody signal format. 1888 (*) Notes: 1890 The Fragment Offset field, if present, is an SDNV and is therefore 1891 variable-length. A three-octet SDNV is shown here for convenience in 1892 representation. 1894 The Fragment Length field, if present, is an SDNV and is therefore 1895 variable-length. A four-octet SDNV is shown here for convenience in 1896 representation. 1898 The Creation Timestamp fields replicate the Creation Timestamp fields 1899 in the primary block of the subject bundle. As such they are SDNVs 1900 (see Section 4.5.1 above) and are therefore variable-length. Four- 1901 octet SDNVs are shown here for convenience in representation. 1903 The source endpoint ID length field is an SDNV and is therefore 1904 variable-length. A three-octet SDNV is shown here for convenience in 1905 representation. 1907 The fields in a custody signal are: 1909 Status: A 1-byte field containing a 1-bit "custody transfer 1910 succeeded" flag followed by a 7-bit reason code explaining the 1911 value of that flag. Custody signal reason codes are defined as 1912 follows: 1914 +---------+--------------------------------------------+ 1915 | Value | Meaning | 1916 +=========+============================================+ 1917 | 0x00 | No additional information. | 1918 +---------+--------------------------------------------+ 1919 | 0x01 | Reserved for future use. | 1920 +---------+--------------------------------------------+ 1921 | 0x02 | Reserved for future use. | 1922 +---------+--------------------------------------------+ 1923 | 0x03 | Redundant reception (reception by a node | 1924 | | that is a custodial node for this bundle).| 1925 +---------+--------------------------------------------+ 1926 | 0x04 | Depleted storage. | 1927 +---------+--------------------------------------------+ 1928 | 0x05 | Destination endpoint ID unintelligible. | 1929 +---------+--------------------------------------------+ 1930 | 0x06 | No known route to destination from here. | 1931 +---------+--------------------------------------------+ 1932 | 0x07 | No timely contact with next node on route.| 1933 +---------+--------------------------------------------+ 1934 | 0x08 | Block unintelligible. | 1935 +---------+--------------------------------------------+ 1936 | (other) | Reserved for future use. | 1937 +---------+--------------------------------------------+ 1939 Figure 14: Custody Signal Reason Codes 1941 Fragment offset: If the bundle fragment bit is set in the status 1942 flags, then the offset (within the original application data unit) 1943 of the payload of the bundle that caused the status report to be 1944 generated is included here. 1946 Fragment length: If the bundle fragment bit is set in the status 1947 flags, then the length of the payload of the subject bundle is 1948 included here. 1950 Time of Signal: A DTN time indicating the time at which the signal 1951 was generated. 1953 Creation Timestamp of Subject Bundle: A copy of the creation 1954 timestamp of the bundle to which the signal applies. 1956 Length of Source Endpoint ID: The length in bytes of the source 1957 endpoint ID of the bundle to which the signal applied. 1959 Source Endpoint ID text: The text of the source endpoint ID of the 1960 bundle to which the signal applies. 1962 6.2. Generation of Administrative Records 1964 Whenever the application agent's administrative element is directed 1965 by the bundle protocol agent to generate an administrative record 1966 with reference to some bundle, the following procedure must be 1967 followed: 1969 Step 1: The administrative record must be constructed. If the 1970 referenced bundle is a fragment, the administrative record must 1971 have the Fragment flag set and must contain the fragment offset 1972 and fragment length fields; the value of the fragment offset field 1973 must be the value of the referenced bundle's fragment offset, and 1974 the value of the fragment length field must be the length of the 1975 referenced bundle's payload. 1977 Step 2: A request for transmission of a bundle whose payload is 1978 this administrative record must be presented to the bundle 1979 protocol agent. 1981 6.3. Reception of Custody Signals 1983 For each received custody signal that has the Custody Transfer 1984 Succeeded flag set to 1, the administrative element of the 1985 application agent must direct the bundle protocol agent to follow the 1986 custody transfer success procedure in Section 5.11. 1988 For each received custody signal that has the Custody Transfer 1989 Succeeded flag set to 0, the administrative element of the 1990 application agent must direct the bundle protocol agent to follow the 1991 custody transfer failure procedure in Section 5.12. 1993 7. Services Required of the Convergence Layer 1995 7.1. The Convergence Layer 1997 The successful operation of the end-to-end bundle protocol depends on 1998 the operation of underlying protocols at what is termed the 1999 "convergence layer"; these protocols accomplish communication between 2000 nodes. A wide variety of protocols may serve this purpose, so long 2001 as each convergence layer protocol adapter provides a defined minimal 2002 set of services to the bundle protocol agent. This convergence layer 2003 service specification enumerates those services. 2005 7.2. Summary of Convergence Layer Services 2007 Each convergence layer protocol adapter is expected to provide the 2008 following services to the bundle protocol agent: 2010 o sending a bundle to all bundle nodes in the minimum reception 2011 group of the endpoint identified by a specified endpoint ID that 2012 are reachable via the convergence layer protocol; 2014 o delivering to the bundle protocol agent a bundle that was sent by 2015 a remote bundle node via the convergence layer protocol. 2017 The convergence layer service interface specified here is neither 2018 exhaustive nor exclusive. That is, supplementary DTN protocol 2019 specifications (including, but not restricted to, the Bundle Security 2020 Protocol [BSP]) may expect convergence layer adapters which serve BP 2021 implementations conforming to those protocols to provide additional 2022 services. 2024 8. Security Considerations 2026 The bundle protocol has taken security into concern from the outset 2027 of its design. It was always assumed that security services would be 2028 needed in the use of the bundle protocol. As a result, the bundle 2029 protocol security architecture and the available security services 2030 are specified in an accompanying document, the Bundle Security 2031 Protocol specification [BSP]; an informative overview of this 2032 architecture is provided in [SECO]. 2034 The bundle protocol has been designed with the notion that it will be 2035 run over networks with scarce resources. For example, the networks 2036 might have limited bandwidth, limited connectivity, constrained 2037 storage in relay nodes, etc. Therefore, the bundle protocol must 2038 ensure that only those entities authorized to send bundles over such 2039 constrained environments are actually allowed to do so. All 2040 unauthorized entities should be prevented from consuming valuable 2041 resources. 2043 Likewise, because of the potentially long latencies and delays 2044 involved in the networks that make use of the bundle protocol, data 2045 sources should be concerned with the integrity of the data received 2046 at the intended destination(s) and may also be concerned with 2047 ensuring confidentiality of the data as it traverses the network. 2048 Without integrity, the bundle payload data might be corrupted while 2049 in transit without the destination able to detect it. Similarly, the 2050 data source can be concerned with ensuring that the data can only be 2051 used by those authorized; hence the need for confidentiality. 2053 Internal to the bundle-aware overlay network, the bundle nodes should 2054 be concerned with the authenticity of other bundle nodes as well as 2055 the preservation of bundle payload data integrity as it is forwarded 2056 between bundle nodes. 2058 As a result, bundle security is concerned with the authenticity, 2059 integrity, and confidentiality of bundles conveyed among bundle 2060 nodes. This is accomplished via the use of three, independent 2061 security specific bundle blocks which may be used together to provide 2062 multiple bundle security services or independently of one another, 2063 depending on perceived security threats, mandated security 2064 requirements, and security policies that must be enforced. 2066 The Bundle Authentication Block (BAB) ensures the authenticity and 2067 integrity of bundles on a hop-by-hop basis between bundle nodes. The 2068 BAB allows each bundle node to verify a bundle's authenticity before 2069 processing or forwarding the bundle. In this way, entities that are 2070 not authorized to send bundles will have unauthorized transmissions 2071 blocked by security-aware bundle nodes. 2073 Additionally, to provide "security-source" to "security-destination" 2074 bundle authenticity and integrity, the Payload Security Block (PSB) 2075 is used. A "security-source" may not actually be the origination 2076 point of the bundle but instead may be the first point along the path 2077 that is security-aware and is able to apply security services. For 2078 example, an enclave of networked systems may generate bundles but 2079 only their gateway may be required and/or able to apply security 2080 services. The PSB allows any security-enabled entity along the 2081 delivery path, in addition to the "security-destination" (the 2082 recipient counterpart to the "security-source"), to ensure the 2083 bundle's authenticity. 2085 Finally, to provide payload confidentiality, the use of the 2086 Confidentiality Block (CB) is available. The bundle payload may be 2087 encrypted to provide "security-source" to "security-destination" 2088 payload confidentiality/privacy. The CB indicates the cryptographic 2089 algorithm and key IDs that were used to encrypt the payload. 2091 Note that removal of strings from the dictionary at a given point in 2092 a bundle's end-to-end path, and attendant adjustment of endpoint ID 2093 references in the blocks of that bundle, may make it necessary to re- 2094 compute values in one or more of the bundle's security blocks. 2096 Bundle security must not be invalidated by forwarding nodes even 2097 though they themselves might not use the Bundle Security Protocol. 2098 In particular, the sequencing of the blocks in a forwarded bundle 2099 must not be changed as it transits a node; received blocks must be 2100 transmitted in the same relative order as that in which they were 2101 received. While blocks may be added to bundles as they transit 2102 intermeditate nodes, removal of blocks that do not have their 2103 'Discard block if it can't be processed' flag in the block processing 2104 control flags set to 1 may cause security to fail. 2106 Inclusion of the Bundle Security Protocol in any Bundle Protocol 2107 implementation is RECOMMENDED. Use of the Bundle Security Protocol 2108 in Bundle Protocol operations is OPTIONAL. 2110 9. IANA Considerations 2112 The new Uniform Resource Identifier scheme "dtn", defined by the 2113 Bundle Protocol, will need to be documented. 2115 10. References 2117 10.1. Normative References 2119 [IPR] Bradner, S., "Intellectual Property Rights in IETF 2120 Technology", RFC 3979, BCP 79, March 2005. 2122 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2123 Requirement Levels", BCP 14, RFC 2119, March 1997. 2125 [RGTS] Bradner, S., "IETF Rights in Contributions", RFC 3978, 2126 BCP 78, March 2005. 2128 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2129 Resource Identifier (URI): Generic Syntax", RFC 3986, 2130 STD 66, January 2005. 2132 [URIREG] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 2133 Registration Procedures for New URI Schemes", RFC 4395, 2134 BCP 115, February 2006. 2136 10.2. Informative References 2138 [ARCH] V. Cerf et. al., "Delay-Tolerant Network Architecture", 2139 RFC 4838, April 2007. 2141 [ASN1] "Abstract Syntax Notation One (ASN.1), "ASN.1 Encoding 2142 Rules: Specification of Basic Encoding Rules (BER), 2143 Canonical Encoding Rules (CER) and Distinguished Encoding 2144 Rules (DER)," ITU-T Rec. X.690 (2002) | ISO/IEC 8825- 2145 1:2002", 2003. 2147 [BSP] Symington, S., "Bundle Security Protocol Specification, 2148 work in progress", Work in 2149 progress, draft-irtf-dtnrg-bundle-security-02, 2150 October 2006. 2152 [NTP] Mills, D., "Network Time Protocol (Version 3) 2153 Specification", RFC 1305, March 1992. 2155 [SECO] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant 2156 Networking Security Overview", Work in 2157 progress, draft-irtf-dtnrg-sec-overview-02, October 2006. 2159 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 2160 Challenged Internets", SIGCOMM 2003 . 2162 [TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A 2163 Tutorial", . 2165 [UTC] Arias, E. and B. Guinot, ""Coordinated universal time UTC: 2166 historical background and perspectives" in Journees 2167 systemes de reference spatio-temporels", 2004. 2169 Appendix A. Contributors 2171 This was an effort of the delay tolerant networking research group. 2172 The following dtnrg participants contributed significant technical 2173 material and/or inputs: Dr. Vinton Cerf of Google, Scott Burleigh, 2174 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 2175 Michael Demmer of the University of California at Berkeley, Robert 2176 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 2177 Kevin Fall, Stephen Farrell of Trinity College Dublin, Peter Lovell 2178 of SPARTA, Inc., Manikantan Ramadas of Ohio University (most of 2179 Section 4.1), and Howard Weiss of SPARTA, Inc. (text of Section 8) . 2181 Appendix B. Comments 2183 Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay 2184 Tolerant Networking Research Group (DTNRG) web site is located at 2185 http://www.dtnrg.org. 2187 Authors' Addresses 2189 Keith L. Scott 2190 The MITRE Corporation 2191 7515 Colshire Drive 2192 McLean, VA 21102 2193 US 2195 Phone: +1 703 983 6547 2196 Fax: +1 703 983 7142 2197 Email: kscott@mitre.org 2199 Scott Burleigh 2200 NASA Jet Propulsion Laboratory 2201 4800 Oak Grove Dr. 2202 Pasadena, CA 91109-8099 2203 US 2205 Phone: +1 818 393 3353 2206 Fax: +1 818 354 1075 2207 Email: Scott.Burleigh@jpl.nasa.gov 2209 Full Copyright Statement 2211 Copyright (C) The IETF Trust (2007). 2213 This document is subject to the rights, licenses and restrictions 2214 contained in BCP 78, and except as set forth therein, the authors 2215 retain all their rights. 2217 This document and the information contained herein are provided on an 2218 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2219 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2220 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2221 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2222 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2223 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2225 Intellectual Property 2227 The IETF takes no position regarding the validity or scope of any 2228 Intellectual Property Rights or other rights that might be claimed to 2229 pertain to the implementation or use of the technology described in 2230 this document or the extent to which any license under such rights 2231 might or might not be available; nor does it represent that it has 2232 made any independent effort to identify any such rights. Information 2233 on the procedures with respect to rights in RFC documents can be 2234 found in BCP 78 and BCP 79. 2236 Copies of IPR disclosures made to the IETF Secretariat and any 2237 assurances of licenses to be made available, or the result of an 2238 attempt made to obtain a general license or permission for the use of 2239 such proprietary rights by implementers or users of this 2240 specification can be obtained from the IETF on-line IPR repository at 2241 http://www.ietf.org/ipr. 2243 The IETF invites any interested party to bring to its attention any 2244 copyrights, patents or patent applications, or other proprietary 2245 rights that may cover technology that may be required to implement 2246 this standard. Please address the information to the IETF at 2247 ietf-ipr@ietf.org. 2249 Acknowledgment 2251 Funding for the RFC Editor function is provided by the IETF 2252 Administrative Support Activity (IASA).