idnits 2.17.1 draft-irtf-dtnrg-bundle-spec-10.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 2231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2255. 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 (July 3, 2007) is 6143 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'IPR' is defined on line 2126, but no explicit reference was found in the text == Unused Reference: 'RGTS' is defined on line 2132, but no explicit reference was found in the text == Unused Reference: 'NTP' is defined on line 2159, 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-03 -- 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-03 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: January 4, 2008 July 3, 2007 8 Bundle Protocol Specification 9 draft-irtf-dtnrg-bundle-spec-10.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 January 4, 2008. 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 This is an experimental protocol, produced within the IRTF's Delay 143 Tolerant Networking Research Group (DTNRG) and represents the 144 consensus of all of the active contributors to this Group. If this 145 protocol is used on the Internet, IETF standard protocols for 146 security and congestion control should be used. 148 BP's location within the standard protocol stack is as shown in 149 Figure 1. BP uses the "native" internet protocols for communications 150 within a given internet. Note that "internet" in the preceding is 151 used in a general sense and does not necessarily refer to TCP/IP. 152 The interface between the common bundle protocol and a specific 153 internetwork protocol suite is termed a "convergence layer adapter". 154 Figure 1 shows three distinct transport and network protocols 155 (denoted T1/N1, T2,N2, and T3/N3). 157 +-----------+ +-----------+ 158 | BP app | | BP app | 159 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 160 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 161 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 162 | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | 163 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 164 | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | 165 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 166 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 167 +-----------+ +-------------+ +-------------+ +-----------+ 168 | | | | 169 |<--- An internet --->| |<--- An internet --->| 170 | | | | 172 Figure 1: The bundle protocol sits at the application layer of the 173 Internet model. 175 This document describes the format of the protocol data units (called 176 bundles) passed between entities participating in BP communications. 177 The entities are referred to as "bundle nodes". This document does 178 not address: 180 o Operations in the convergence layer adapters that bundle nodes use 181 to transport data through specific types of internet. (However, 182 the document does discuss the services that must be provided by 183 each adapter at the convergence layer.) 185 o The bundle routing algorithm. 187 o Mechanisms for populating the routing or forwarding information 188 bases of bundle nodes. 190 3. Service Description 192 3.1. Definitions 194 Bundle - A bundle is a protocol data unit of the DTN bundle 195 protocol. Each bundle comprises a sequence of two or more 196 "blocks" of protocol data, which serve various purposes. Multiple 197 instances of the same bundle (the same unit of DTN protocol data) 198 might exist concurrently in different parts of a network - 199 possibly in different representations - in the memory local to one 200 or more bundle nodes and/or in transit between nodes. In the 201 context of the operation of a bundle node, a bundle is an instance 202 of some bundle in the network that is in that node's local memory. 204 Bundle payload - A bundle payload (or simply "payload") is the 205 application data whose conveyance to the bundle's destination is 206 the purpose for the transmission of a given bundle. The terms 207 "bundle content", "bundle payload", and "payload" are used 208 interchangeably in this document. The "nominal" payload for a 209 bundle forwarded in response to a bundle transmission request is 210 the application data unit whose location is provided as a 211 parameter to that request. The nominal payload for a bundle 212 forwarded in response to reception of that bundle is the payload 213 of the received bundle. 215 Fragment - A fragment is a bundle whose payload block contains a 216 fragmentary payload. A fragmentary payload is either the first N 217 bytes or the last N bytes of some other payload - either a nominal 218 payload or a fragmentary payload - of length M, such that 0 < N < 219 M. 221 Bundle node - A bundle node (or, in the context of this document, 222 simply a "node") is any entity that can send and/or receive 223 bundles. In the most familiar case a bundle node is instantiated 224 as a single process running on a general-purpose computer, but in 225 general the definition is meant to be broader: a bundle node might 226 alternatively be a thread, an object in an object-oriented 227 operating system, a special-purpose hardware device, etc. Each 228 bundle node has three conceptual components, defined below: a 229 "bundle protocol agent", a set of zero or more "convergence layer 230 adapters", and an "application agent". 232 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 233 the node component that offers the BP services and executes the 234 procedures of the Bundle Protocol. The manner in which it does so 235 is wholly an implementation matter. For example, BPA 236 functionality might be coded into each node individually; it might 237 be implemented as a shared library that is used in common by any 238 number of bundle nodes on a single computer; it might be 239 implemented as a daemon whose services are invoked via inter- 240 process or network communication by any number of bundle nodes on 241 one or more computers; it might be implemented in hardware. 243 Convergence layer adapters - A convergence layer adapter (CLA) sends 244 and receives bundles on behalf of the BPA, utilizing the services 245 of some 'native' internet protocol that is supported in one of the 246 internets within which the node is functionally located. The 247 manner in which a CLA sends and receives bundles is wholly an 248 implementation matter, exactly as described for the BPA. 250 Application agent - The application agent (AA) of a node is the node 251 component that utilizes the BP services to effect communication 252 for some purpose. The application agent in turn has two elements, 253 an administrative element and an application-specific element. 254 The application-specific element of an AA constructs, requests 255 transmission of, accepts delivery of, and processes application- 256 specific application data units; the only interface between the 257 BPA and the application-specific element of the AA is the BP 258 service interface. The administrative element of an AA constructs 259 and requests transmission of administrative records (status 260 reports and custody signals), and it accepts delivery of and 261 processes any custody signals that the node receives. In addition 262 to the BP service interface, there is a (conceptual) private 263 control interface between the BPA and the administrative element 264 of the AA that enables each to direct the other to take action 265 under specific circumstances. In the case of a node that serves 266 simply as a "router" in the overlay network, the AA may have no 267 application-specific element at all. The application-specific 268 elements of other nodes' AAs may perform arbitrarily complex 269 application functions, perhaps even offering multiplexed DTN 270 communication services to a number of other applications. As with 271 the BPA, the manner in which the AA performs its functions is 272 wholly an implementation matter; in particular, the administrative 273 element of an AA might be built into the library or daemon or 274 hardware that implements the BPA, and the application-specific 275 element of an AA might be implemented either in software or in 276 hardware. 278 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 279 of zero or more bundle nodes that all identify themselves for BP 280 purposes by some single text string, called a "bundle endpoint ID" 281 (or, in this document, simply "endpoint ID"; endpoint IDs are 282 described in detail in 3.4 below). The special case of an 283 endpoint that never contains more than one node is termed a 284 "singleton" endpoint; every bundle node must be a member of at 285 least one singleton endpoint. Singletons are the most familiar 286 sort of endpoint, but in general the endpoint notion is meant to 287 be broader. For example, the nodes in a sensor network might 288 constitute a set of bundle nodes that identify themselves by a 289 single common endpoint ID and thus form a single bundle endpoint. 290 **Note** too that a given bundle node might identify itself by 291 multiple endpoint IDs and thus be a member of multiple bundle 292 endpoints. 294 Forwarding - When the bundle protocol agent of a node determines 295 that a bundle must be "forwarded" to an endpoint, it causes the 296 bundle to be sent to all of the nodes that the bundle protocol 297 agent currently believes are in the "minimum reception group" of 298 that endpoint. The minimum reception group of an endpoint may be 299 any one of the following: (a) ALL of the nodes registered in an 300 endpoint that is permitted to contain multiple nodes (in which 301 case forwarding to the endpoint is functionally similar to 302 "multicast" operations in the Internet, though possibly very 303 different in implementation); (b) ANY N of the nodes registered in 304 an endpoint that is permitted to contain multiple nodes, where N 305 is in the range from zero to the cardinality of the endpoint (in 306 which case forwarding to the endpoint is functionally similar to 307 "anycast" operations in the Internet); (c) THE SOLE NODE 308 registered in a singleton endpoint (in which case forwarding to 309 the endpoint is functionally similar to "unicast" operations in 310 the Internet). The nature of the minimum reception group for a 311 given endpoint can be determined from the endpoint's ID (again, 312 see 3.4 below): for some endpoint ID "schemes", the nature of the 313 minimum reception group is fixed - in a manner that is defined by 314 the scheme - for all endpoints identified under the scheme; for 315 other schemes, the nature of the minimum reception group is 316 indicated by some lexical feature of the "scheme-specific part" of 317 the endpoint ID, in a manner that is defined by the scheme. 319 Registration - A registration is the state machine characterizing a 320 given node's membership in a given endpoint. Any number of 321 registrations may be concurrently associated with a given 322 endpoint, and any number of registrations may be concurrently 323 associated with a given node. Any single registration must at any 324 time be in one of two states: Active, Passive. A registration 325 always has an associated "delivery failure action", the action 326 that is to be taken when a bundle that is "deliverable" (see 327 below) subject to that registration is received at a time when the 328 registration is in the Passive state. Delivery failure action 329 must be one of the following: 331 * defer "delivery" (see below) of the bundle subject to this 332 registration until (a) this bundle is the least recently 333 received of all bundles currently deliverable subject to this 334 registration and (b) either the registration is polled or else 335 the registration is in Active state; 337 * "abandon" (see below) delivery of the bundle subject to this 338 registration. 340 An additional implementation-specific delivery deferral procedure 341 may optionally be associated with the registration. While the 342 state of a registration is Active, reception of a bundle that is 343 deliverable subject to this registration must cause the bundle to 344 be delivered automatically as soon as it is the least recently 345 received bundle that is currently deliverable subject to the 346 registration. While the state of a registration is Passive, 347 reception of a bundle that is deliverable subject to this 348 registration must cause delivery of the bundle to be abandoned or 349 deferred as mandated by the registration's current delivery 350 failure action; in the latter case, any additional delivery 351 deferral procedure associated with the registration must also be 352 performed. 354 Delivery - Upon reception, the processing of a bundle that has been 355 sent to a given node depends on whether or not the receiving node 356 is registered in the bundle's destination endpoint; if it is, and 357 if the payload of the bundle is non-fragmentary (possibly as a 358 result of successful payload reassembly from fragmentary payloads, 359 including the original payload of the received bundle), then the 360 bundle is normally "delivered" to the node's application agent 361 subject to the registration characterizing the node's membership 362 in the destination endpoint. A bundle is considered to have been 363 delivered at a node subject to a registration as soon as the 364 application data unit that is the payload of the bundle, together 365 with the value of the bundle's "Acknowledgement by application is 366 requested" flag and any other relevant metadata (an implementation 367 matter), has been presented to the node's application agent in a 368 manner consistent with the state of that registration and, as 369 applicable, the registration's delivery failure action. 371 Deliverability, Abandonment - A bundle is considered "deliverable" 372 subject to a registration if and only if (a) the bundle's 373 destination endpoint is the endpoint with which the registration 374 is associated, (b) the bundle has not yet been delivered subject 375 to this registration, and (c) delivery of the bundle subject to 376 this registration has not been abandoned. To "abandon" delivery 377 of a bundle subject to a registration is simply to declare it no 378 longer deliverable subject to that registration; normally only 379 registrations' registered delivery failure actions cause 380 deliveries to be abandoned. 382 Deletion, Discarding - A bundle protocol agent "discards" a bundle 383 by simply ceasing all operations on the bundle and functionally 384 erasing all references to it; the specific procedures by which 385 this is accomplished are an implementation matter. Bundles are 386 discarded silently, i.e., the discarding of a bundle does not 387 result in generation of an administrative record. "Retention 388 constraints" are elements of bundle state that prevent a bundle 389 from being discarded; a bundle cannot be discarded while it has 390 any retention constraints. A bundle protocol agent "deletes" a 391 bundle in response to some anomalous condition by notifying the 392 bundle's report-to endpoint of the deletion (provided such 393 notification is warranted; see 4.13 for details) and then 394 arbitrarily removing all of the bundle's retention constraints, 395 enabling the bundle to be discarded. 397 Transmission - A transmission is a sustained effort by a node's 398 bundle protocol agent to cause a bundle to be sent to all nodes in 399 the minimum reception group of some endpoint (which may be the 400 bundle's destination or may be some intermediate forwarding 401 endpoint) in response to a transmission request issued by the 402 node's application agent. Any number of transmissions may be 403 concurrently undertaken by the bundle protocol agent of a given 404 node. 406 Custody - To "accept custody" upon forwarding a bundle is to commit 407 to retaining a copy of the bundle - possibly re-forwarding the 408 bundle when the necessity to do so is determined - until custody 409 of that bundle is "released". Custody of a bundle whose 410 destination is a singleton endpoint is released when either (a) 411 notification is received that some other node has accepted custody 412 of the same bundle, (b) notification is received that the bundle 413 has been delivered at the (sole) node registered in the bundle's 414 destination endpoint, or (c) the bundle is explicitly deleted for 415 some reason, such as lifetime expiration. The condition(s) under 416 which custody of a bundle whose destination is not a singleton 417 endpoint may be released are not defined in this specification. 418 To "refuse custody" of a bundle is to decide not to accept custody 419 of the bundle. A "custodial node" of a bundle is a node that has 420 accepted custody of the bundle and has not yet released that 421 custody. A "custodian" of a bundle is a singleton endpoint whose 422 sole member is one of the bundle's custodial nodes. 424 3.2. Implementation architectures 426 The above definitions are intended to enable the bundle protocol's 427 operations to be specified in a manner that minimizes bias toward any 428 particular implementation architecture. To illustrate the range of 429 interoperable implementation models that might conform to this 430 specification, four example architectures are briefly described 431 below. 433 1. Bundle protocol application server 435 A single bundle protocol application server, constituting a 436 single bundle node, runs as a daemon process on each computer. 437 The daemon's functionality includes all functions of the bundle 438 protocol agent, all convergence layer adapters, and both the 439 administrative and application-specific elements of the 440 application agent. The application-specific element of the 441 application agent functions as a server, offering bundle protocol 442 service over a local area network: it responds to remote 443 procedure calls from application processes (on the same computer 444 and/or remote computers) that need to communicate via the bundle 445 protocol. The server supports its clients by creating a new 446 (conceptual) node for each one and registering each such node in 447 a client-specified endpoint; the conceptual nodes managed by the 448 server function as clients' Bundle Protocol service access 449 points. 451 2. Peer application nodes 453 Any number of bundle protocol application processes, each one 454 constituting a single bundle node, run in ad-hoc fashion on each 455 computer. The functionality of the bundle protocol agent, all 456 convergence layer adapters, and the administrative element of the 457 application agent is provided by a library to which each node 458 process is dynamically linked at run time; the application- 459 specific element of each node's application agent is node- 460 specific application code. 462 3. Sensor network nodes 464 Each node of the sensor network is the self-contained 465 implementation of a single bundle node. All functions of the 466 bundle protocol agent, all convergence layer adapters, and the 467 administrative element of the application agent are implemented 468 in simplified form in ASICs, while the application-specific 469 element of each node's application agent is implemented in a 470 programmable microcontroller. Forwarding is rudimentary: all 471 bundles are forwarded on a hard-coded default route. 473 4. Dedicated bundle router 475 Each computer constitutes a single bundle node that functions 476 solely as a high-performance bundle forwarder. Many standard 477 functions of the bundle protocol agent, the convergence layer 478 adapters, and the administrative element of the application agent 479 are implemented in ASICs, but some functions are implemented in a 480 high-speed processor to enable reprogramming as necessary. The 481 node's application agent has no application-specific element. 482 Substantial non-volatile storage resources are provided, and 483 arbitrarily complex forwarding algorithms are supported. 485 3.3. Services offered by bundle protocol agents 487 The bundle protocol agent of each node is expected to provide the 488 following services to the node's application agent: 490 o commencing a registration (registering a node in an endpoint); 492 o terminating a registration; 494 o switching a registration between Active and Passive state; 496 o transmitting a bundle to an identified bundle endpoint; 498 o canceling a transmission; 500 o polling a registration that is in passive state; 502 o delivering a received bundle. 504 4. Bundle Format 506 Each bundle shall be a concatenated sequence of at least two block 507 structures. The first block in the sequence must be a primary bundle 508 block, and no bundle may have more than one primary bundle block. 509 Additional bundle protocol blocks of other types may follow the 510 primary block to support extensions to the Bundle Protocol, such as 511 the Bundle Security Protocol [BSP]. At most one of the blocks in the 512 sequence may be a payload block. The last block in the sequence must 513 have the "last block" flag (in its block processing control flags) 514 set to 1; for every other block in the bundle after the primary 515 block, this flag must be set to zero. 517 4.1. Self-Delimiting Numeric Values (SDNVs) 519 The design of the bundle protocol attempts to reconcile minimal 520 consumption of transmission bandwidth with: 522 o extensibility to address requirements not yet identified, and 524 o scalability across a wide range of network scales and payload 525 sizes. 527 A key strategic element in the design is the use of self-delimiting 528 numeric values (SDNVs). The SDNV encoding scheme is closely adapted 529 from the Abstract Syntax Notation One Basic Encoding Rules for 530 subidentifiers within an object identifier value [ASN1]. An SDNV is 531 a numeric value encoded in N octets, the last of which has its most 532 significant bit (MSB) set to zero; the MSB of every other octet in 533 the SDNV must be set to 1. The value encoded in an SDNV is the 534 unsigned binary number obtained by concatenating into a single bit 535 string the 7 least significant bits of each octet of the SDNV. 537 The following examples illustrate the encoding scheme for various 538 hexadecimal values. 540 0xABC : 1010 1011 1100 541 is encoded as 542 {1 00 10101} {0 0111100} 543 = 10010101 00111100 545 0x1234 : 0001 0010 0011 0100 546 = 1 0010 0011 0100 547 is encoded as 548 {1 0 100100} {0 0110100} 549 = 10100100 00110100 551 0x4234 : 0100 0010 0011 0100 552 = 100 0010 0011 0100 553 is encoded as 554 {1 000000 1} {1 0000100} {0 0110100} 555 = 10000001 10000100 00110100 557 0x7F : 0111 1111 558 = 111 1111 559 is encoded as 560 {0 1111111} 561 = 01111111 563 Figure 2: SDNV Example 565 Note: Care must be taken to make sure that the value to be encoded is 566 (in concept) padded with high-order zero bits to make its bitwise 567 length a multiple of 7 before encoding. Also note that, while there 568 is no theoretical limit on the size of an SDNV field, the overhead of 569 the SDNV scheme is 1:7, i.e., one bit of overhead for every 7 bits of 570 actual data to be encoded. Thus a 7-octet value (a 56-bit quantity 571 with no leading zeroes) would be encoded in an 8-octet SDNV; an 572 8-octet value (a 64-bit quantity with no leading zeroes) would be 573 encoded in a 10-octet SDNV (one octet containing the high-order bit 574 of the value padded with six leading zero bits, followed by nine 575 octets containing the remaining 63 bits of the value). 148 bits of 576 overhead would be consumed in encoding a 1024-bit RSA encryption key 577 directly in an SDNV. In general, an N-bit quantity with no leading 578 zeroes is encoded in an SDNV occupying ceil(N/7) octets, where ceil 579 is the integer ceiling function. 581 Implementations of the Bundle Protocol may handle as an invalid 582 numeric value any SDNV that encodes an integer that is larger than 583 (2^64 - 1). 585 An SDNV can be used to represent both very large and very small 586 integer values. However, SDNV is clearly not the best way to 587 represent every numeric value. For example, an SDNV is a poor way to 588 represent an integer whose value typically falls in the range 128 to 589 255. In general, though, we believe that SDNV representation of 590 numeric values in bundle blocks yields the smallest block sizes 591 without sacrificing scalability. 593 4.2. Bundle Processing Control Flags 595 The bundle processing control flags field in the primary bundle block 596 of each bundle is an SDNV; the value encoded in this SDNV is a string 597 of bits used to invoke selected bundle processing control features. 598 The significance of the value in each currently defined position of 599 this bit string is described here. Note that in the figure and 600 descriptions, the bit label numbers denote position (from least 601 significant ('0') to most significant) within the decoded bit string, 602 and not within the representation of the bits on the wire. This is 603 why the descriptions in this section and the next do not follow 604 standard RFC conventions with bit 0 on the left; if fields are added 605 in the future, the SDNV will grow to the left, and using this 606 representation allows the references here to remain valid. 608 2 1 0 609 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 |Status Report|Class of Svc.| General | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Figure 3: Bundle processing control flags bit layout 616 The bits in positions 0 through 6 are flags that characterize the 617 bundle as follows: 619 0 -- Bundle is a fragment. 621 1 -- Application data unit is an administrative record. 623 2 -- Bundle must not be fragmented. 625 3 -- Custody transfer is requested. 627 4 -- Destination endpoint is a singleton. 629 5 -- Acknowledgement by application is requested. 631 6 -- Reserved for future use. 633 The bits in positions 7 through 13 are used to indicate the bundle's 634 class of service. The bits in positions 8 and 7 constitute a two-bit 635 priority field indicating the bundle's priority, with higher values 636 being of higher priority: 00 = bulk, 01 = normal, 10 = expedited, 11 637 is reserved for future use. Within this field, bit 8 is the most 638 significant bit. The bits in positions 9 through 13 are reserved for 639 future use. 641 The bits in positions 14 through 20 are status report request flags. 642 These flags are used to request status reports as follows: 644 14 -- Request reporting of bundle reception. 646 15 -- Request reporting of custody acceptance. 648 16 -- Request reporting of bundle forwarding. 650 17 -- Request reporting of bundle delivery. 652 18 -- Request reporting of bundle deletion. 654 19 -- Reserved for future use. 656 20 -- Reserved for future use. 658 If the bundle processing control flags indicate that the bundle's 659 application data unit is an administrative record, then the custody 660 transfer requested flag must be zero and all status report request 661 flags must be zero. If the custody transfer requested flag is 1 then 662 the sending node requests that the receiving node accept custody of 663 the bundle. If the bundle's source endpoint ID is "dtn:none" (see 664 below), then the bundle is not uniquely identifiable and all bundle 665 protocol features that rely on bundle identity must therefore be 666 disabled: the bundle's custody transfer requested flag must be zero, 667 the "bundle must not be fragmented" flag must be 1, and all status 668 report request flags must be zero. 670 4.3. Block Processing Control Flags 672 The block processing control flags field in every block other than 673 the primary bundle block is an SDNV; the value encoded in this SDNV 674 is a string of bits used to invoke selected block processing control 675 features. The significance of the values in all currently defined 676 positions of this bit string, in order from least-significant 677 position in the decoded bit string (labeled '0') to most-significant 678 (labeled '6'), are described here. 680 0 681 6 5 4 3 2 1 0 682 +-+-+-+-+-+-+-+ 683 | Flags | 684 +-+-+-+-+-+-+-+ 686 Figure 4: Block processing control flags bit layout 688 0 - Block must be replicated in every fragment. 690 1 - Transmit status report if block can't be processed. 692 2 - Delete bundle if block can't be processed. 694 3 - Last block. 696 4 - Discard block if it can't be processed. 698 5 - Block was forwarded without being processed. 700 6 - Block contains an EID-reference field. 702 For each bundle whose primary block's bundle processing control flags 703 (see above) indicate that the bundle's application data unit is an 704 administrative record, the "Transmit status report if block can't be 705 processed" flag in the block processing flags field of every other 706 block in the bundle must be zero. 708 The 'Block must be replicated in every fragment' bit in the block 709 processing flags must be set to zero on all blocks that follow the 710 payload block. 712 4.4. Endpoint IDs 714 The destinations of bundles are bundle endpoints, identified by text 715 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 716 conveyed in any bundle block takes the form of a Uniform Resource 717 Identifier (URI; [URI]). As such, each endpoint ID can be 718 characterized as having this general structure: 720 < scheme name > : < scheme-specific part, or "SSP" > 722 As used for the purposes of the bundle protocol, neither the length 723 of a scheme name nor the length of an SSP may exceed 1023 bytes. 725 Bundle blocks cite a number of endpoint IDs for various purposes of 726 the bundle protocol. Many, though not necessarily all, of the 727 endpoint IDs referred to in the blocks of a given bundle are conveyed 728 in the "dictionary" byte array in the bundle's primary block. This 729 array is simply the concatenation of any number of null-terminated 730 scheme names and SSPs. 732 "Endpoint ID references" are used to cite endpoint IDs that are 733 contained in the dictionary; all endpoint ID citations in the primary 734 bundle block are endpoint ID references, and other bundle blocks may 735 contain endpoint ID references as well. Each endpoint ID reference 736 is an ordered pair of SDNVs: 738 o The first SDNV contains the offset within the dictionary of the 739 first character of the referenced endpoint ID's scheme name. 741 o The second SDNV contains the offset within the dictionary of the 742 first character of the referenced endpoint ID's SSP. 744 This encoding enables a degree of block compression: when the source 745 and report-to of a bundle are the same endpoint, for example, the 746 text of that endpoint's ID may be cited twice yet appear only once in 747 the dictionary. 749 The scheme identified by the < scheme name > in an endpoint ID is a 750 set of syntactic and semantic rules that fully explain how to parse 751 and interpret the SSP. The set of allowable schemes is effectively 752 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 753 protocol endpoint ID. In addition, a single additional scheme is 754 defined by the present document: 756 o The "dtn" scheme, which is used at minimum in the representation 757 of the null endpoint ID "dtn:none". The forwarding of a bundle to 758 the null endpoint is never contraindicated, and the minimum 759 reception group for the null endpoint is the empty set. 761 Note that, although the endpoint IDs conveyed in bundle blocks are 762 expressed as URIs, implementations of the BP service interface may 763 support expression of endpoint IDs in some internationalized manner 764 (e.g., IRIs; see RFC 3987). 766 4.5. Formats of Bundle Blocks 768 This section describes the formats of the primary block and payload 769 block. Rules for processing these blocks appear in Section 5 of this 770 document. 772 Note that supplementary DTN protocol specifications (including, but 773 not restricted to, the Bundle Security Protocol [BSP]) may require 774 that BP implementations conforming to those protocols construct and 775 process additional blocks. 777 The format of the two basic BP blocks is shown in Figure 5 below. 779 Primary Bundle Block 780 +----------------+----------------+----------------+----------------+ 781 | Version | Proc. Flags (*) | 782 +----------------+----------------+----------------+----------------+ 783 | Block length (*) | 784 +----------------+----------------+---------------------------------+ 785 | Destination scheme offset (*) | Destination SSP offset (*) | 786 +----------------+----------------+----------------+----------------+ 787 | Source scheme offset (*) | Source SSP offset (*) | 788 +----------------+----------------+----------------+----------------+ 789 | Report-to scheme offset (*) | Report-to SSP offset (*) | 790 +----------------+----------------+----------------+----------------+ 791 | Custodian scheme offset (*) | Custodian SSP offset (*) | 792 +----------------+----------------+----------------+----------------+ 793 | Creation Timestamp time (*) | 794 +---------------------------------+---------------------------------+ 795 | Creation Timestamp sequence number (*) | 796 +---------------------------------+---------------------------------+ 797 | Lifetime (*) | 798 +----------------+----------------+----------------+----------------+ 799 | Dictionary length (*) | 800 +----------------+----------------+----------------+----------------+ 801 | Dictionary byte array (variable) | 802 +----------------+----------------+---------------------------------+ 803 | [Fragment offset (*)] | 804 +----------------+----------------+---------------------------------+ 805 | [Total application data unit length (*)] | 806 +----------------+----------------+---------------------------------+ 808 Bundle Payload Block 809 +----------------+----------------+----------------+----------------+ 810 | Block type | Proc. Flags (*)| Block length(*) | 811 +----------------+----------------+----------------+----------------+ 812 / Bundle Payload (variable) / 813 +-------------------------------------------------------------------+ 815 Figure 5: Bundle Block Formats 817 (*) Notes: 819 The bundle processing control ("Proc.") flags field in the Primary 820 Bundle Block is an SDNV and is therefore variable-length. A three- 821 octet SDNV is shown here for convenience in representation. 823 The block length field of the Primary Bundle Block is an SDNV and is 824 therefore variable-length. A four-octet SDNV is shown here for 825 convenience in representation. 827 Each of the eight offset fields in the Primary Bundle Block is an 828 SDNV and is therefore variable-length. Two-octet SDNVs are shown 829 here for convenience in representation. 831 The Creation Timestamp time field in the Primary Bundle Block is an 832 SDNV and is therefore variable-length. A four-octet SDNV is shown 833 here for convenience in representation. 835 The Creation Timestamp sequence number field in the Primary Bundle 836 Block is an SDNV and is therefore variable-length. A four-octet SDNV 837 is shown here for convenience in representation. 839 The Lifetime field in the Primary Bundle Block is an SDNV and is 840 therefore variable-length. A four-octet SDNV is shown here for 841 convenience in representation. 843 The dictionary length field of the Primary Bundle Block is an SDNV 844 and is therefore variable-length. A four-octet SDNV is shown here 845 for convenience in representation. 847 The fragment offset field of the Primary Bundle Block is present only 848 if the Fragment flag in the block's processing flags byte is set to 849 1. It is an SDNV and is therefore variable-length; a four-octet SDNV 850 is shown here for convenience in representation. 852 The total application data unit length field of the Primary Bundle 853 Block is present only if the Fragment flag in the block's processing 854 flags byte is set to 1. It is an SDNV and is therefore variable- 855 length; a four-octet SDNV is shown here for convenience in 856 representation. 858 The block processing control ("Proc.") flags field of the Payload 859 Block is an SDNV and is therefore variable-length. A one-octet SDNV 860 is shown here for convenience in representation. 862 The block length field of the Payload Block is an SDNV and is 863 therefore variable-length. A two-octet SDNV is shown here for 864 convenience in representation. 866 4.5.1. Primary Bundle Block 868 The primary bundle block contains the basic information needed to 869 route bundles to their destinations. The fields of the primary 870 bundle block are: 872 Version: A 1-byte field indicating the version of the bundle 873 protocol that constructed this block. The present document 874 describes version 0x05 of the bundle protocol. 876 Bundle Processing Control Flags: The Bundle Processing Control 877 Flags field is an SDNV that contains the bundle processing control 878 flags discussed in Section 4.2 above. 880 Block Length: The Block Length field is an SDNV that contains the 881 aggregate length of all remaining fields of the block. 883 Destination Scheme Offset: The Destination Scheme Offset field 884 contains the offset within the dictionary byte array of the scheme 885 name of the endpoint ID of the bundle's destination, i.e., the 886 endpoint containing the node(s) at which the bundle is to be 887 delivered. 889 Destination SSP Offset: The Destination SSP Offset field contains 890 the offset within the dictionary byte array of the scheme-specific 891 part of the endpoint ID of the bundle's destination. 893 Source Scheme Offset: The Source Scheme Offset field contains the 894 offset within the dictionary byte array of the scheme name of the 895 endpoint ID of the bundle's nominal source, i.e., the endpoint 896 nominally containing the node from which the bundle was initially 897 transmitted. 899 Source SSP Offset: The Source SSP Offset field contains the offset 900 within the dictionary byte array of the scheme-specific part of 901 the endpoint ID of the bundle's nominal source. 903 Report-to Scheme Offset: The Report-to Scheme Offset field contains 904 the offset within the dictionary byte array of the scheme name of 905 the ID of the endpoint to which status reports pertaining to the 906 forwarding and delivery of this bundle are to be transmitted. 908 Report-to SSP Offset: The Report-to SSP Offset field contains the 909 offset within the dictionary byte array of the scheme-specific 910 part of the ID of the endpoint to which status reports pertaining 911 to the forwarding and delivery of this bundle are to be 912 transmitted. 914 Custodian Scheme Offset: The "current custodian endpoint ID" of a 915 primary bundle block identifies an endpoint whose membership 916 includes the node that most recently accepted custody of the 917 bundle upon forwarding this bundle. The Custodian Scheme Offset 918 field contains the offset within the dictionary byte array of the 919 scheme name of the current custodian endpoint ID. 921 Custodian SSP Offset: The Destination SSP Offset field contains the 922 offset within the dictionary byte array of the scheme-specific 923 part of the current custodian endpoint ID. 925 Creation Timestamp: The creation timestamp is a pair of SDNVs that, 926 together with the source endpoint ID and (if the bundle is a 927 fragment) the fragment offset and payload length, serve to 928 identify the bundle. The first SDNV of the timestamp is the 929 bundle's creation time while the second is the bundle's creation 930 timestamp sequence number. Bundle creation time is the time - 931 expressed in seconds since the start of the year 2000, on the 932 Coordinated Universal Time (UTC) scale [UTC] - at which the 933 transmission request was received that resulted in the creation of 934 the bundle. Sequence count is the latest value (as of the time at 935 which that transmission request was received) of a monotonically 936 increasing positive integer counter managed by the source node's 937 bundle protocol agent that may be reset to zero whenever the 938 current time advances by one second. A source Bundle Protocol 939 Agent must never create two distinct bundles with the same source 940 endpoint ID and bundle creation timestamp. The combination of 941 source endpoint ID and bundle creation timestamp therefore serves 942 to identify a single transmission request, enabling it to be 943 acknowledged by the receiving application (provided the source 944 endpoint ID is not "dtn:none"). 946 Lifetime: The lifetime field is an SDNV that indicates the time at 947 which the bundle's payload will no longer be useful, encoded as a 948 number of seconds past the creation time. When the current time 949 is greater than the creation time plus the lifetime, bundle nodes 950 need no longer retain or forward the bundle; the bundle may be 951 deleted from the network. 953 Dictionary Length: The Dictionary Length field is an SDNV that 954 contains the length of the dictionary byte array. 956 Dictionary: The Dictionary field is an array of bytes formed by 957 concatenating the null-terminated scheme names and SSPs of all 958 endpoint IDs referenced by any fields in this Primary Block 959 together with, potentially, other endpoint IDs referenced by 960 fields in other TBD DTN protocol blocks. Its length is given by 961 the value of the Dictionary Length field. 963 Fragment Offset: If the Bundle Processing Control Flags of this 964 Primary block indicate that the bundle is a fragment, then the 965 Fragment Offset field is an SDNV indicating the offset from the 966 start of the original application data unit at which the bytes 967 comprising the payload of this bundle were located. If not, then 968 the Fragment Offset field is omitted from the block. 970 Total Application Data Unit Length: If the Bundle Processing 971 Control Flags of this Primary block indicate that the bundle is a 972 fragment, then the Total Application Data Unit Length field is an 973 SDNV indicating the total length of the original application data 974 unit of which this bundle's payload is a part. If not, then the 975 Total Application Data Unit Length field is omitted from the 976 block. 978 4.5.2. Canonical Bundle Block Format 980 Every bundle block of every type other than the primary bundle block 981 comprises the following fields, in this order: 983 o Block type code, expressed as an 8-bit unsigned binary integer. 984 Bundle block type code 1 indicates that the block is a bundle 985 payload block. Block type codes 192 through 255 are not defined 986 in this specification and are available for private and/or 987 experimental use. All other values of the block type code are 988 reserved for future use. 990 o Block processing control flags, an unsigned integer expressed as 991 an SDNV. The individual bits of this integer are used to invoke 992 selected block processing control features. 994 o Block EID reference count and EID references (optional). If and 995 only if the block references EID elements in the primary block's 996 dictionary, the 'block contains an EID-reference field' flag in 997 the block processing control flags is set to 1 and the block 998 includes an EID reference field consisting of a count of EID 999 references expressed as an SDNV followed by the EID references 1000 themselves. Each EID reference is a pair of SDNVs. The first 1001 SDNV of each EID reference contains the offset of a scheme name in 1002 the primary block's dictionary, and the second SDNV of each 1003 reference contains the offset of a scheme-specific part in the 1004 dictionary. 1006 o Block data length, an unsigned integer expressed as an SDNV. The 1007 Block data length field contains the aggregate length of all 1008 remaining fields of the block, i.e., the block-type-specific data 1009 fields. 1011 o Block-type-specific data fields, whose format and order are type- 1012 specific and whose aggregate length in octets is the value of the 1013 block data length field. All multi-byte block-type-specific data 1014 fields are represented in network byte order. 1016 +-----------+-----------+-----------+-----------+ 1017 |Block type | Block processing ctrl flags (SDNV)| 1018 +-----------+-----------+-----------+-----------+ 1019 | Block length (SDNV) | 1020 +-----------+-----------+-----------+-----------+ 1021 / Block body data (variable) / 1022 +-----------+-----------+-----------+-----------+ 1024 Figure 6: Block layout without EID reference list. 1026 +-----------+-----------+-----------+-----------+ 1027 |Block Type | Block processing ctrl flags (SDNV)| 1028 +-----------+-----------+-----------+-----------+ 1029 | EID Reference Count (SDNV) | 1030 +-----------+-----------+-----------+-----------+ 1031 | Ref_scheme_1 (SDNV) | Ref_ssp_1 (SDNV) | 1032 +-----------+-----------+-----------+-----------+ 1033 | Ref_scheme_2 (SDNV) | Ref_ssp_2 (SDNV) | 1034 +-----------+-----------+-----------+-----------+ 1035 | Block length (SDNV) | 1036 +-----------+-----------+-----------+-----------+ 1037 / Block body data (variable) / 1038 +-----------+-----------+-----------+-----------+ 1040 Figure 7: Block layout showing two EID references. 1042 4.5.3. Bundle Payload Block 1044 The fields of the bundle payload block are: 1046 Block Type: The Block Type field is a 1-byte field that indicates 1047 the type of the block. For the bundle payload block this field 1048 contains the value 1. 1050 Block Processing Control Flags: The Block Processing Control Flags 1051 field is an SDNV that contains the block processing control flags 1052 discussed in Section 4.3 above. 1054 Block Length: The Block Length field is an SDNV that contains the 1055 aggregate length of all remaining fields of the block - which is 1056 to say, the length of the bundle's payload. 1058 Payload: The application data carried by this bundle. 1060 That is, bundle payload blocks follow the canonical format of the 1061 previous section with the restriction that the 'block contains an 1062 EID-reference field' bit of the block processing control flags is 1063 never set. The block body data for payload blocks is the application 1064 data carried by the bundle. 1066 4.6. Extension Blocks 1068 "Extension blocks" are all blocks other than the primary and payload 1069 blocks. Because extension blocks are not defined in the Bundle 1070 Protocol specification (the present document), not all nodes 1071 conforming to this specification will necessarily instantiate Bundle 1072 Protocol implementations that include procedures for processing (that 1073 is, recognizing, parsing, acting on, and/or producing) all extension 1074 blocks. It is therefore possible for a node to receive a bundle that 1075 includes extension blocks which the node cannot process. 1077 Whenever a bundle is forwarded that contains one or more extension 1078 blocks that could not be processed, the "Block was forwarded without 1079 being processed" flag must be set to 1 within the block processing 1080 flags of each such block. For each block flagged in this way, the 1081 flag may optionally be cleared (i.e., set to zero) by another node 1082 that subsequently receives the bundle and is able to process that 1083 block; the specifications defining the various extension blocks are 1084 expected to define the circumstances under which this flag may be 1085 cleared, if any. 1087 4.7. Dictionary revision 1089 Any strings (scheme names and SSPs) in a bundle's dictionary that are 1090 not referenced from the bundle's primary block nor from the block EID 1091 reference field of any extension block may be removed from the 1092 dictionary at the time the bundle is forwarded. 1094 Whenever removal of a string from the dictionary causes the offsets 1095 (within the dictionary byte array) of any other strings to change, 1096 all endpoint ID references that refer to those strings must be 1097 adjusted at the same time. Note that these references may be in the 1098 primary block and/or in the block EID reference fields of extension 1099 blocks. 1101 5. Bundle Processing 1103 The bundle processing procedures mandated in this section and in 1104 Section 6 govern the operation of the Bundle Protocol Agent and the 1105 Application Agent administrative element of each bundle node. They 1106 are neither exhaustive nor exclusive. That is, supplementary DTN 1107 protocol specifications (including, but not restricted to, the Bundle 1108 Security Protocol [BSP]) may require that additional measures be 1109 taken at specified junctures in these procedures. Such additional 1110 measures shall not override or supersede the mandated bundle protocol 1111 procedures, except that they may in some cases make these procedures 1112 moot by requiring, for example, that implementations conforming to 1113 the supplementary protocol terminate the processing of a given 1114 incoming or outgoing bundle due to a fault condition recognized by 1115 that protocol. 1117 5.1. Generation of administrative records 1119 All initial transmission of bundles is in response to bundle 1120 transmission requests presented by nodes' application agents. When 1121 required to "generate" an administrative record (a bundle status 1122 report or a custody signal), the bundle protocol agent itself is 1123 responsible for causing a new bundle to be transmitted, conveying 1124 that record. In concept, the bundle protocol agent discharges this 1125 responsibility by directing the administrative element of the node's 1126 application agent to construct the record and request its 1127 transmission as detailed in Section 6 below; in practice, the manner 1128 in which administrative record generation is accomplished is an 1129 implementation matter, provided the constraints noted in Section 6 1130 are observed. 1132 Under some circumstances the requesting of status reports could 1133 result in an unacceptable increase in the bundle traffic in the 1134 network. For this reason, the generation of status reports is 1135 mandatory only in one case, the deletion of a bundle for which 1136 custody transfer is requested. In all other cases the decision on 1137 whether or not to generate a requested status report is left to the 1138 discretion of the bundle protocol agent. Mechanisms that could 1139 assist in making such decisions, such as pre-placed agreements 1140 authorizing the generation of status reports under specified 1141 circumstances, are beyond the scope of this specification. 1143 Notes on administrative record terminology: 1145 o A "bundle reception status report" is a bundle status report with 1146 the "reporting node received bundle" flag set to 1. 1148 o A "custody acceptance status report" is a bundle status report 1149 with the "reporting node accepted custody of bundle" flag set to 1150 1. 1152 o A "bundle forwarding status report" is a bundle status report with 1153 the "reporting node forwarded the bundle" flag set to 1. 1155 o A "bundle delivery status report" is a bundle status report with 1156 the "reporting node delivered the bundle" flag set to 1. 1158 o A "bundle deletion status report" is a bundle status report with 1159 the "reporting node deleted the bundle" flag set to 1. 1161 o A "Succeeded" custody signal is a custody signal with the "custody 1162 transfer succeeded" flag set to 1. 1164 o A "Failed" custody signal is a custody signal with the "custody 1165 transfer succeeded" flag set to zero. 1167 o The "current custodian" of a bundle is the endpoint identified by 1168 the current custodian endpoint ID in the bundle's primary block. 1170 5.2. Bundle Transmission 1172 The steps in processing a bundle transmission request are: 1174 Step 1: If custody transfer is requested for this bundle 1175 transmission and, moreover, custody acceptance by the source node 1176 is required, then either the bundle protocol agent must commit to 1177 accepting custody of the bundle - in which case processing 1178 proceeds from Step 2 - or else the request cannot be honored and 1179 all remaining steps of this procedure must be skipped. The bundle 1180 protocol agent must not commit to accepting custody of a bundle if 1181 the conditions under which custody of the bundle may be accepted 1182 are not satisfied. The conditions under which a node may accept 1183 custody of a bundle whose destination is not a singleton endpoint 1184 are not defined in this specification. 1186 Step 2: Transmission of the bundle is initiated. An outbound 1187 bundle must be created per the parameters of the bundle 1188 transmission request, with current custodian endpoint ID set to 1189 the null endpoint ID "dtn:none" and with the retention constraint 1190 "Dispatch pending". The source endpoint ID of the bundle must be 1191 either the ID of an endpoint of which the node is a member or else 1192 the null endpoint ID "dtn:none". 1194 Step 3: Processing proceeds from Step 1 of Section 5.4. 1196 5.3. Bundle Dispatching 1198 The steps in dispatching a bundle are: 1200 Step 1: If the bundle's destination endpoint is an endpoint of 1201 which the node is a member, the bundle delivery procedure defined 1202 in Section 5.7 must be followed. 1204 Step 2: Processing proceeds from Step 1 of Section 5.4. 1206 5.4. Bundle Forwarding 1208 The steps in forwarding a bundle are: 1210 Step 1: The retention constraint "Forward pending" must be added to 1211 the bundle, and the bundle's "Dispatch pending" retention 1212 constraint must be removed. 1214 Step 2: The bundle protocol agent must determine whether or not 1215 forwarding is contraindicated for any of the reasons listed in 1216 Figure 12. In particular: 1218 * The bundle protocol agent must determine which endpoint(s) to 1219 forward the bundle to. The bundle protocol agent may choose 1220 either to forward the bundle directly to its destination 1221 endpoint (if possible) or else to forward the bundle to some 1222 other endpoint(s) for further forwarding. The manner in which 1223 this decision is made may depend on the scheme name in the 1224 destination endpoint ID but in any case is beyond the scope of 1225 this document. If the agent finds it impossible to select any 1226 endpoint(s) to forward the bundle to, then forwarding is 1227 contraindicated. 1229 * Provided the bundle protocol agent succeeded in selecting the 1230 endpoint(s) to forward the bundle to, the bundle protocol agent 1231 must select the convergence layer adapter(s) whose services 1232 will enable the node to send the bundle to the nodes of the 1233 minimum reception group of each selected endpoint. The manner 1234 in which the appropriate convergence layer adapters are 1235 selected may depend on the scheme name in the destination 1236 endpoint ID but in any case is beyond the scope of this 1237 document. If the agent finds it impossible to select 1238 convergence layer adapters to use in forwarding this bundle, 1239 then forwarding is contraindicated. 1241 Step 3: If forwarding of the bundle is determined to be 1242 contraindicated for any of the reasons listed in Figure 12, then 1243 the Forwarding Contraindicated procedure defined in Section 5.4.1 1244 must be followed; the remaining steps of Section 5 are skipped at 1245 this time. 1247 Step 4: If the bundle's custody transfer requested flag (in the 1248 bundle processing flags field) is set to 1 then the custody 1249 transfer procedure defined in Section 5.10.2 must be followed. 1251 Step 5: For each endpoint selected for forwarding, the bundle 1252 protocol agent must invoke the services of the selected 1253 convergence layer adapter(s) in order to effect the sending of the 1254 bundle to the nodes constituting the minimum reception group of 1255 that endpoint. Determining the time at which the bundle is to be 1256 sent by each convergence layer adapter is an implementation 1257 matter. 1259 To keep from possibly invalidating bundle security, the sequencing 1260 of the blocks in a forwarded bundle must not be changed as it 1261 transits a node; received blocks must be transmitted in the same 1262 relative order as that in which they were received. While blocks 1263 may be added to bundles as they transit intermediate nodes, 1264 removal of blocks that do not have their 'Discard block if it 1265 can't be processed' flag in the block processing control flags set 1266 to 1 may cause security to fail. 1268 Step 6: When all selected convergence layer adapters have informed 1269 the bundle protocol agent that they have concluded their data 1270 sending procedures with regard to this bundle: 1272 * If the "request reporting of bundle forwarding" flag in the 1273 bundle's status report request field is set to 1, then a bundle 1274 forwarding status report should be generated, destined for the 1275 bundle's report-to endpoint ID. If the bundle has the 1276 retention constraint "custody accepted" and all of the nodes in 1277 the minimum reception group of the endpoint selected for 1278 forwarding are known to be unable to send bundles back to this 1279 node, then the reason code on this bundle forwarding status 1280 report must be "forwarded over unidirectional link"; otherwise 1281 the reason code must be "no additional information". 1283 * The bundle's "Forward pending" retention constraint must be 1284 removed. 1286 5.4.1. Forwarding Contraindicated 1288 The steps in responding to contraindication of forwarding for some 1289 reason are: 1291 Step 1: The bundle protocol agent must determine whether or not to 1292 declare failure in forwarding the bundle for this reason. Note: 1293 this decision is likely to be influenced by the reason for which 1294 forwarding is contraindicated. 1296 Step 2: If forwarding failure is declared, then the Forwarding 1297 Failed procedure defined in 4.4.2 must be followed. Otherwise, 1298 (a) if the bundle's custody transfer requested flag (in the bundle 1299 processing flags field) is set to 1 then the custody transfer 1300 procedure defined in Section 5.10 must be followed; (b) when - at 1301 some future time - the forwarding of this bundle ceases to be 1302 contraindicated, processing proceeds from Step 5 of Section 5.4. 1304 5.4.2. Forwarding Failed 1306 The steps in responding to a declaration of forwarding failure for 1307 some reason are: 1309 Step 1: If the bundle's custody transfer requested flag (in the 1310 bundle processing flags field) is set to 1, custody transfer 1311 failure must be handled. Procedures for handling failure of 1312 custody transfer for a bundle whose destination is not a singleton 1313 endpoint are not defined in this specification. For a bundle 1314 whose destination is a singleton endpoint, the bundle protocol 1315 agent must handle the custody transfer failure by generating a 1316 "Failed" custody signal for the bundle, destined for the bundle's 1317 current custodian; the custody signal must contain a reason code 1318 corresponding to the reason for which forwarding was determined to 1319 be contraindicated. (Note that discarding the bundle will not 1320 delete it from the network, since the current custodian still has 1321 a copy.) 1323 Step 2: If the bundle's destination endpoint is an endpoint of 1324 which the node is a member, then the bundle's "Forward pending" 1325 retention constraint must be removed. Otherwise the bundle must 1326 be deleted: the bundle deletion procedure defined in 4.13 must be 1327 followed, citing the reason for which forwarding was determined to 1328 be contraindicated. 1330 5.5. Bundle Expiration 1332 A bundle expires when the current time is greater than the bundle's 1333 creation time plus its lifetime as specified in the primary bundle 1334 block. Bundle expiration may occur at any point in the processing of 1335 a bundle. When a bundle expires, the bundle protocol agent must 1336 delete the bundle for the reason "lifetime expired": the bundle 1337 deletion procedure defined in Section 5.13 must be followed. 1339 5.6. Bundle Reception 1341 The steps in processing a bundle received from another node are: 1343 Step 1: The retention constraint "Dispatch pending" must be added 1344 to the bundle. 1346 Step 2: If the "request reporting of bundle reception" flag in the 1347 bundle's status report request field is set to 1, then a bundle 1348 reception status report with reason code "No additional 1349 information" should be generated, destined for the bundle's 1350 report-to endpoint ID. 1352 Step 3: For each block in the bundle that is an extension block 1353 that the bundle protocol agent cannot process: 1355 * If the block processing flags in that block indicate that a 1356 status report is requested in this event, then a bundle 1357 reception status report with reason code "Block unintelligible" 1358 should be generated, destined for the bundle's report-to 1359 endpoint ID. 1361 * If the block processing flags in that block indicate that the 1362 bundle must be deleted in this event, then the bundle protocol 1363 agent must delete the bundle for the reason "Block 1364 unintelligible"; the bundle deletion procedure defined in 4.13 1365 must be followed and all remaining steps of the bundle 1366 reception procedure must be skipped. 1368 * If the block processing flags in that block do NOT indicate 1369 that the bundle must be deleted in this event but do indicate 1370 that the block must be discarded, then the bundle protocol 1371 agent must remove this block from the bundle. 1373 * If the block processing flags in that block indicate NEITHER 1374 that the bundle must be deleted NOR that the block must be 1375 discarded, then the bundle protocol agent must set to 1 the 1376 "Block was forwarded without being processed" flag in the block 1377 processing flags of the block. 1379 Step 4: If the bundle's custody transfer requested flag (in the 1380 bundle processing flags field) is set to 1 and the bundle has the 1381 same source endpoint ID, creation timestamp, and (if the bundle is 1382 a fragment) fragment offset and payload length as another bundle 1383 that (a) has not been discarded and (b) currently has the 1384 retention constraint "Custody accepted", custody transfer 1385 redundancy must be handled; otherwise, processing proceeds from 1386 Step 5. Procedures for handling redundancy in custody transfer 1387 for a bundle whose destination is not a singleton endpoint are not 1388 defined in this specification. For a bundle whose destination is 1389 a singleton endpoint, the bundle protocol agent must handle 1390 custody transfer redundancy by generating a "Failed" custody 1391 signal for this bundle with reason code "Redundant reception", 1392 destined for this bundle's current custodian, and removing this 1393 bundle's "Dispatch pending" retention constraint. 1395 Step 5: Processing proceeds from Step 1 of Section 5.3. 1397 5.7. Local Bundle Delivery 1399 The steps in processing a bundle that is destined for an endpoint of 1400 which this node is a member are: 1402 Step 1: If the received bundle is a fragment, the application data 1403 unit reassembly procedure described in Section 5.9 must be 1404 followed. If this procedure results in reassembly of the entire 1405 original application data unit, processing of this bundle (whose 1406 fragmentary payload has been replaced by the reassembled 1407 application data unit) proceeds from Step 2; otherwise the 1408 retention constraint "Reassembly pending" must be added to the 1409 bundle and all remaining steps of this procedure are skipped. 1411 Step 2: Delivery depends on the state of the registration whose 1412 endpoint ID matches that of the destination of the bundle: 1414 * If the registration is in the Active state, then the bundle 1415 must be delivered subject to this registration (see Section 3.1 1416 above) as soon as all previously received bundles that are 1417 deliverable subject to this registration have been delivered. 1419 * If the registration is in the Passive state, then the 1420 registration's delivery failure action must be taken (see 1421 Section 3.1 above). 1423 Step 3: As soon as the bundle has been delivered: 1425 * If the "request reporting of bundle delivery" flag in the 1426 bundle's status report request field is set to 1, then a bundle 1427 delivery status report should be generated, destined for the 1428 bundle's report-to endpoint ID. Note that this status report 1429 only states that the payload has been delivered to the 1430 application agent, not that the application agent has processed 1431 that payload. 1433 * If the bundle's custody transfer requested flag (in the bundle 1434 processing flags field) is set to 1, custodial delivery must be 1435 reported. Procedures for reporting custodial delivery for a 1436 bundle whose destination is not a singleton endpoint are not 1437 defined in this specification. For a bundle whose destination 1438 is a singleton endpoint, the bundle protocol agent must report 1439 custodial delivery by generating a "Succeeded" custody signal 1440 for the bundle, destined for the bundle's current custodian. 1442 5.8. Bundle Fragmentation 1444 It may at times be necessary for bundle protocol agents to reduce the 1445 sizes of bundles in order to forward them. This might be the case, 1446 for example, if the endpoint to which a bundle is to be forwarded is 1447 accessible only via intermittent contacts and no upcoming contact is 1448 long enough to enable the forwarding of the entire bundle. 1450 The size of a bundle can be reduced by "fragmenting" the bundle. To 1451 fragment a bundle whose payload is of size M is to replace it with 1452 two "fragments" - new bundles with the same source endpoint ID and 1453 creation timestamp as the original bundle - whose payloads are the 1454 first N and the last (M - N) bytes of the original bundle's payload, 1455 where 0 < N < M. Note that fragments may themselves be fragmented, so 1456 fragmentation may in effect replace the original bundle with more 1457 than two fragments. (However, there is only one 'level' of 1458 fragmentation, as in IP fragmentation.) 1460 Any bundle whose primary block's bundle processing flags do NOT 1461 indicate that it must not be fragmented may be fragmented at any 1462 time, for any purpose, at the discretion of the bundle protocol 1463 agent. 1465 Fragmentation shall be constrained as follows: 1467 o The concatenation of the payloads of all fragments produced by 1468 fragmentation must always be identical to the payload of the 1469 bundle that was fragmented. Note that the payloads of fragments 1470 resulting from different fragmentation episodes, in different 1471 parts of the network, may be overlapping subsets of the original 1472 bundle's payload. 1474 o The bundle processing flags in the primary block of each fragment 1475 must be modified to indicate that the bundle is a fragment, and 1476 both fragment offset and total application data unit length must 1477 be provided at the end of each fragment's primary bundle block. 1479 o The primary blocks of the fragments will differ from that of the 1480 fragmented bundle as noted above. 1482 o The payload blocks of fragments will differ from that of the 1483 fragmented bundle as noted above. 1485 o All blocks that precede the payload block at the time of 1486 fragmentation must be replicated in the fragment with the lowest 1487 offset. 1489 o All blocks that follow the payload block at the time of 1490 fragmentation must be replicated in the fragment with the highest 1491 offset. 1493 o If the 'Block must be replicated in every fragment' bit is set to 1494 one then the block must be replicated in every fragment. 1496 o If the 'Block must be replicated in every fragment' bit is set to 1497 zero, the block should be replicated in only one fragment. 1499 o The relative order of all blocks that are present in a fragment 1500 must be the same as in the bundle prior to fragmentation. 1502 5.9. Application Data Unit Reassembly 1504 If the concatenation - as informed by fragment offsets and payload 1505 lengths - of the payloads of all previously received fragments with 1506 the same source endpoint ID and creation timestamp as this fragment, 1507 together with the payload of this fragment, forms a byte array whose 1508 length is equal to the total application data unit length in the 1509 fragment's primary block, then: 1511 o This byte array - the reassembled application data unit - must 1512 replace the payload of this fragment. 1514 o The "Reassembly pending" retention constraint must be removed from 1515 every other fragment whose payload is a subset of the reassembled 1516 application data unit. 1518 Note: reassembly of application data units from fragments occurs at 1519 destination endpoints as necessary; an application data unit may also 1520 be reassembled at some other endpoint on the route to the 1521 destination. 1523 5.10. Custody Transfer 1525 The conditions under which a node may accept custody of a bundle 1526 whose destination is not a singleton endpoint are not defined in this 1527 specification. 1529 The decision as to whether or not to accept custody of a bundle whose 1530 destination is a singleton endpoint is an implementation matter which 1531 may involve both resource and policy considerations; however, if the 1532 bundle protocol agent has committed to accepting custody of the 1533 bundle (as described in Step 1 of Section 5.2) then custody must be 1534 accepted. 1536 If the bundle protocol agent elects to accept custody of the bundle, 1537 then it must follow the custody acceptance procedure defined in 1538 Section 5.10.1. 1540 5.10.1. Custody Acceptance 1542 Procedures for acceptance of custody of a bundle whose destination is 1543 not a singleton endpoint are not defined in this specification. 1545 Procedures for acceptance of custody of a bundle whose destination is 1546 a singleton endpoint are defined as follows. 1548 The retention constraint "Custody accepted" must be added to the 1549 bundle. 1551 If the "request custody acceptance reporting" flag in the bundle's 1552 status report request field is set to 1, a custody acceptance status 1553 report should be generated, destined for the report-to endpoint ID of 1554 the bundle. However, if a bundle reception status report was 1555 generated for this bundle (step 1 of Section 5.6) then this report 1556 should be generated by simply turning on the "Reporting node accepted 1557 custody of bundle" flag in that earlier report's status flags byte. 1559 The bundle protocol agent must generate a "Succeeded" custody signal 1560 for the bundle, destined for the bundle's current custodian. 1562 The bundle protocol agent must assert the new current custodian for 1563 the bundle. It does so by changing the current custodian endpoint ID 1564 in the bundle's primary block to the endpoint ID of one of the 1565 singleton endpoints in which the node is registered. This may entail 1566 appending that endpoint ID's null-terminated scheme name and SSP to 1567 the dictionary byte array in the bundle's primary block, and in some 1568 case it may also enable the (optional) removal of the current 1569 custodian endpoint ID's scheme name and/or SSP from the dictionary. 1571 The bundle protocol agent may set a custody transfer countdown timer 1572 for this bundle; upon expiration of this timer prior to expiration of 1573 the bundle itself and prior to custody transfer success for this 1574 bundle, the custody transfer failure procedure detailed in section 1575 Section 5.12 must be followed. The manner in which the countdown 1576 interval for such a timer is determined is an implementation matter. 1578 The bundle should be retained in persistent storage if possible. 1580 5.10.2. Custody Release 1582 Procedures for release of custody of a bundle whose destination is 1583 not a singleton endpoint are not defined in this specification. 1585 When custody of a bundle is released, where the destination of the 1586 bundle is a singleton endpoint, the "Custody accepted" retention 1587 constraint must be removed from the bundle and any custody transfer 1588 timer that has been established for this bundle must be destroyed. 1590 5.11. Custody Transfer Success 1592 Procedures for determining custody transfer success for a bundle 1593 whose destination is not a singleton endpoint are not defined in this 1594 specification. 1596 Upon receipt of a "Succeeded" custody signal at a node that is a 1597 custodial node of the bundle identified in the custody signal, where 1598 the destination of the bundle is a singleton endpoint, custody of the 1599 bundle must be released as described in Section 5.10.2. 1601 5.12. Custody Transfer Failure 1603 Procedures for determining custody transfer failure for a bundle 1604 whose destination is not a singleton endpoint are not defined in this 1605 specification. Custody transfer for a bundle whose destination is a 1606 singleton endpoint is determined to have failed at a custodial node 1607 for that bundle when either (a) that node's custody transfer timer 1608 for that bundle (if any) expires or (b) a "Failed" custody signal for 1609 that bundle is received at that node. 1611 Upon determination of custody transfer failure, the action taken by 1612 the bundle protocol agent is implementation-specific and may depend 1613 on the nature of the failure. For example, if custody transfer 1614 failure was inferred from expiration of a custody transfer timer or 1615 was asserted by a "Failed" custody signal with the "Depleted storage" 1616 reason code, the bundle protocol agent might choose to re-forward the 1617 bundle, possibly on a different route (Section 5.4). Receipt of a 1618 "Failed" custody signal with the "Redundant reception" reason code, 1619 on the other hand, might cause the bundle protocol agent to release 1620 custody of the bundle and to revise its algorithm for computing 1621 countdown intervals for custody transfer timers. 1623 5.13. Bundle Deletion 1625 The steps in deleting a bundle are: 1627 Step 1: If the retention constraint "Custody accepted" currently 1628 prevents this bundle from being discarded, and the destination of 1629 the bundle is a singleton endpoint, then: 1631 * Custody of the node is released as described in Section 5.10.2. 1633 * A bundle deletion status report citing the reason for deletion 1634 must be generated, destined for the bundle's report-to endpoint 1635 ID. 1637 Otherwise, if the "request reporting of bundle deletion" flag in 1638 the bundle's status report request field is set to 1, then a 1639 bundle deletion status report citing the reason for deletion 1640 should be generated, destined for the bundle's report-to endpoint 1641 ID. 1643 Step 2: All of the bundle's retention constraints must be removed. 1645 5.14. Discarding a Bundle 1647 As soon as a bundle has no remaining retention constraints it may be 1648 discarded. 1650 5.15. Canceling a Transmission 1652 When requested to cancel a specified transmission, where the bundle 1653 created upon initiation of the indicated transmission has not yet 1654 been discarded, the bundle protocol agent must delete that bundle for 1655 the reason "transmission canceled". For this purpose, the procedure 1656 defined in Section 5.13 must be followed. 1658 5.16. Polling 1660 When requested to poll a specified registration that is in Passive 1661 state, the bundle protocol agent must immediately deliver the least 1662 recently received bundle that is deliverable subject to the indicated 1663 registration, if any. 1665 6. Administrative Record Processing 1667 6.1. Administrative Records 1669 Administrative records are standard application data units that are 1670 used in providing some of the features of the Bundle Protocol. Two 1671 types of administrative records have been defined to date: bundle 1672 status reports and custody signals. 1674 Every administrative record consists of a four-bit record type code 1675 followed by four bits of administrative record flags, followed by 1676 record content in type-specific format. Record type codes are 1677 defined as follows: 1679 +---------+--------------------------------------------+ 1680 | Value | Meaning | 1681 +=========+============================================+ 1682 | 0001 | Bundle status report. | 1683 +---------+--------------------------------------------+ 1684 | 0010 | Custody signal. | 1685 +---------+--------------------------------------------+ 1686 | (other) | Reserved for future use. | 1687 +---------+--------------------------------------------+ 1689 Figure 8: Administrative Record Type Codes. 1691 +---------+--------------------------------------------+ 1692 | Value | Meaning | 1693 +=========+============================================+ 1694 | 0001 | Record is for a fragment; fragment | 1695 | | offset and length fields are present. | 1696 +---------+--------------------------------------------+ 1697 | (other) | Reserved for future use. | 1698 +---------+--------------------------------------------+ 1700 Figure 9: Administrative Record Flags. 1702 All time values in administrative records are UTC times expressed in 1703 "DTN time" representation. A DTN time consists of an SDNV indicating 1704 the number of seconds since the start of the year 2000, followed by 1705 an SDNV indicating the number of nanoseconds since the start of the 1706 indicated second. 1708 The contents of the various types of administrative records are 1709 described below. 1711 6.1.1. Bundle Status Reports 1713 The transmission of 'bundle status reports' under specified 1714 conditions is an option that can be invoked when transmission of a 1715 bundle is requested. These reports are intended to provide 1716 information about how bundles are progressing through the system, 1717 including notices of receipt, custody transfer, forwarding, final 1718 delivery, and deletion. They are transmitted to the Report-to 1719 endpoints of bundles. 1721 +----------------+----------------+----------------+----------------+ 1722 | Status Flags | Reason code | Fragment offset (*) (if 1723 +----------------+----------------+----------------+----------------+ 1724 present) | Fragment length (*) (if present) | 1725 +----------------+----------------+----------------+----------------+ 1726 | Time of receipt of bundle X (a DTN time, if present) | 1727 +----------------+----------------+----------------+----------------+ 1728 | Time of custody acceptance of bundle X (a DTN time, if present) | 1729 +----------------+----------------+----------------+----------------+ 1730 | Time of forwarding of bundle X (a DTN time, if present) | 1731 +----------------+----------------+----------------+----------------+ 1732 | Time of delivery of bundle X (a DTN time, if present) | 1733 +----------------+----------------+----------------+----------------+ 1734 | Time of deletion of bundle X (a DTN time, if present) | 1735 +----------------+----------------+----------------+----------------+ 1736 | Copy of bundle X's Creation Timestamp time (*) | 1737 +----------------+----------------+----------------+----------------+ 1738 | Copy of bundle X's Creation Timestamp sequence number (*) | 1739 +----------------+----------------+----------------+----------------+ 1740 | Length of X's source endpoint ID (*) | Source 1741 +----------------+---------------------------------+ + 1742 endpoint ID of bundle X (variable) | 1743 +----------------+----------------+----------------+----------------+ 1745 Figure 10: Bundle status report format 1747 (*) Notes: 1749 The Fragment Offset field, if present, is an SDNV and is therefore 1750 variable-length. A three-octet SDNV is shown here for convenience in 1751 representation. 1753 The Fragment Length field, if present, is an SDNV and is therefore 1754 variable-length. A three-octet SDNV is shown here for convenience in 1755 representation. 1757 The Creation Timestamp fields replicate the Creation Timestamp fields 1758 in the primary block of the subject bundle. As such they are SDNVs 1759 (see 3.5.1 above) and are therefore variable-length. Four-octet 1760 SDNVs are shown here for convenience in representation. 1762 The source endpoint ID length field is an SDNV and is therefore 1763 variable-length. A three-octet SDNV is shown here for convenience in 1764 representation. 1766 The fields in a bundle status report are: 1768 Status Flags: A 1-byte field containing the following flags: 1770 +----------+--------------------------------------------+ 1771 | Value | Meaning | 1772 +==========+============================================+ 1773 | 00000001 | Reporting node received bundle. | 1774 +----------+--------------------------------------------+ 1775 | 00000010 | Reporting node accepted custody of bundle.| 1776 +----------+--------------------------------------------+ 1777 | 00000100 | Reporting node forwarded the bundle. | 1778 +----------+--------------------------------------------+ 1779 | 00001000 | Reporting node delivered the bundle. | 1780 +----------+--------------------------------------------+ 1781 | 00010000 | Reporting node deleted the bundle. | 1782 +----------+--------------------------------------------+ 1783 | 00100000 | Unused. | 1784 +----------+--------------------------------------------+ 1785 | 01000000 | Unused. | 1786 +----------+--------------------------------------------+ 1787 | 10000000 | Unused. | 1788 +----------+--------------------------------------------+ 1790 Figure 11: Status Flags for Bundle Status Reports 1792 Reason Code: A 1-byte field explaining the value of the flags in 1793 the status flags byte. The list of status report reason codes 1794 provided here is neither exhaustive nor exclusive; supplementary 1795 DTN protocol specifications (including, but not restricted to, the 1796 Bundle Security Protocol [BSP]) may define additional reason 1797 codes. Status report reason codes are defined as follows: 1799 +---------+--------------------------------------------+ 1800 | Value | Meaning | 1801 +=========+============================================+ 1802 | 0x00 | No additional information. | 1803 +---------+--------------------------------------------+ 1804 | 0x01 | Lifetime expired. | 1805 +---------+--------------------------------------------+ 1806 | 0x02 | Forwarded over unidirectional link. | 1807 +---------+--------------------------------------------+ 1808 | 0x03 | Transmission canceled. | 1809 +---------+--------------------------------------------+ 1810 | 0x04 | Depleted storage. | 1811 +---------+--------------------------------------------+ 1812 | 0x05 | Destination endpoint ID unintelligible. | 1813 +---------+--------------------------------------------+ 1814 | 0x06 | No known route to destination from here. | 1815 +---------+--------------------------------------------+ 1816 | 0x07 | No timely contact with next node on route.| 1817 +---------+--------------------------------------------+ 1818 | 0x08 | Block unintelligible. | 1819 +---------+--------------------------------------------+ 1820 | (other) | Reserved for future use. | 1821 +---------+--------------------------------------------+ 1823 Figure 12: Status Report Reason Codes 1825 Fragment Offset: If the bundle fragment bit is set in the status 1826 flags, then the offset (within the original application data unit) 1827 of the payload of the bundle that caused the status report to be 1828 generated is included here. 1830 Fragment length: If the bundle fragment bit is set in the status 1831 flags, then the length of the payload of the subject bundle is 1832 included here. 1834 Time of Receipt (if present): If the bundle-received bit is set in 1835 the status flags, then a DTN time indicating the time at which the 1836 bundle was received at the reporting node is included here. 1838 Time of Custody Acceptance (if present): If the custody-accepted 1839 bit is set in the status flags, then a DTN time indicating the 1840 time at which custody was accepted at the reporting node is 1841 included here. 1843 Time of Forward (if present): If the bundle-forwarded bit is set in 1844 the status flags, then a DTN time indicating the time at which the 1845 bundle was first forwarded at the reporting node is included here. 1847 Time of Delivery (if present): If the bundle-delivered bit is set 1848 in the status flags, then a DTN time indicating the time at which 1849 the bundle was delivered at the reporting node is included here. 1851 Time of Deletion (if present): If the bundle-deleted bit is set in 1852 the status flags, then a DTN time indicating the time at which the 1853 bundle was deleted at the reporting node is included here. 1855 Creation Timestamp of Subject Bundle: A copy of the creation 1856 timestamp of the bundle that caused the status report to be 1857 generated. 1859 Length of Source Endpoint ID: The length in bytes of the source 1860 endpoint ID of the bundle that caused the status report to be 1861 generated. 1863 Source Endpoint ID text: The text of the source endpoint ID of the 1864 bundle that caused the status report to be generated. 1866 6.1.2. Custody Signals 1868 Custody signals are administrative records that effect custody 1869 transfer operations. They are transmitted to the endpoints that are 1870 the current custodians of bundles. 1872 Custody signals have the following format. 1874 Custody Signal regarding bundle 'X': 1876 +----------------+----------------+----------------+----------------+ 1877 | Status | Fragment offset (*) (if present) | 1878 +----------------+----------------+----------------+----------------+ 1879 | Fragment length (*) (if present) | 1880 +----------------+----------------+----------------+----------------+ 1881 | Time of signal (a DTN time) | 1882 +----------------+----------------+----------------+----------------+ 1883 | Copy of bundle X's Creation Timestamp time (*) | 1884 +----------------+----------------+----------------+----------------+ 1885 | Copy of bundle X's Creation Timestamp sequence number (*) | 1886 +----------------+----------------+----------------+----------------+ 1887 | Length of X's source endpoint ID (*) | Source 1888 +----------------+---------------------------------+ + 1889 endpoint ID of bundle X (variable) | 1890 +----------------+----------------+----------------+----------------+ 1892 Figure 13: Custody signal format. 1894 (*) Notes: 1896 The Fragment Offset field, if present, is an SDNV and is therefore 1897 variable-length. A three-octet SDNV is shown here for convenience in 1898 representation. 1900 The Fragment Length field, if present, is an SDNV and is therefore 1901 variable-length. A four-octet SDNV is shown here for convenience in 1902 representation. 1904 The Creation Timestamp fields replicate the Creation Timestamp fields 1905 in the primary block of the subject bundle. As such they are SDNVs 1906 (see Section 4.5.1 above) and are therefore variable-length. Four- 1907 octet SDNVs are shown here for convenience in representation. 1909 The source endpoint ID length field is an SDNV and is therefore 1910 variable-length. A three-octet SDNV is shown here for convenience in 1911 representation. 1913 The fields in a custody signal are: 1915 Status: A 1-byte field containing a 1-bit "custody transfer 1916 succeeded" flag followed by a 7-bit reason code explaining the 1917 value of that flag. Custody signal reason codes are defined as 1918 follows: 1920 +---------+--------------------------------------------+ 1921 | Value | Meaning | 1922 +=========+============================================+ 1923 | 0x00 | No additional information. | 1924 +---------+--------------------------------------------+ 1925 | 0x01 | Reserved for future use. | 1926 +---------+--------------------------------------------+ 1927 | 0x02 | Reserved for future use. | 1928 +---------+--------------------------------------------+ 1929 | 0x03 | Redundant reception (reception by a node | 1930 | | that is a custodial node for this bundle).| 1931 +---------+--------------------------------------------+ 1932 | 0x04 | Depleted storage. | 1933 +---------+--------------------------------------------+ 1934 | 0x05 | Destination endpoint ID unintelligible. | 1935 +---------+--------------------------------------------+ 1936 | 0x06 | No known route to destination from here. | 1937 +---------+--------------------------------------------+ 1938 | 0x07 | No timely contact with next node on route.| 1939 +---------+--------------------------------------------+ 1940 | 0x08 | Block unintelligible. | 1941 +---------+--------------------------------------------+ 1942 | (other) | Reserved for future use. | 1943 +---------+--------------------------------------------+ 1945 Figure 14: Custody Signal Reason Codes 1947 Fragment offset: If the bundle fragment bit is set in the status 1948 flags, then the offset (within the original application data unit) 1949 of the payload of the bundle that caused the status report to be 1950 generated is included here. 1952 Fragment length: If the bundle fragment bit is set in the status 1953 flags, then the length of the payload of the subject bundle is 1954 included here. 1956 Time of Signal: A DTN time indicating the time at which the signal 1957 was generated. 1959 Creation Timestamp of Subject Bundle: A copy of the creation 1960 timestamp of the bundle to which the signal applies. 1962 Length of Source Endpoint ID: The length in bytes of the source 1963 endpoint ID of the bundle to which the signal applied. 1965 Source Endpoint ID text: The text of the source endpoint ID of the 1966 bundle to which the signal applies. 1968 6.2. Generation of Administrative Records 1970 Whenever the application agent's administrative element is directed 1971 by the bundle protocol agent to generate an administrative record 1972 with reference to some bundle, the following procedure must be 1973 followed: 1975 Step 1: The administrative record must be constructed. If the 1976 referenced bundle is a fragment, the administrative record must 1977 have the Fragment flag set and must contain the fragment offset 1978 and fragment length fields; the value of the fragment offset field 1979 must be the value of the referenced bundle's fragment offset, and 1980 the value of the fragment length field must be the length of the 1981 referenced bundle's payload. 1983 Step 2: A request for transmission of a bundle whose payload is 1984 this administrative record must be presented to the bundle 1985 protocol agent. 1987 6.3. Reception of Custody Signals 1989 For each received custody signal that has the Custody Transfer 1990 Succeeded flag set to 1, the administrative element of the 1991 application agent must direct the bundle protocol agent to follow the 1992 custody transfer success procedure in Section 5.11. 1994 For each received custody signal that has the Custody Transfer 1995 Succeeded flag set to 0, the administrative element of the 1996 application agent must direct the bundle protocol agent to follow the 1997 custody transfer failure procedure in Section 5.12. 1999 7. Services Required of the Convergence Layer 2001 7.1. The Convergence Layer 2003 The successful operation of the end-to-end bundle protocol depends on 2004 the operation of underlying protocols at what is termed the 2005 "convergence layer"; these protocols accomplish communication between 2006 nodes. A wide variety of protocols may serve this purpose, so long 2007 as each convergence layer protocol adapter provides a defined minimal 2008 set of services to the bundle protocol agent. This convergence layer 2009 service specification enumerates those services. 2011 7.2. Summary of Convergence Layer Services 2013 Each convergence layer protocol adapter is expected to provide the 2014 following services to the bundle protocol agent: 2016 o sending a bundle to all bundle nodes in the minimum reception 2017 group of the endpoint identified by a specified endpoint ID that 2018 are reachable via the convergence layer protocol; 2020 o delivering to the bundle protocol agent a bundle that was sent by 2021 a remote bundle node via the convergence layer protocol. 2023 The convergence layer service interface specified here is neither 2024 exhaustive nor exclusive. That is, supplementary DTN protocol 2025 specifications (including, but not restricted to, the Bundle Security 2026 Protocol [BSP]) may expect convergence layer adapters which serve BP 2027 implementations conforming to those protocols to provide additional 2028 services. 2030 8. Security Considerations 2032 The bundle protocol has taken security into concern from the outset 2033 of its design. It was always assumed that security services would be 2034 needed in the use of the bundle protocol. As a result, the bundle 2035 protocol security architecture and the available security services 2036 are specified in an accompanying document, the Bundle Security 2037 Protocol specification [BSP]; an informative overview of this 2038 architecture is provided in [SECO]. 2040 The bundle protocol has been designed with the notion that it will be 2041 run over networks with scarce resources. For example, the networks 2042 might have limited bandwidth, limited connectivity, constrained 2043 storage in relay nodes, etc. Therefore, the bundle protocol must 2044 ensure that only those entities authorized to send bundles over such 2045 constrained environments are actually allowed to do so. All 2046 unauthorized entities should be prevented from consuming valuable 2047 resources. 2049 Likewise, because of the potentially long latencies and delays 2050 involved in the networks that make use of the bundle protocol, data 2051 sources should be concerned with the integrity of the data received 2052 at the intended destination(s) and may also be concerned with 2053 ensuring confidentiality of the data as it traverses the network. 2054 Without integrity, the bundle payload data might be corrupted while 2055 in transit without the destination able to detect it. Similarly, the 2056 data source can be concerned with ensuring that the data can only be 2057 used by those authorized; hence the need for confidentiality. 2059 Internal to the bundle-aware overlay network, the bundle nodes should 2060 be concerned with the authenticity of other bundle nodes as well as 2061 the preservation of bundle payload data integrity as it is forwarded 2062 between bundle nodes. 2064 As a result, bundle security is concerned with the authenticity, 2065 integrity, and confidentiality of bundles conveyed among bundle 2066 nodes. This is accomplished via the use of three, independent 2067 security specific bundle blocks which may be used together to provide 2068 multiple bundle security services or independently of one another, 2069 depending on perceived security threats, mandated security 2070 requirements, and security policies that must be enforced. 2072 The Bundle Authentication Block (BAB) ensures the authenticity and 2073 integrity of bundles on a hop-by-hop basis between bundle nodes. The 2074 BAB allows each bundle node to verify a bundle's authenticity before 2075 processing or forwarding the bundle. In this way, entities that are 2076 not authorized to send bundles will have unauthorized transmissions 2077 blocked by security-aware bundle nodes. 2079 Additionally, to provide "security-source" to "security-destination" 2080 bundle authenticity and integrity, the Payload Security Block (PSB) 2081 is used. A "security-source" may not actually be the origination 2082 point of the bundle but instead may be the first point along the path 2083 that is security-aware and is able to apply security services. For 2084 example, an enclave of networked systems may generate bundles but 2085 only their gateway may be required and/or able to apply security 2086 services. The PSB allows any security-enabled entity along the 2087 delivery path, in addition to the "security-destination" (the 2088 recipient counterpart to the "security-source"), to ensure the 2089 bundle's authenticity. 2091 Finally, to provide payload confidentiality, the use of the 2092 Confidentiality Block (CB) is available. The bundle payload may be 2093 encrypted to provide "security-source" to "security-destination" 2094 payload confidentiality/privacy. The CB indicates the cryptographic 2095 algorithm and key IDs that were used to encrypt the payload. 2097 Note that removal of strings from the dictionary at a given point in 2098 a bundle's end-to-end path, and attendant adjustment of endpoint ID 2099 references in the blocks of that bundle, may make it necessary to re- 2100 compute values in one or more of the bundle's security blocks. 2102 Bundle security must not be invalidated by forwarding nodes even 2103 though they themselves might not use the Bundle Security Protocol. 2104 In particular, the sequencing of the blocks in a forwarded bundle 2105 must not be changed as it transits a node; received blocks must be 2106 transmitted in the same relative order as that in which they were 2107 received. While blocks may be added to bundles as they transit 2108 intermediate nodes, removal of blocks that do not have their 'Discard 2109 block if it can't be processed' flag in the block processing control 2110 flags set to 1 may cause security to fail. 2112 Inclusion of the Bundle Security Protocol in any Bundle Protocol 2113 implementation is RECOMMENDED. Use of the Bundle Security Protocol 2114 in Bundle Protocol operations is OPTIONAL. 2116 9. IANA Considerations 2118 The "dtn:" URI scheme has been provisionally registered by IANA. See 2119 http://www.iana.org/assignments/uri-schemes.html for the latest 2120 details. 2122 10. References 2124 10.1. Normative References 2126 [IPR] Bradner, S., "Intellectual Property Rights in IETF 2127 Technology", RFC 3979, BCP 79, March 2005. 2129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2130 Requirement Levels", BCP 14, RFC 2119, March 1997. 2132 [RGTS] Bradner, S., "IETF Rights in Contributions", RFC 3978, 2133 BCP 78, March 2005. 2135 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2136 Resource Identifier (URI): Generic Syntax", RFC 3986, 2137 STD 66, January 2005. 2139 [URIREG] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 2140 Registration Procedures for New URI Schemes", RFC 4395, 2141 BCP 115, February 2006. 2143 10.2. Informative References 2145 [ARCH] V. Cerf et. al., "Delay-Tolerant Network Architecture", 2146 RFC 4838, April 2007. 2148 [ASN1] "Abstract Syntax Notation One (ASN.1), "ASN.1 Encoding 2149 Rules: Specification of Basic Encoding Rules (BER), 2150 Canonical Encoding Rules (CER) and Distinguished Encoding 2151 Rules (DER)," ITU-T Rec. X.690 (2002) | ISO/IEC 8825- 2152 1:2002", 2003. 2154 [BSP] Symington, S., "Bundle Security Protocol Specification, 2155 work in progress", Work in 2156 progress, draft-irtf-dtnrg-bundle-security-03, 2157 October 2007. 2159 [NTP] Mills, D., "Network Time Protocol (Version 3) 2160 Specification", RFC 1305, March 1992. 2162 [SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, 2163 "Delay-Tolerant Networking Security Overview", Work in 2164 progress, draft-irtf-dtnrg-sec-overview-03, July 2007. 2166 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 2167 Challenged Internets", SIGCOMM 2003 . 2169 [TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A 2170 Tutorial", . 2172 [UTC] Arias, E. and B. Guinot, ""Coordinated universal time UTC: 2173 historical background and perspectives" in Journees 2174 systemes de reference spatio-temporels", 2004. 2176 Appendix A. Contributors 2178 This was an effort of the delay tolerant networking research group. 2179 The following dtnrg participants contributed significant technical 2180 material and/or inputs: Dr. Vinton Cerf of Google, Scott Burleigh, 2181 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 2182 Michael Demmer of the University of California at Berkeley, Robert 2183 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 2184 Kevin Fall of Intel Research, Stephen Farrell of Trinity College 2185 Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of Ohio 2186 University (most of Section 4.1), and Howard Weiss of SPARTA, Inc. 2187 (text of Section 8) . 2189 Appendix B. Comments 2191 Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay 2192 Tolerant Networking Research Group (DTNRG) web site is located at 2193 http://www.dtnrg.org. 2195 Authors' Addresses 2197 Keith L. Scott 2198 The MITRE Corporation 2199 7515 Colshire Drive 2200 McLean, VA 21102 2201 US 2203 Phone: +1 703 983 6547 2204 Fax: +1 703 983 7142 2205 Email: kscott@mitre.org 2207 Scott Burleigh 2208 NASA Jet Propulsion Laboratory 2209 4800 Oak Grove Dr. 2210 Pasadena, CA 91109-8099 2211 US 2213 Phone: +1 818 393 3353 2214 Fax: +1 818 354 1075 2215 Email: Scott.Burleigh@jpl.nasa.gov 2217 Full Copyright Statement 2219 Copyright (C) The IETF Trust (2007). 2221 This document is subject to the rights, licenses and restrictions 2222 contained in BCP 78, and except as set forth therein, the authors 2223 retain all their rights. 2225 This document and the information contained herein are provided on an 2226 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2227 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2228 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2229 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2230 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2231 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2233 Intellectual Property 2235 The IETF takes no position regarding the validity or scope of any 2236 Intellectual Property Rights or other rights that might be claimed to 2237 pertain to the implementation or use of the technology described in 2238 this document or the extent to which any license under such rights 2239 might or might not be available; nor does it represent that it has 2240 made any independent effort to identify any such rights. Information 2241 on the procedures with respect to rights in RFC documents can be 2242 found in BCP 78 and BCP 79. 2244 Copies of IPR disclosures made to the IETF Secretariat and any 2245 assurances of licenses to be made available, or the result of an 2246 attempt made to obtain a general license or permission for the use of 2247 such proprietary rights by implementers or users of this 2248 specification can be obtained from the IETF on-line IPR repository at 2249 http://www.ietf.org/ipr. 2251 The IETF invites any interested party to bring to its attention any 2252 copyrights, patents or patent applications, or other proprietary 2253 rights that may cover technology that may be required to implement 2254 this standard. Please address the information to the IETF at 2255 ietf-ipr@ietf.org. 2257 Acknowledgment 2259 Funding for the RFC Editor function is provided by the IETF 2260 Administrative Support Activity (IASA).