idnits 2.17.1 draft-irtf-dtnrg-bundle-spec-04.txt: -(171): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(192): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(205): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(216): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(223): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(346): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(893): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1214): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1258): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1841): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 on line 1963. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1940. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1947. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1953. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 26 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1757 has weird spacing: '...cceeded flag ...' == Line 1762 has weird spacing: '...cceeded flag ...' == Line 1771 has weird spacing: '... the operat...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ASN1' is mentioned on line 541, but not defined == Unused Reference: 'RFC3978' is defined on line 1875, but no explicit reference was found in the text == Unused Reference: 'RFC3979' is defined on line 1878, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1899, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 2717 (Obsoleted by RFC 4395) == Outdated reference: A later version (-08) exists of draft-irtf-dtnrg-arch-03 -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '4') (Obsoleted by RFC 5905) == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-00 == Outdated reference: A later version (-06) exists of draft-irtf-dtnrg-sec-overview-00 Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay Tolerant Networking Research Group K. Scott 3 Internet Draft The MITRE Corporation 4 5 November 2005 S. Burleigh 6 Expires: May 2006 Jet Propulsion Laboratory 8 Bundle Protocol Specification 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of BCP 16 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 document was produced within the IRTF's Delay Tolerant 35 Networking Research Group (DTNRG). See http://www.dtnrg.org for more 36 information. 38 Abstract 40 This document describes the end-to-end protocol, header formats, and 41 abstract service description for the exchange of messages (bundles) 42 in Delay Tolerant Networking (DTN). 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC-2119 [1]. 50 Table of Contents 52 1. Introduction..........................................3 53 2. Service Description...................................4 54 2.1 Definitions...........................................4 55 2.2 Implementation architectures..........................8 56 2.3 Services offered by bundle protocol agents............9 57 3. Bundle Format........................................10 58 3.1 Canonical Bundle Header Format.......................10 59 3.2 Bundle Processing Flags..............................10 60 3.3 Header Processing Flags..............................11 61 3.4 Self-Delimiting Numeric Values (SDNV)................11 62 3.5 Endpoint IDs.........................................12 63 3.6 Formats of Bundle Headers............................13 64 3.6.1 Primary Bundle Header................................15 65 3.6.2 Bundle Payload Header................................18 66 4. Bundle Processing....................................18 67 4.1 Generation of administrative records.................19 68 4.2 Bundle transmission..................................19 69 4.3 Bundle dispatching...................................20 70 4.4 Bundle forwarding....................................20 71 4.4.1 Forwarding Contraindicated...........................21 72 4.4.2 Forwarding Failed....................................22 73 4.5 Bundle expiration....................................22 74 4.6 Bundle reception.....................................23 75 4.7 Local bundle delivery................................23 76 4.8 Bundle Fragmentation.................................24 77 4.9 Application Data Unit Reassembly.....................25 78 4.10 Custody transfer.....................................26 79 4.10.1 Custody acceptance...................................26 80 4.10.2 Custody release......................................27 81 4.11 Custody transfer success.............................27 82 4.12 Custody transfer failure.............................27 83 4.13 Bundle deletion......................................28 84 4.14 Discarding a bundle..................................28 85 4.15 Canceling a transmission.............................28 86 4.16 Polling..............................................28 87 4.17 Acknowledging an application data unit...............28 88 5. Administrative record processing.....................29 89 5.1 Administrative records...............................29 90 5.1.1 Bundle Status Reports................................29 91 5.1.2 Custody Signals......................................33 92 5.2 Generation of administrative records.................35 93 5.3 Reception of custody signals.........................36 94 6. Services Required of the Convergence Layer...........36 95 6.1 The Convergence Layer................................36 96 7. Security Considerations..............................37 97 8. IANA Considerations..................................38 98 9. Normative References.................................38 99 10. Informative References...............................38 101 1. Introduction 103 This document describes version 4 of the Delay Tolerant 104 Networking (DTN) "bundle" protocol (BP). Delay Tolerant Networking 105 is an end-to-end architecture providing communications in and/or 106 through highly stressed environments. Stressed networking 107 environments include those with intermittent connectivity, large 108 and/or variable delays, and high bit error rates. To provide its 109 services, BP sits at the application layer of some number of 110 constituent internets, forming a store-and-forward overlay network. 111 Key capabilities of BP include: 113 o Custody-based retransmission 114 o Ability to cope with intermittent connectivity 115 o Ability to take advantage of scheduled, predicted, and 116 opportunistic connectivity (in addition to continuous 117 connectivity) 118 o Late binding of overlay network endpoint identifiers to 119 constituent internet addresses 121 For descriptions of these capabilities and the rationale for the DTN 122 architecture, see [2] and [8]. [3] contains a tutorial-level 123 overview of DTN concepts. 125 BP's location within the standard protocol stack is as shown in 126 Figure 1. BP uses the 'native' internet protocols for communications 127 within a given internet. Note that 'internet' in the preceding is 128 used in a general sense and does not necessarily refer to TCP/IP. 129 The interface between the common bundle protocol and a specific 130 internetwork protocol suite is termed a "convergence layer adapter". 131 Figure 1 shows three distinct transport and network protocols 132 (denoted T1/N1, T2,N2, and T3/N3). 134 +-----------+ +-----------+ 135 | BP app | | BP app | 136 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 137 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 138 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 139 | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | 140 | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | 141 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 142 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 143 +-----------+ +------------+ +-------------+ +-----------+ 145 | | | | 146 |<-- An internet --->| |<--- An internet --->| 147 | | | | 149 Figure 1: The bundle protocol sits at the application layer of the 150 Internet model. 152 This document describes the format of the protocol data units (called 153 bundles) passed between entities participating in BP communications. 154 The entities are referred to as "bundle nodes". This document does 155 not address: 157 o Operations in the convergence layer adapters that bundle nodes 158 use to transport data through specific types of internet. 159 (However, the document does discuss the services that must be 160 provided by each adapter at the convergence layer.) 162 o The bundle routing algorithm. 164 o Mechanisms for populating the routing or forwarding information 165 bases of bundle nodes. 167 2. Service Description 169 2.1 Definitions 171 Bundle � A bundle is a protocol data unit of the DTN bundle protocol. 172 Multiple instances of the same bundle (the same unit of DTN protocol 173 data) might exist concurrently in different parts of a network - 174 possibly in different representations - in the memory local to one or 175 more bundle nodes and/or in transit between nodes. In the context of 176 the operation of a bundle node, a bundle is an instance of some 177 bundle in the network that is in that node's local memory. 179 Bundle payload � A bundle payload (or simply "payload") is the 180 application data whose conveyance to the bundle's destination is the 181 purpose for the transmission of a given bundle. The terms "bundle 182 content", "bundle payload", and "payload" are used interchangeably in 184 response to a bundle transmission request is the application data 185 unit whose location is provided as a parameter to that request. The 186 nominal payload for a bundle forwarded in response to reception of 187 that bundle is the payload of the received bundle. 189 Fragment � A fragment is a bundle whose payload header contains a 190 fragmentary payload. A fragmentary payload is either the first N 191 bytes or the last N bytes of some other payload � either a nominal 192 payload or a fragmentary payload � of length M, such that 0 < N < M. 194 Bundle node � A bundle node (or, in the context of this document, 195 simply a "node") is any entity that can send and/or receive bundles. 196 In the most familiar case a bundle node is instantiated as a single 197 process running on a general-purpose computer, but in general the 198 definition is meant to be broader; a bundle node might alternatively 199 be a thread, an object in an object-oriented operating system, a 200 special-purpose hardware device, etc. Each bundle node has three 201 conceptual components, defined below: a "bundle protocol agent", a 202 set of zero or more "convergence layer adapters", and an "application 203 agent". 205 Bundle protocol agent � The bundle protocol agent (BPA) of a node is 206 the node component that offers the BP services and executes the 207 procedures of the Bundle Protocol. The manner in which it does so is 208 wholly an implementation matter. For example, BPA functionality 209 might be coded into each node individually; it might be implemented 210 as a shared library that is used in common by any number of bundle 211 nodes on a single computer; it might be implemented as a daemon whose 212 services are invoked via inter-process or network communication by 213 any number of bundle nodes on one or more computers; it might be 214 implemented in hardware. 216 Convergence layer adapters � A convergence layer adapter (CLA) sends 217 and receives bundles on behalf of the BPA, utilizing the services of 218 some 'native' internet protocol that is supported in one of the 219 internets within which the node is functionally located. The manner 220 in which a CLA sends and receives bundles is wholly an implementation 221 matter, exactly as described for the BPA. 223 Application agent � The application agent (AA) of a node is the node 224 component that utilizes the BP services to effect communication for 225 some purpose. The application agent in turn has two elements, an 226 administrative element and an application-specific element. The 227 transmission of, accepts delivery of, and processes application- 228 specific application data units; the only interface between the BPA 229 and the application-specific element of the AA is the BP service 230 interface. The administrative element of an AA constructs and 231 requests transmission of administrative records (status reports and 232 custody signals), and it accepts delivery of and processes any 233 custody signals that the node receives; in addition to the BP service 234 interface, there is a (conceptual) private control interface between 235 the BPA and the administrative element of the AA that enables each to 236 direct the other to take action under specific circumstances. In the 237 case of a node that serves simply as a "router" in the overlay 238 network, the AA may have no application-specific element at all; the 239 application-specific elements of other nodes' AAs may perform 240 arbitrarily complex application functions, perhaps even offering 241 multiplexed DTN communication services to a number of other 242 applications. As with the BPA, the manner in which the AA performs 243 its functions is wholly an implementation matter; in particular, the 244 administrative element of an AA might be built into the library or 245 daemon or hardware that implements the BPA, and the application- 246 specific element of an AA might be implemented either in software or 247 in hardware. 249 Bundle endpoint � A bundle endpoint (or simply "endpoint") is a set 250 of zero or more bundle nodes that all identify themselves for BP 251 purposes by some single text string, called a "bundle endpoint ID" 252 (or, in this document, simply "endpoint ID"; endpoint IDs are 253 described in detail in 3.5 below). The special case of an endpoint 254 that never contains more than one node is termed a "singleton" 255 endpoint; every bundle node must be a member of at least one 256 singleton endpoint. Singletons are the most familiar sort of 257 endpoint, but in general the endpoint notion is meant to be broader. 258 For example, the nodes in a sensor network might constitute a set of 259 bundle nodes that identify themselves by a single common endpoint ID 260 and thus form a single bundle endpoint. **Note** too that a given 261 bundle node might identify itself by multiple endpoint IDs and thus 262 be a member of multiple bundle endpoints. 264 Forwarding - When the bundle protocol agent of a node determines that 265 a bundle must be "forwarded" to an endpoint, it causes the bundle to 266 be sent to all of the nodes that the bundle protocol agent currently 267 believes are in the "minimum reception group" of that endpoint. The 268 minimum reception group of an endpoint may be any one of the 269 following: (a) ALL of the nodes registered in an endpoint that is 270 endpoint is functionally similar to "multicast" operations in the 271 Internet, though possibly very different in implementation); (b) ANY 272 N of the nodes registered in an endpoint that is permitted to contain 273 multiple nodes, where N is in the range from zero to the cardinality 274 of the endpoint (in which case forwarding to the endpoint is 275 functionally similar to "anycast" operations in the Internet); (c) 276 THE SOLE NODE registered in a singleton endpoint (in which case 277 forwarding to the endpoint is functionally similar to "unicast" 278 operations in the Internet). The nature of the minimum reception 279 group for a given endpoint can be determined from the endpoint's ID 280 (again, see 3.5 below): for some endpoint ID "schemes", the nature of 281 the minimum reception group is fixed - in a manner that is defined by 282 the scheme - for all endpoints identified under the scheme; for other 283 schemes, the nature of the minimum reception group is indicated by 284 some lexical feature of the "scheme-specific part" of the endpoint 285 ID, in a manner that is defined by the scheme. 287 Registration � A registration is the state machine characterizing a 288 given node's membership in a given endpoint. Any number of 289 registrations may be concurrently associated with a given endpoint, 290 and any number of registrations may be concurrently associated with a 291 given node. Any single registration must at any time be in one of 292 two states: Active, Passive. A registration always has an associated 293 "delivery failure action", the action that is to be taken when a 294 bundle that is "deliverable" (see below) subject to that registration 295 is received at a time when the registration is in the Passive state. 296 Delivery failure action must be one of the following: 298 o defer "delivery" (see below) of the bundle subject to this 299 registration until (a) this bundle is the least recently 300 received of all bundles currently deliverable subject to this 301 registration and (b) either the registration is polled or else 302 the registration is in Active state; 304 o "abandon" (see below) delivery of the bundle subject to this 305 registration. 307 An additional implementation-specific delivery deferral procedure may 308 optionally be associated with the registration. While the state of a 309 registration is Active, reception of a bundle that is deliverable 310 subject to this registration must cause the bundle to be delivered 311 automatically as soon as it is the least recently received bundle 312 that is currently deliverable subject to the registration. While the 314 deliverable subject to this registration must cause delivery of the 315 bundle to be abandoned or deferred as mandated by the registration's 316 current delivery failure action; in the latter case, any additional 317 delivery deferral procedure associated with the registration must 318 also be performed. 320 Delivery � Upon reception, the processing of a bundle that has been 321 sent to a given node depends on whether or not the receiving node is 322 registered in the bundle's destination endpoint; if it is, and if the 323 payload of the bundle is non-fragmentary (possibly as a result of 324 successful payload reassembly from fragmentary payloads, including 325 the original payload of the received bundle), then the bundle is 326 normally "delivered" to the node's application agent subject to the 327 registration characterizing the node's membership in the destination 328 endpoint. A bundle is considered to have been delivered at a node 329 subject to a registration as soon as the application data unit that 330 is the payload of the bundle, together with relevant metadata (an 331 implementation matter), has been presented to the node's application 332 agent in a manner consistent with the state of that registration and, 333 as applicable, the registration's delivery failure action. 335 Deliverability, Abandonment � A bundle is considered "deliverable" 336 subject to a registration if and only if (a) the bundle's destination 337 endpoint is the endpoint with which the registration is associated, 338 (b) the bundle has not yet been delivered subject to this 339 registration, and (c) delivery of the bundle subject to this 340 registration has not been abandoned. To "abandon" delivery of a 341 bundle subject to a registration is simply to declare it no longer 342 deliverable subject to that registration; normally only 343 registrations' registered delivery failure actions cause deliveries 344 to be abandoned. 346 Deletion, Discarding � A bundle protocol agent "discards" a bundle by 347 simply ceasing all operations on the bundle and functionally erasing 348 all references to it; the specific procedures by which this is 349 accomplished are an implementation matter. Bundles are discarded 350 silently, i.e., the discarding of a bundle does not result in 351 generation of an administrative record. "Retention constraints" are 352 elements of bundle state that prevent a bundle from being discarded; 353 a bundle cannot be discarded while it has any retention constraints. 354 A bundle protocol agent "deletes" a bundle in response to some 355 anomalous condition by notifying the bundle's report-to endpoint of 356 the deletion (provided such notification is warranted; see 4.13 for 357 constraints, enabling the bundle to be discarded. 359 Transmission � A transmission is a sustained effort by a node's 360 bundle protocol agent to cause a bundle to be sent to all nodes in 361 the minimum reception group of some endpoint (which may be the 362 bundle's destination or may be some intermediate forwarding endpoint) 363 in response to a transmission request issued by the node's 364 application agent. Any number of transmissions may be concurrently 365 undertaken by the bundle protocol agent of a given node. 367 Custody � To "accept custody" upon forwarding a bundle is to commit 368 to retaining a copy of the bundle - possibly re-forwarding the bundle 369 when the necessity to do so is determined - until custody of that 370 bundle is "released". Custody of a bundle whose destination is a 371 singleton endpoint is released when either (a) notification is 372 received that some other node has accepted custody of the same 373 bundle, (b) notification is received that the bundle has been 374 delivered at the (sole) node registered in the bundle's destination 375 endpoint, or (c) the bundle is explicitly deleted for some reason, 376 such as lifetime expiration; the condition(s) under which custody of 377 a bundle whose destination is not a singleton endpoint may be 378 released are not defined in this specification. To "refuse custody" 379 of a bundle is to decide not to accept custody of the bundle. A 380 "custodial node" of a bundle is a node that has accepted custody of 381 the bundle and has not yet released that custody. A "custodian" of a 382 bundle is a singleton endpoint whose sole member is one of the 383 bundle's custodial nodes. 385 2.2 Implementation architectures 387 The above definitions are intended to enable the bundle protocol's 388 operations to be specified in a manner that minimizes bias toward any 389 particular implementation architecture. To illustrate the range of 390 interoperable implementation models that might conform to this 391 specification, four example architectures are briefly described 392 below. 394 a) Bundle protocol application server 396 A single bundle protocol application server, constituting a single 397 bundle node, runs as a daemon process on each computer. The daemon's 398 functionality includes all functions of the bundle protocol agent, 399 all convergence layer adapters, and both the administrative and 400 application-specific elements of the application agent. The 401 application-specific element of the application agent functions as a 402 server, offering bundle protocol service over a local area network: 404 it responds to remote procedure calls from application processes (on 405 the same computer and/or remote computers) that need to communicate 406 via the bundle protocol. The server supports its clients by creating 407 a new (conceptual) node for each one and registering each such node 408 in a client-specified endpoint; the conceptual nodes managed by the 409 server function as clients' Bundle Protocol service access points. 411 b) Peer application nodes 413 Any number of bundle protocol application processes, each one 414 constituting a single bundle node, run in ad-hoc fashion on each 415 computer. The functionality of the bundle protocol agent, all 416 convergence layer adapters, and the administrative element of the 417 application agent is provided by a library to which each node process 418 is dynamically linked at run time; the application-specific element 419 of each node's application agent is node-specific application code. 421 c) Sensor network nodes 423 Each node of the sensor network is the self-contained implementation 424 of a single bundle node. All functions of the bundle protocol agent, 425 all convergence layer adapters, and the administrative element of the 426 application agent are implemented in simplified form in ASICs, while 427 the application-specific element of each node's application agent is 428 implemented in a programmable microcontroller. Forwarding is 429 rudimentary: all bundles are forwarded on a hard-coded default route. 431 d) Dedicated bundle router 433 Each computer constitutes a single bundle node that functions solely 434 as a high-performance bundle forwarder. Many standard functions of 435 the bundle protocol agent, the convergence layer adapters, and the 436 administrative element of the application agent are implemented in 437 ASICs, but some functions are implemented in a high-speed processor 438 to enable reprogramming as necessary. The node's application agent 439 has no application-specific element. Substantial non-volatile 440 storage resources are provided, and arbitrarily complex forwarding 441 algorithms are supported. 443 2.3 Services offered by bundle protocol agents 445 The bundle protocol agent of each node is expected to provide the 446 following services to the node's application agent: 448 a) commencing a registration (registering a node in an endpoint); 449 b) terminating a registration; 450 c) switching a registration between Active and Passive state; 451 d) transmitting a bundle to an identified bundle endpoint; 452 e) canceling a transmission; 453 f) polling a registration that is in passive state; 454 g) delivering a received bundle; 455 h) acknowledging receipt of a bundle's contents. 457 3. Bundle Format 459 Each bundle shall be a concatenated sequence of at least two bundle 460 header structures. The first header in the sequence must be a 461 primary bundle header, and no bundle may have more than one primary 462 bundle header. Additional bundle protocol headers of other types may 463 follow the primary header to support extensions to the Bundle 464 Protocol, such as the Bundle Security Protocol. At most one of the 465 headers in the sequence may be a payload header. The last header in 466 the sequence must have the "last header" flag (in its header 467 processing control flags) set to 1; for every other header in the 468 bundle after the primary header, this flag must be set to zero. 470 3.1 Canonical Bundle Header Format 472 Every bundle header of every type other than the primary bundle 473 header comprises the following elements, in this order: 474 o Header type code, expressed as an 8-bit unsigned binary 475 integer. Bundle header type code 1 indicates that the header 476 is a bundle payload header. All other values of the header 477 type code are reserved for future use. 478 o Header processing control flags, a set of eight 1-bit flag 479 values. 480 o Header data length, an unsigned integer expressed as an SDNV 481 (explained below). The Header data length field contains the 482 aggregate length of all remaining fields of the header, i.e., 483 the header-type-specific data fields. 484 o Header-type-specific data fields, whose format and order are 485 type-specific and whose aggregate length in octets is the value 486 of the header data length field. All multi-byte header-type- 487 specific data fields are represented in network byte order. 489 3.2 Bundle Processing Flags 491 The following Boolean processing control flags are present only in 492 the bundle processing control flags byte of the primary bundle header 493 of each bundle: 495 00000001 - Bundle is a fragment. 496 00000010 - Application data unit is an administrative record. 497 00000100 - Bundle must not be fragmented. 498 00001000 - Custody transfer is requested. 499 00010000 - Destination endpoint is a singleton. 500 00100000 - Reserved for future use. 501 01000000 - Reserved for future use. 502 10000000 - Reserved for future use. 504 If the bundle processing control flags indicate that the bundle's 505 application data unit is an administrative record, then the custody 506 transfer requested flag must be zero. If the custody transfer 507 requested flag is 1 then the sending node requests that the receiving 508 node accept custody of the bundle. 510 3.3 Header Processing Flags 512 The following Boolean processing control flags are present in the 513 header processing control flags byte of every bundle header other 514 than the primary bundle header of each bundle: 516 00000001 - Header must be replicated in every fragment. 517 00000010 - Transmit status report if header can't be processed. 518 00000100 - Discard bundle if header can't be processed. 519 00001000 - Last header. 520 00010000 - Reserved for future use. 521 00100000 - Reserved for future use. 522 01000000 - Reserved for future use. 523 10000000 - Reserved for future use. 525 For each bundle whose primary header's bundle processing control 526 flags (see above) indicate that the bundle's application data unit is 527 an administrative record, the "Transmit status report if header can't 528 be processed" flag in the header processing flags element of every 529 other header in the bundle must be zero. 531 3.4 Self-Delimiting Numeric Values (SDNV) 533 The design of the bundle protocol attempts to reconcile minimal 534 consumption of transmission bandwidth with: 535 o extensibility to address requirements not yet identified, and 536 o scalability across a wide range of network scales and payload 537 sizes. 539 A key strategic element in the design is the use of self-delimiting 540 numeric values (SDNVs). The SDNV encoding scheme is closely adapted 541 from the Abstract Syntax Notation One [ASN1] scheme for encoding 542 Object Identifier Arcs. An SDNV is a numeric value encoded in N 543 octets, the last of which has its most significant bit (MSB) set to 544 zero; the MSB of every other octet in the SDNV must be set to 1. The 545 value encoded in an SDNV is the unsigned binary number obtained by 546 concatenating into a single bit string the 7 least significant bits 547 of each octet of the SDNV. 549 The following examples illustrate the encoding scheme for various 550 hexadecimal values. 552 0xABC : 1010 1011 1100 553 is encoded as 554 {100 1010 1} {0 011 1100} 555 = 10010101 00111100 557 0x1234 : 0001 0010 0011 0100 558 = 1 0010 0011 0100 559 is encoded as 560 {10 1 0010 0} {0 011 0100} 561 = 10100100 00110100 563 0x4234 : 0100 0010 0011 0100 564 = 100 0010 0011 0100 565 is encoded as 566 {1000000 1} {1 00 0010 0} {0 011 0100} 567 = 10000001 10000100 00110100 569 0x7F : 0111 1111 570 = 111 1111 571 is encoded as 572 {0 111 1111} 573 = 01111111 575 Note: Care must be taken to make sure that the value to be encoded is 576 (in concept) padded with high-order zero bits to make its bitwise 577 length a multiple of 7 before encoding. Also note that, while there 578 is no theoretical limit on the size of an SDNV field, the overhead of 579 the SDNV scheme is 1/8-th of the bitwise length of the value to be 580 encoded. In order to encode an 64-bit numeric value, an SDNV field 581 of 9 octets is required. 128 bits of overhead would be consumed in 582 encoding a 1024-bit RSA encryption key directly in an SDNV. 584 An SDNV can be used to represent both very large and very small 585 integer values. However, SDNV is clearly not the best way to 586 represent every numeric value. For example, an SDNV is a poor way to 587 represent an integer whose value typically falls in the range 128 to 588 255. In general, though, we believe that SDNV representation of 589 numeric values in bundle headers yields the smallest bundle header 590 sizes without sacrificing scalability. 592 3.5 Endpoint IDs 594 The destinations of bundles are bundle endpoints, identified by text 595 strings termed "endpoint IDs" (see section 2.1). Each endpoint ID 596 conveyed in any bundle header takes the form of a Uniform Resource 597 Identifier (URI; [RFC3986]). As such, each endpoint ID can be 598 characterized as having this general structure: 600 : 602 As used for the purposes of the bundle protocol, neither the length 603 of a scheme name nor the length of an SSP may exceed 1023 bytes. 605 Bundle headers cite a number of endpoint IDs for various purposes of 606 the bundle protocol. Many, though not necessarily all, of the 607 endpoint IDs referred to in the headers of a given bundle are 608 conveyed in the "dictionary" byte array in the bundle's primary 609 header. This array is simply the concatenation of any number of 610 null-terminated scheme names and SSPs. 612 "Endpoint ID references" are used to cite endpoint IDs that are 613 contained in the dictionary; all endpoint ID citations in the primary 614 bundle header are endpoint ID references, and other bundle headers 615 may contain endpoint ID references as well. Each endpoint ID 616 reference is an ordered pair of 16-bit unsigned integers: 618 o The offset, within the dictionary, of the first character of 619 the referenced endpoint ID's scheme name. 621 o The offset, within the dictionary, of the first character of 622 the referenced endpoint ID's SSP. 624 This encoding enables a degree of header compression: when the source 625 and report-to of a bundle are the same endpoint, for example, the 626 text of that endpoint's ID may be cited twice yet appear only once in 627 the dictionary. 629 The scheme identified by the in an endpoint ID is a set 630 of syntactic and semantic rules that fully explain how to parse and 631 interpret the SSP. The set of allowable schemes is effectively 632 unlimited. Any scheme conforming to [RFC2717] may be used in a 633 bundle protocol endpoint ID. In addition, a single additional scheme 634 is defined by the present document: 636 o The "dtn" scheme, which is used at minimum in the 637 representation of the null endpoint ID "dtn:none". The 638 forwarding of a bundle to the null endpoint is never 639 contraindicated, and the minimum reception group for the null 640 endpoint is the empty set. 642 Note that, although the endpoint IDs conveyed in bundle headers are 643 expressed as URIs, implementations of the BP service interface may 644 support expression of endpoint IDs in some internationalized manner 645 (e.g., IRIs; see RFC 3987). 647 3.6 Formats of Bundle Headers 649 This section describes the formats of the primary header and payload 650 header. Rules for processing these headers appear in section 4 of 651 this document. 653 Note that supplementary DTN protocol specifications (including, but 654 not restricted to, the Bundle Security Protocol) may require that BP 655 implementations conforming to those protocols construct and process 656 additional headers. 658 The format of the two basic BP headers is shown in Figure 2 below. 660 Primary Bundle Header 661 +----------------+----------------+----------------+----------------+ 662 | Version | Proc. Flags | COS Flags | SRR Flags | 663 +----------------+----------------+----------------+----------------+ 664 | [Header length (*)] | 665 +----------------+----------------+---------------------------------+ 666 | Destination scheme offset | Destination SSP offset | 667 +----------------+----------------+----------------+----------------+ 668 | Source scheme offset | Source SSP offset | 669 +----------------+----------------+----------------+----------------+ 670 | Report-to scheme offset | Report-to SSP offset | 671 +----------------+----------------+----------------+----------------+ 672 | Custodian scheme offset | Custodian SSP offset | 673 +----------------+----------------+----------------+----------------+ 674 | | 675 + Creation Timestamp (8 bytes) + 676 | | 677 +---------------------------------+---------------------------------+ 678 | Lifetime | 679 +----------------+----------------+----------------+----------------+ 680 | Dictionary length (**) | 681 +----------------+----------------+----------------+----------------+ 682 | Dictionary byte array (variable) | 683 +----------------+----------------+---------------------------------+ 684 | [Fragment offset (***)] | 685 +----------------+----------------+---------------------------------+ 686 | [Total application data unit length (****)] | 687 +----------------+----------------+---------------------------------+ 689 Bundle Payload Header 690 +----------------+----------------+----------------+----------------+ 691 | Header type | Proc. Flags | Header length(*****) | 692 +----------------+----------------+----------------+----------------+ 693 | | 694 | Bundle Payload (variable) | 695 | | 696 / / 697 / / 698 | | 699 +-------------------------------------------------------------------+ 701 Figure 2: Bundle header formats. 702 Notes: 704 (*) The header length field of the Primary Bundle Header is an SDNV 705 and is therefore variable-length. A four-octet SDNV is shown here 706 for convenience in representation. 708 (**) The dictionary length field of the Primary Bundle Header is an 709 SDNV and is therefore variable-length. A four-octet SDNV is shown 710 here for convenience in representation. 712 (***) The fragment offset field of the Primary Bundle Header is 713 present only if the Fragment flag in the header's processing flags 714 byte is set to 1. It is an SDNV and is therefore variable-length; a 715 four-octet SDNV is shown here for convenience in representation. 717 (****) The total application data unit length field of the Primary 718 Bundle Header is present only if the Fragment flag in the header's 719 processing flags byte is set to 1. It is an SDNV and is therefore 720 variable-length; a four-octet SDNV is shown here for convenience in 721 representation. 723 (*****) The header length field of the Payload Header is an SDNV and 724 is therefore variable-length. A two-octet SDNV is shown here for 725 convenience in representation. 727 3.6.1 Primary Bundle Header 729 The primary bundle header contains the basic information needed to 730 route bundles to their destinations. The fields of the primary 731 bundle header are: 733 Version. A 1-byte field indicating the version of the bundle 734 protocol that constructed this header. The present document 735 describes version 0x04 of the bundle protocol. 737 Bundle Processing Control Flags. The Bundle Processing Control Flags 738 field is a 1-byte field that contains the bundle processing 739 control flags discussed in section 3.2 above. 741 Class of Service Flags. The COS Flags byte consists of two (2) bits 742 of priority followed by six (6) bits that are reserved for 743 future use. The two-bit priority field indicates the bundle's 744 priority, with higher values being of higher priority: 00 = 745 bulk, 01 = normal, 10 = expedited, 11 is reserved for future 746 use. 748 Status Report Request Flags. The status report request flags 749 indicate the source node's requests for bundle status report 750 generation. If the bundle processing control flags indicate 751 that the bundle's application data unit is an administrative 752 record, then all status report request flags must be zero. 753 The interpretation of the status report request flags is as 754 follows. 756 Table 1: Status Report Request Flag Meanings 758 +---------+--------------------------------------------+ 759 | Value | Meaning | 760 +=========+============================================+ 761 | 0x00 | No status reports requested. | 762 +---------+--------------------------------------------+ 763 | 0x01 | Request reporting of bundle reception. | 764 +---------+--------------------------------------------+ 765 | 0x02 | Request reporting of custody acceptance. | 766 +---------+--------------------------------------------+ 767 | 0x04 | Request reporting of bundle forwarding. | 768 +---------+--------------------------------------------+ 769 | 0x08 | Request reporting of bundle delivery. | 770 +---------+--------------------------------------------+ 771 | 0x10 | Request reporting of bundle deletion. | 772 +---------+--------------------------------------------+ 773 | 0x20 | Request acknowledgement by application. | 774 +---------+--------------------------------------------+ 775 | 0x40 | Unused. | 776 +---------+--------------------------------------------+ 777 | 0x80 | Unused. | 778 +---------+--------------------------------------------+ 780 Header Length. The Header Length field is an SDNV that contains the 781 aggregate length of all remaining fields of the header. 783 Destination Scheme Offset. The Destination Scheme Offset field 784 contains the offset within the dictionary byte array of the 785 scheme name of the endpoint ID of the bundle's destination, 786 i.e., the endpoint containing the node(s) at which the bundle 787 is to be delivered. 789 Destination SSP Offset. The Destination SSP Offset field contains 790 the offset within the dictionary byte array of the scheme- 791 specific part of the endpoint ID of the bundle's destination. 793 Source Scheme Offset. The Source Scheme Offset field contains the 794 offset within the dictionary byte array of the scheme name of 795 the endpoint ID of the bundle's nominal source, i.e., the 796 endpoint nominally containing the node from which the bundle 797 was initially transmitted. 799 Source SSP Offset. The Source SSP Offset field contains the offset 800 within the dictionary byte array of the scheme-specific part 801 of the endpoint ID of the bundle's nominal source. 803 Report-to Scheme Offset. The Report-to Scheme Offset field contains 804 the offset within the dictionary byte array of the scheme name 805 of the ID of the endpoint to which status reports pertaining 806 to the forwarding and delivery of this bundle are to be 807 transmitted. 809 Report-to SSP Offset. The Report-to SSP Offset field contains the 810 offset within the dictionary byte array of the scheme-specific 811 part of the ID of the endpoint to which status reports 812 pertaining to the forwarding and delivery of this bundle are 813 to be transmitted. 815 Custodian Scheme Offset. The "current custodian endpoint ID" of a 816 primary bundle header identifies an endpoint whose membership 817 includes the node that most recently accepted custody of the 818 bundle upon forwarding this bundle. The Custodian Scheme 819 Offset field contains the offset within the dictionary byte 820 array of the scheme name of the current custodian endpoint ID. 822 Custodian SSP Offset. The Destination SSP Offset field contains the 823 offset within the dictionary byte array of the scheme-specific 824 part of the current custodian endpoint ID. 826 Creation Timestamp. The creation timestamp is an 8-byte field that, 827 together with the source endpoint ID and (if applicable) the 828 fragment offset, serves to identify the bundle. The high- 829 order four bytes of the timestamp are the bundle's creation 830 time while its low-order four bytes are the bundle's creation 831 timestamp sequence number. Bundle creation time is the time - 832 expressed in seconds since the start of the year 2000, on the 833 Coordinated Universal Time (UTC) scale [7] - at which the 834 transmission request was received that resulted in the 835 creation of the bundle. Sequence count is the latest value 836 (as of the time at which that transmission request was 837 received) of a monotonically increasing positive integer 838 counter managed by the source node's bundle protocol agent 839 that may be reset to zero whenever the current time advances 840 by one second. A source Bundle Protocol Agent must never 841 create two distinct bundles with the same source endpoint ID 842 and bundle creation timestamp. The combination of source 843 endpoint ID and bundle creation timestamp therefore serves to 844 identify a single transmission request, enabling it to be 845 acknowledged by the receiving application. 847 Lifetime. The four-byte lifetime field indicates the time at which 848 the bundle's payload will no longer be useful, encoded as a 849 number of seconds past the creation time. When the current 850 time is greater than the creation time plus the lifetime, 851 bundle nodes need no longer retain or forward the bundle; the 852 bundle may be deleted from the network. 854 Dictionary Length. The Dictionary Length field is an SDNV that 855 contains the length of the dictionary byte array. 857 Dictionary. The Dictionary field is an array of bytes formed by 858 concatenating the null-terminated scheme names and SSPs of all 859 endpoint IDs referenced by any fields in this Primary Header 860 together with, potentially, other endpoint IDs referenced by 861 fields in other TBD DTN protocol headers. Its length is given 862 by the value of the Dictionary Length field. 864 Fragment Offset. If the Bundle Processing Control Flags of this 865 Primary header indicate that the bundle is a fragment, then 866 the Fragment Offset field is an SDNV indicating the offset 867 from the start of the original application data unit at which 868 the bytes comprising the payload of this bundle were located. 869 If not, then the Fragment Offset field is omitted from the 870 header. 872 Total Application Data Unit Length. If the Bundle Processing Control 873 Flags of this Primary header indicate that the bundle is a 874 fragment, then the Total Application Data Unit Length field is 875 an SDNV indicating the total length of the original 876 application data unit of which this bundle's payload is a 877 part. If not, then the Total Application Data Unit Length 878 field is omitted from the header. 880 3.6.2 Bundle Payload Header 882 The fields of the bundle payload header are: 884 Header Type. The Header Type field is a 1-byte field that indicates 885 the type of the header. For the bundle payload header this 886 field contains the value 1. 888 Header Processing Control Flags. The Header Processing Control Flags 889 field is a 1-byte field that contains the header processing 890 control flags discussed in section 3.3 above. 892 Header Length. The Header Length field is an SDNV that contains the 893 aggregate length of all remaining fields of the header � which 894 is to say, the length of the bundle's payload. 896 Payload. The application data carried by this bundle. 898 4. Bundle Processing 900 The bundle processing procedures mandated in this section and in 901 section 5 govern the operation of the Bundle Protocol Agent and the 902 Application Agent administrative element of each bundle node. They 903 are neither exhaustive nor exclusive. That is, supplementary DTN 904 protocol specifications (including, but not restricted to, the Bundle 905 Security Protocol) may require that additional measures be taken at 906 specified junctures in these procedures. Such additional measures 907 shall not override or supersede the mandated bundle protocol 908 procedures, except that they may in some cases make these procedures 909 moot by requiring, for example, that implementations conforming to 910 the supplementary protocol terminate the processing of a given 911 incoming or outgoing bundle due to a fault condition recognized by 912 that protocol. 914 4.1 Generation of administrative records 916 All initial transmission of bundles is in response to bundle 917 transmission requests presented by nodes' application agents. When 918 required to "generate" an administrative record (a bundle status 919 report or a custody signal), the bundle protocol agent itself is 920 responsible for causing a new bundle to be transmitted, conveying 921 that record. In concept, the bundle protocol agent discharges this 922 responsibility by directing the administrative element of the node's 923 application agent to construct the record and request its 924 transmission as detailed in section 5 below; in practice, the manner 925 in which administrative record generation is accomplished is an 926 implementation matter, provided the constraints noted in section 5 927 are observed. 929 Notes on administrative record terminology: 931 a. A "bundle reception status report" is a bundle status report with 932 the "reporting node received bundle" flag set to 1. 934 b. A "custody acceptance status report" is a bundle status report 935 with the "reporting node accepted custody of bundle" flag set to 1. 937 c. A "bundle forwarding status report" is a bundle status report with 938 the "reporting node forwarded the bundle" flag set to 1. 940 d. A "bundle delivery status report" is a bundle status report with 941 the "reporting node delivered the bundle" flag set to 1. 943 e. A "bundle deletion status report" is a bundle status report with 944 the "reporting node deleted the bundle" flag set to 1. 946 f. An "acknowledgement status report" is a bundle status report with 947 the "acknowledged by application" flag set to 1. 949 g. A "Succeeded" custody signal is a custody signal with the "custody 950 transfer succeeded" flag set to 1. 952 h. A "Failed" custody signal is a custody signal with the "custody 953 transfer succeeded" flag set to zero. 955 i. The "current custodian" of a bundle is the endpoint identified by 956 the current custodian endpoint ID in the bundle's primary header. 958 4.2 Bundle transmission 959 The steps in processing a bundle transmission request are: 961 Step 1: If custody transfer is requested for this bundle transmission 962 and, moreover, custody acceptance by the source node is required, 963 then either the bundle protocol agent must commit to accepting 964 custody of the bundle � in which case processing proceeds from 965 Step 2 - or else the request cannot be honored and all remaining 966 steps of this procedure must be skipped. 968 Step 2: Transmission of the bundle is initiated. An outbound bundle 969 must be created per the parameters of the bundle transmission 970 request, with current custodian endpoint ID set to the null 971 endpoint ID "dtn:none" and with the retention constraint "Dispatch 972 pending". The source endpoint ID of the bundle must be either the 973 ID of an endpoint of which the node is a member or else the null 974 endpoint ID "dtn:none". 976 Step 3: Processing proceeds from Step 1 of section 4.3. 978 4.3 Bundle dispatching 980 The steps in dispatching a bundle are: 982 Step 1: If the bundle's destination endpoint is an endpoint of which 983 the node is a member, the bundle delivery procedure defined in 4.7 984 must be followed. 986 Step 2: Processing proceeds from Step 1 of section 4.4. 988 4.4 Bundle forwarding 990 The steps in forwarding a bundle are: 992 Step 1: The retention constraint "Forward pending" must be added to 993 the bundle, and the bundle's "Dispatch pending" retention 994 constraint must be removed. 996 Step 2: The bundle protocol agent must determine whether or not 997 forwarding is contraindicated for any of the reasons listed in 998 Table 5. In particular: 1000 o The bundle protocol agent must determine which endpoint(s) to 1001 forward the bundle to. The bundle protocol agent may choose 1002 either to forward the bundle directly to its destination 1003 endpoint (if possible) or else to forward the bundle to some 1004 other endpoint(s) for further forwarding. The manner in which 1005 this decision is made may depend on the scheme name in the 1006 destination endpoint ID but in any case is beyond the scope of 1007 this document. If the agent finds it impossible to select any 1008 endpoint(s) to forward the bundle to, then forwarding is 1009 contraindicated. 1011 o Provided the bundle protocol agent succeeded in selecting the 1012 endpoint(s) to forward the bundle to, the bundle protocol agent 1013 must select the convergence layer adapter(s) whose services 1014 will enable the node to send the bundle to the nodes of the 1015 minimum reception group of each selected endpoint. The manner 1016 in which the appropriate convergence layer adapters are 1017 selected may depend on the scheme name in the destination 1018 endpoint ID but in any case is beyond the scope of this 1019 document. If the agent finds it impossible to select 1020 convergence layer adapters to use in forwarding this bundle, 1021 then forwarding is contraindicated. 1023 Step 3: If forwarding of the bundle is determined to be 1024 contraindicated for any of the reasons listed in Table 5, then the 1025 Forwarding Contraindicated procedure defined in 4.4.1 must be 1026 followed; the remaining steps of section 4 are skipped at this 1027 time. 1029 Step 4: If the bundle's custody transfer requested flag (in the 1030 bundle processing flags field) is set to 1 then the custody 1031 transfer procedure defined in section 4.10 must be followed. 1033 Step 5: For each endpoint selected for forwarding, the bundle 1034 protocol agent must invoke the services of the selected 1035 convergence layer adapter(s) in order to effect the sending of the 1036 bundle to the nodes constituting the minimum reception group of 1037 that endpoint. Determining the time at which the bundle is to be 1038 sent by each convergence layer adapter is an implementation 1039 matter. 1041 Step 6: When all selected convergence layer adapters have informed 1042 the bundle protocol agent that they have concluded their data 1043 sending procedures with regard to this bundle: 1045 o If the "request reporting of bundle forwarding" flag in the 1046 bundle's class of service field is set to 1, then a bundle 1047 forwarding status report must be generated, destined for the 1048 bundle's report-to endpoint ID. If the bundle has the 1049 retention constraint "custody accepted" and all of the nodes 1050 in the minimum reception group of the endpoint selected for 1051 forwarding are known to be unable to send bundles back to this 1052 node, then the reason code on this bundle forwarding status 1053 report must be "forwarded over unidirectional link"; otherwise 1054 the reason code must be "no additional information". 1056 o The bundle's "Forward pending" retention constraint must be 1057 removed. 1059 4.4.1 Forwarding Contraindicated 1060 The steps in responding to contraindication of forwarding for some 1061 reason are: 1063 Step 1: The bundle protocol agent must determine whether or not to 1064 declare failure in forwarding the bundle for this reason. Note: 1065 this decision is likely to be influenced by the reason for which 1066 forwarding is contraindicated. 1068 Step 2: If forwarding failure is declared, then the Forwarding Failed 1069 procedure defined in 4.4.2 must be followed. Otherwise, (a) if 1070 the bundle's custody transfer requested flag (in the bundle 1071 processing flags field) is set to 1 then the custody transfer 1072 procedure defined in section 4.10 must be followed; (b) when - at 1073 some future time - the forwarding of this bundle ceases to be 1074 contraindicated, processing proceeds from Step 5 of 4.4. 1076 4.4.2 Forwarding Failed 1078 The steps in responding to a declaration of forwarding failure for 1079 some reason are: 1081 Step 1: If the bundle's custody transfer requested flag (in the 1082 bundle processing flags field) is set to 1, custody transfer 1083 failure must be handled. Procedures for handling failure of 1084 custody transfer for a bundle whose destination is not a singleton 1085 endpoint are not defined in this specification. For a bundle 1086 whose destination is a singleton endpoint, the bundle protocol 1087 agent must handle the custody transfer failure by generating a 1088 "Failed" custody signal for the bundle, destined for the bundle's 1089 current custodian; the custody signal must contain a reason code 1090 corresponding to the reason for which forwarding was determined to 1091 be contraindicated. (Note that discarding the bundle will not 1092 delete it from the network, since the current custodian still has 1093 a copy.) 1095 Step 2: If the bundle's destination endpoint is an endpoint of which 1096 the node is a member, then the bundle's "Forward pending" 1097 retention constraint must be removed. Otherwise the bundle must 1098 be deleted: the bundle deletion procedure defined in 4.13 must be 1099 followed, citing the reason for which forwarding was determined to 1100 be contraindicated. 1102 4.5 Bundle expiration 1104 A bundle expires when the current time is greater than the bundle's 1105 creation time plus its lifetime as specified in the primary bundle 1106 header. Bundle expiration may occur at any point in the processing 1107 of a bundle. When a bundle expires, the bundle protocol agent must 1108 delete the bundle for the reason "lifetime expired": the bundle 1109 deletion procedure defined in 4.13 must be followed. 1111 4.6 Bundle reception 1113 The steps in processing a bundle received from another node are: 1115 Step 1: The retention constraint "Dispatch pending" must be added to 1116 the bundle. 1118 Step 2: If the "request reporting of bundle reception" flag in the 1119 bundle's class of service field is set to 1, then a bundle 1120 reception status report with reason code "No additional 1121 information" must be generated, destined for the bundle's report- 1122 to endpoint ID. 1124 Step 3: If any header in the bundle cannot be processed: 1126 o If the header processing flags in the header indicate that a 1127 status report must be generated in this event, then a bundle 1128 reception status report with reason code "Header 1129 unintelligible" must be generated, destined for the bundle's 1130 report-to endpoint ID. 1132 o If the header processing flags in that header indicate that 1133 the bundle must be discarded in this event, then the bundle 1134 protocol agent must delete the bundle for the reason "Header 1135 unintelligible": the bundle deletion procedure defined in 4.13 1136 must be followed. Otherwise, processing proceeds from Step 4. 1138 Step 4: If the bundle's custody transfer requested flag (in the 1139 bundle processing flags field) is set to 1 and the bundle has the 1140 same source endpoint ID, creation timestamp, and fragment offset 1141 as another bundle that (a) has not been discarded and (b) 1142 currently has the retention constraint "Custody accepted", custody 1143 transfer redundancy must be handled; otherwise, processing 1144 proceeds from Step 5. Procedures for handling redundancy in 1145 custody transfer for a bundle whose destination is not a singleton 1146 endpoint are not defined in this specification. For a bundle 1147 whose destination is a singleton endpoint, the bundle protocol 1148 agent must handle custody transfer redundancy by generating a 1149 "Failed" custody signal for this bundle with reason code 1150 "Redundant reception", destined for this bundle's current 1151 custodian, and removing this bundle's "Dispatch pending" retention 1152 constraint. 1154 Step 5: Processing proceeds from Step 1 of section 4.3. 1156 4.7 Local bundle delivery 1158 The steps in processing a bundle that is destined for an endpoint of 1159 which this node is a member are: 1161 Step 1: If the received bundle is a fragment, the application data 1162 unit reassembly procedure described in 4.9 must be followed. If 1163 this procedure results in reassembly of the entire original 1164 application data unit, processing of this bundle (whose 1165 fragmentary payload has been replaced by the reassembled 1166 application data unit) proceeds from Step 2; otherwise the 1167 retention constraint "Reassembly pending" must be added to the 1168 bundle and all remaining steps of this procedure are skipped. 1170 Step 2: Delivery depends on the state of the registration whose 1171 endpoint ID matches that of the destination of the bundle: 1173 o If the registration is in the Active state, then the bundle 1174 must be delivered subject to this registration (see 2.1 above) 1175 as soon as all previously received bundles that are 1176 deliverable subject to this registration have been delivered. 1178 o If the registration is in the Passive state, then the 1179 registration's delivery failure action must be taken (see 2.1 1180 above). 1182 Step 3: As soon as the bundle has been delivered: 1184 o If the "request reporting of bundle delivery" flag in the 1185 bundle's class of service field is set to 1, then a bundle 1186 delivery status report must be generated, destined for the 1187 bundle's report-to endpoint ID. Note that this status report 1188 only states that the payload has been delivered to the 1189 application agent, not that the application agent has 1190 processed that payload. 1192 o If the bundle's custody transfer requested flag (in the bundle 1193 processing flags field) is set to 1, custodial delivery must 1194 be reported. Procedures for reporting custodial delivery for 1195 a bundle whose destination is not a singleton endpoint are not 1196 defined in this specification. For a bundle whose destination 1197 is a singleton endpoint, the bundle protocol agent must report 1198 custodial delivery by generating a "Succeeded" custody signal 1199 for the bundle, destined for the bundle's current custodian. 1201 4.8 1202 Bundle Fragmentation 1204 It may at times be necessary for bundle protocol agents to reduce the 1205 sizes of bundles in order to forward them. This might be the case, 1206 for example, if the endpoint to which a bundle is to be forwarded is 1207 accessible only via intermittent contacts and no upcoming contact is 1208 long enough to enable the forwarding of the entire bundle. 1210 The size of a bundle can be reduced by "fragmenting" the bundle. To 1211 fragment a bundle whose payload is of size M is to replace it with 1212 two "fragments" � new bundles with the same source endpoint ID and 1213 creation timestamp as the original bundle � whose payloads are the 1214 first N and the last (M � N) bytes of the original bundle's payload, 1215 where 0 < N < M. Note that fragments may themselves be fragmented, 1216 so fragmentation may in effect replace the original bundle with more 1217 than two fragments. (However, there is only one 'level' of 1218 fragmentation, as in IP fragmentation.) 1220 Any bundle whose primary header's bundle processing flags do NOT 1221 indicate that it must not be fragmented may be fragmented at any 1222 time, for any purpose, at the discretion of the bundle protocol 1223 agent. 1225 Fragmentation shall be constrained as follows: 1227 o The concatenation of the payloads of all fragments produced by 1228 a fragmentation must always be identical to the payload of the 1229 bundle that was fragmented. Note that the payloads of 1230 fragments resulting from different fragmentation episodes, in 1231 different parts of the network, may be overlapping subsets of 1232 the original bundle's payload. 1234 o The bundle processing flags in the primary header of each 1235 fragment must be modified to indicate that the bundle is a 1236 fragment, and both fragment offset and total application data 1237 unit length must be provided at the end of each fragment's 1238 primary bundle header. 1240 o All fragments must contain the same headers as the original 1241 bundle, except that (a) the primary headers of the fragments 1242 will differ from that of the fragmented bundle as noted above, 1243 (b) the payload headers of fragments will differ from that of 1244 the fragmented bundle, and (c) any header whose header 1245 processing flags do NOT indicate that the header must be 1246 replicated in every fragment should be replicated only in the 1247 fragment whose fragment offset is zero. 1249 4.9 Application Data Unit Reassembly 1251 If the concatenation � as informed by fragment offsets and payload 1252 lengths - of the payloads of all previously received fragments with 1253 the same source endpoint ID and creation timestamp as this fragment, 1254 together with the payload of this fragment, forms a byte array whose 1255 length is equal to the total application data unit length in the 1256 fragment's primary header, then: 1258 o This byte array � the reassembled application data unit � must 1259 replace the payload of this fragment. 1261 o The "Reassembly pending" retention constraint must be removed 1262 from every other fragment whose payload is a subset of the 1263 reassembled application data unit. 1265 Note: reassembly of application data units from fragments occurs at 1266 destination endpoints as necessary; an application data unit may also 1267 be reassembled at some other endpoint on the route to the 1268 destination. 1270 4.10 Custody transfer 1272 The conditions under which a node may accept custody of a bundle 1273 whose destination is not a singleton endpoint are not defined in this 1274 specification. 1276 The decision as to whether or not to accept custody of a bundle whose 1277 destination is a singleton endpoint is an implementation matter which 1278 may involve both resource and policy considerations; however, if the 1279 bundle protocol agent has committed to accepting custody of the 1280 bundle (as described in Step 1 of 4.2) then custody must be accepted. 1282 If the bundle protocol agent elects to accept custody of the bundle, 1283 then it must follow the custody acceptance procedure defined in 1284 4.10.1. 1286 4.10.1 1287 Custody acceptance 1289 Procedures for acceptance of custody of a bundle whose destination is 1290 not a singleton endpoint are not defined in this specification. 1292 Procedures for acceptance of custody of a bundle whose destination is 1293 a singleton endpoint are defined as follows. 1295 The retention constraint "Custody accepted" must be added to the 1296 bundle. 1298 If the "request custody acceptance reporting" flag in the bundle's 1299 class of service field is set to 1, a custody acceptance status 1300 report must be generated, destined for the report-to endpoint ID of 1301 the bundle. However, if a bundle reception status report was 1302 generated for this bundle (step 1 of 4.6) then this report should be 1303 generated by simply turning on the "Reporting node accepted custody 1304 of bundle" flag in that earlier report's status flags byte. 1306 The bundle protocol agent must generate a "Succeeded" custody signal 1307 for the bundle, destined for the bundle's current custodian. 1309 The bundle protocol agent must assert the new current custodian for 1310 the bundle. It does so by changing the current custodian endpoint ID 1311 in the bundle's primary header to the endpoint ID of one of the 1312 singleton endpoints in which the node is registered. This may entail 1313 appending that endpoint ID's null-terminated scheme name and SSP to 1314 the dictionary byte array in the bundle's primary header, and in some 1315 case it may also enable the (optional) removal of the current 1316 custodian endpoint ID's scheme name and/or SSP from the dictionary. 1318 The bundle protocol agent may set a custody transfer countdown timer 1319 for this bundle; upon expiration of this timer prior to expiration of 1320 the bundle itself and prior to custody transfer success for this 1321 bundle, the custody transfer failure procedure detailed in section 1322 4.12 must be followed. The manner in which the countdown interval 1323 for such a timer is determined is an implementation matter. 1325 The bundle should be retained in persistent storage if possible. 1327 4.10.2 1328 Custody release 1330 Procedures for release of custody of a bundle whose destination is 1331 not a singleton endpoint are not defined in this specification. 1333 When custody of a bundle is released, where the destination of the 1334 bundle is a singleton endpoint, the "Custody accepted" retention 1335 constraint must be removed from the bundle and any custody transfer 1336 timer that has been established for this bundle must be destroyed. 1338 4.11 Custody transfer success 1340 Procedures for determining custody transfer success for a bundle 1341 whose destination is not a singleton endpoint are not defined in this 1342 specification. 1344 Upon receipt of a "Succeeded" custody signal at a node that is a 1345 custodial node of the bundle identified in the custody signal, where 1346 the destination of the bundle is a singleton endpoint, custody of the 1347 bundle must be released as described in 4.10.2. 1349 4.12 Custody transfer failure 1351 Procedures for determining custody transfer failure for a bundle 1352 whose destination is not a singleton endpoint are not defined in this 1353 specification. Custody transfer for a bundle whose destination is a 1354 singleton endpoint is determined to have failed at a custodial node 1355 for that bundle when either (a) that node's custody transfer timer 1356 for that bundle (if any) expires or (b) a "Failed" custody signal for 1357 that bundle is received at that node. 1359 Upon determination of custody transfer failure, the action taken by 1360 the bundle protocol agent is implementation-specific and may depend 1361 on the nature of the failure. For example, if custody transfer 1362 failure was inferred from expiration of a custody transfer timer or 1363 was asserted by a "Failed" custody signal with the "Depleted storage" 1364 reason code, the bundle protocol agent might choose to re-forward the 1365 bundle, possibly on a different route (section 4.4). Receipt of a 1366 "Failed" custody signal with the "Redundant reception" reason code, 1367 on the other hand, might cause the bundle protocol agent to release 1368 custody of the bundle and to revise its algorithm for computing 1369 countdown intervals for custody transfer timers. 1371 4.13 Bundle deletion 1373 The steps in deleting a bundle are: 1375 Step 1: If the retention constraint "Custody accepted" currently 1376 prevents this bundle from being discarded, and the destination of 1377 the bundle is a singleton endpoint, then: 1379 o Custody of the node is released as described in 4.10.2. 1381 o A bundle deletion status report citing the reason for deletion 1382 must be generated, destined for the bundle's report-to 1383 endpoint ID. 1385 Otherwise, if the "request reporting of bundle deletion" flag in 1386 the bundle's class of service field is set to 1, then a bundle 1387 deletion status report citing the reason for deletion must be 1388 generated, destined for the bundle's report-to endpoint ID. 1390 Step 2: All of the bundle's retention constraints must be removed. 1392 4.14 Discarding a bundle 1394 As soon as a bundle has no remaining retention constraints it may be 1395 discarded. 1397 4.15 Canceling a transmission 1399 When requested to cancel a specified transmission, where the bundle 1400 created upon initiation of the indicated transmission has not yet 1401 been discarded, the bundle protocol agent must delete that bundle for 1402 the reason "transmission canceled". For this purpose, the procedure 1403 defined in 4.13 must be followed. 1405 4.16 Polling 1407 When requested to poll a specified registration that is in Passive 1408 state, the bundle protocol agent must immediately deliver the least 1409 recently received bundle that is deliverable subject to the indicated 1410 registration, if any. 1412 4.17 Acknowledging an application data unit 1414 When requested to acknowledge to an indicated report-to endpoint the 1415 bundle transmission request identified by an indicated source 1416 endpoint ID and bundle creation timestamp, the bundle protocol agent 1417 must generate an acknowledgement status report for that transmission 1418 request, destined for that report-to-endpoint. 1420 5. Administrative record processing 1422 5.1 Administrative records 1424 Two types of administrative records have been defined to date: bundle 1425 status reports and custody signals. 1427 Every administrative record consists of a four-bit record type code 1428 followed by four bits of administrative record flags, followed by 1429 record content in type-specific format. Record type codes are 1430 defined as follows: 1432 Table 2: Administrative Record Type Codes 1434 +---------+--------------------------------------------+ 1435 | Value | Meaning | 1436 +=========+============================================+ 1437 | 0x01 | Bundle status report. | 1438 +---------+--------------------------------------------+ 1439 | 0x02 | Custody signal. | 1440 +---------+--------------------------------------------+ 1441 | (other) | Reserved for future use. | 1442 +---------+--------------------------------------------+ 1444 Administrative record flags are defined as follows: 1446 Table 3: Administrative Record Flags 1448 +---------+--------------------------------------------+ 1449 | Value | Meaning | 1450 +=========+============================================+ 1451 | 0x01 | Record is for a fragment; fragment | 1452 | | offset and length fields are present. | 1453 +---------+--------------------------------------------+ 1454 | (other) | Reserved for future use. | 1455 +---------+--------------------------------------------+ 1457 All time values in administrative records are UTC times expressed in 1458 "DTN time" representation. A DTN time consists of a 32-bit number in 1459 network byte order indicating the number of seconds since the start 1460 of the year 2000, followed by a 32-bit number in network byte order 1461 indicating the number of nanoseconds since the start of the indicated 1462 second. 1464 The contents of the various types of administrative records are 1465 described below. 1467 5.1.1 Bundle Status Reports 1469 The transmission of 'bundle status reports' under specified 1470 conditions is an option that can be invoked when transmission of a 1471 bundle is requested. These reports are intended to provide 1472 information about how bundles are progressing through the system, 1473 including notices of receipt, custody transfer, forwarding, final 1474 delivery, and deletion. They are transmitted to the Report-to 1475 endpoints of bundles. 1477 Format of Bundle Status Report for bundle 'X': 1479 +----------------+----------------+----------------+----------------+ 1480 | Status Flags | Reason code | Fragment offset (*) (if 1481 +----------------+----------------+----------------+----------------+ 1482 present) | Fragment length (**) (if present) | 1483 +----------------+----------------+----------------+----------------+ 1484 | 1485 + Time of receipt of bundle X (8 bytes, if present) + 1486 | 1487 +----------------+----------------+----------------+----------------+ 1488 | 1489 + Time of custody acceptance of bundle X (8 bytes, if present) + 1490 | 1491 +----------------+----------------+----------------+----------------+ 1492 | 1493 + Time of forwarding of bundle X (8 bytes, if present) + 1494 | 1495 +----------------+----------------+----------------+----------------+ 1496 | 1497 + Time of delivery of bundle X (8 bytes, if present) + 1498 | 1499 +----------------+----------------+----------------+----------------+ 1500 | 1501 + Time of deletion of bundle X (8 bytes, if present) + 1502 | 1503 +----------------+----------------+----------------+----------------+ 1504 | 1505 + Time of acknowledgement of bundle X (8 bytes, if present) + 1506 | 1507 +----------------+----------------+----------------+----------------+ 1508 | 1509 + Copy of bundle X's Creation Timestamp (8 bytes) + 1510 | 1511 +----------------+----------------+----------------+----------------+ 1512 | Length of X's source endpoint ID (***) | Source 1513 +----------------+---------------------------------+ + 1514 endpoint ID of bundle X (variable) | 1515 +----------------+----------------+----------------+----------------+ 1517 Notes: 1519 (*) The Fragment Offset field, if present, is an SDNV and is 1520 therefore variable-length. A three-octet SDNV is shown here for 1521 convenience in representation. 1523 (**) The Fragment Length field, if present, is an SDNV and is 1524 therefore variable-length. A three-octet SDNV is shown here for 1525 convenience in representation. 1527 (***) The source endpoint ID length field is an SDNV and is 1528 therefore variable-length. A three-octet SDNV is shown here for 1529 convenience in representation. 1531 The fields in a bundle status report are: 1533 Status Flags. A 1-byte field containing the following flags: 1535 Table 4: Status Flags for Bundle Status Reports 1537 +---------+--------------------------------------------+ 1538 | Value | Meaning | 1539 +=========+============================================+ 1540 | 0x01 | Reporting node received bundle. | 1541 +---------+--------------------------------------------+ 1542 | 0x02 | Reporting node accepted custody of bundle.| 1543 +---------+--------------------------------------------+ 1544 | 0x04 | Reporting node forwarded the bundle. | 1545 +---------+--------------------------------------------+ 1546 | 0x08 | Reporting node delivered the bundle. | 1547 +---------+--------------------------------------------+ 1548 | 0x10 | Reporting node deleted the bundle. | 1549 +---------+--------------------------------------------+ 1550 | 0x20 | Acknowledged by application. | 1551 +---------+--------------------------------------------+ 1552 | 0x40 | Unused. | 1553 +---------+--------------------------------------------+ 1554 | 0x80 | Unused. | 1555 +---------+--------------------------------------------+ 1557 Reason code. A 1-byte field explaining the value of the flags in the 1558 status flags byte. The list of status report reason codes 1559 provided here is neither exhaustive nor exclusive; 1560 supplementary DTN protocol specifications (including, but not 1561 restricted to, the Bundle Security Protocol) may define 1562 additional reason codes. Status report reason codes are 1563 defined as follows: 1565 Table 5: Status Report Reason Codes 1567 +---------+--------------------------------------------+ 1568 | Value | Meaning | 1569 +=========+============================================+ 1570 | 0x00 | No additional information. | 1571 +---------+--------------------------------------------+ 1572 | 0x01 | Lifetime expired. | 1573 +---------+--------------------------------------------+ 1574 | 0x02 | Forwarded over unidirectional link. | 1575 +---------+--------------------------------------------+ 1576 | 0x03 | Transmission canceled. | 1577 +---------+--------------------------------------------+ 1578 | 0x04 | Depleted storage. | 1579 +---------+--------------------------------------------+ 1580 | 0x05 | Destination endpoint ID unintelligible. | 1581 +---------+--------------------------------------------+ 1582 | 0x06 | No known route to destination from here. | 1583 +---------+--------------------------------------------+ 1584 | 0x07 | No timely contact with next node on route.| 1585 +---------+--------------------------------------------+ 1586 | 0x08 | Header unintelligible. | 1587 +---------+--------------------------------------------+ 1588 | (other) | Reserved for future use. | 1589 +---------+--------------------------------------------+ 1591 Fragment offset. If the bundle fragment bit is set in the status 1592 flags, then the offset (within the original application data 1593 unit) of the payload of the bundle that caused the status 1594 report to be generated is included here. 1596 Fragment length. If the bundle fragment bit is set in the status 1597 flags, then the length of the payload of the subject bundle is 1598 included here. 1600 Time of Receipt (if present). If the bundle-received bit is set in 1601 the status flags, then a DTN time indicating the time at which 1602 the bundle was received at the reporting node is included 1603 here. 1605 Time of Custody Acceptance (if present). If the custody-accepted bit 1606 is set in the status flags, then a DTN time indicating the 1607 time at which custody was accepted at the reporting node is 1608 included here. 1610 Time of Forward (if present). If the bundle-forwarded bit is set in 1611 the status flags, then a DTN time indicating the time at which 1612 the bundle was first forwarded at the reporting node is 1613 included here. 1615 Time of Delivery (if present). If the bundle-delivered bit is set in 1616 the status flags, then a DTN time indicating the time at which 1617 the bundle was delivered at the reporting node is included 1618 here. 1620 Time of Deletion (if present). If the bundle-deleted bit is set in 1621 the status flags, then a DTN time indicating the time at which 1622 the bundle was deleted at the reporting node is included here. 1624 Time of Acknowledgement (if present). If the bundle-acknowledged-by- 1625 application bit is set in the status flags, then a DTN time 1626 indicating the time at which the bundle was acknowledged by 1627 the application at the reporting node is included here. 1629 Creation Timestamp of Subject Bundle. A copy of the creation 1630 timestamp of the bundle that caused the status report to be 1631 generated. 1633 Length of Source Endpoint ID. The length in bytes of the source 1634 endpoint ID of the bundle that caused the status report to be 1635 generated. 1637 Source Endpoint ID text. The text of the source endpoint ID of the 1638 bundle that caused the status report to be generated. 1640 5.1.2 Custody Signals 1642 Custody signals are administrative records that effect custody 1643 transfer operations. They are transmitted to the endpoints that are 1644 the current custodians of bundles. 1646 Custody signals have the following format. 1648 Custody Signal regarding bundle 'X': 1650 +----------------+----------------+----------------+----------------+ 1651 | Status | Fragment offset (*) (if present) | 1652 +----------------+----------------+----------------+----------------+ 1653 | Fragment length (**) (if present) | 1654 +----------------+----------------+----------------+----------------+ 1655 | 1656 + Time of signal (8 bytes) + 1657 | 1658 +----------------+----------------+----------------+----------------+ 1659 | 1660 + Copy of bundle X's Creation Timestamp (8 bytes) + 1661 | 1662 +----------------+----------------+----------------+----------------+ 1663 | Length of X's source endpoint ID (***) | Source 1664 +----------------+---------------------------------+ + 1665 endpoint ID of bundle X (variable) | 1666 +----------------+----------------+----------------+----------------+ 1668 Notes: 1670 (*) The Fragment Offset field, if present, is an SDNV and is 1671 therefore variable-length. A three-octet SDNV is shown here for 1672 convenience in representation. 1674 (**) The Fragment Length field, if present, is an SDNV and is 1675 therefore variable-length. A four-octet SDNV is shown here for 1676 convenience in representation. 1678 (***) The source endpoint ID length field is an SDNV and is 1679 therefore variable-length. A three-octet SDNV is shown here for 1680 convenience in representation. 1682 The fields in a custody signal are: 1684 Status. A 1-byte field containing a 1-bit "custody transfer 1685 succeeded" flag followed by a 7-bit reason code explaining the value 1686 of that flag. Custody signal reason codes are defined as follows: 1688 Table 6: Custody Signal Reason Codes 1690 +---------+--------------------------------------------+ 1691 | Value | Meaning | 1692 +=========+============================================+ 1693 | 0x00 | No additional information. | 1694 +---------+--------------------------------------------+ 1695 | 0x01 | Reserved for future use. | 1696 +---------+--------------------------------------------+ 1697 | 0x02 | Reserved for future use. | 1698 +---------+--------------------------------------------+ 1699 | 0x03 | Redundant reception (reception by a node | 1700 | | that is a custodial node for this bundle).| 1701 +---------+--------------------------------------------+ 1702 | 0x04 | Depleted storage. | 1703 +---------+--------------------------------------------+ 1704 | 0x05 | Destination endpoint ID unintelligible. | 1705 +---------+--------------------------------------------+ 1706 | 0x06 | No known route to destination from here. | 1707 +---------+--------------------------------------------+ 1708 | 0x07 | No timely contact with next node on route.| 1709 +---------+--------------------------------------------+ 1710 | 0x08 | Header unintelligible. | 1711 +---------+--------------------------------------------+ 1712 | (other) | Reserved for future use. | 1713 +---------+--------------------------------------------+ 1715 Fragment offset. If the bundle fragment bit is set in the status 1716 flags, then the offset (within the original application data 1717 unit) of the payload of the bundle that caused the status 1718 report to be generated is included here. 1720 Fragment length. If the bundle fragment bit is set in the status 1721 flags, then the length of the payload of the subject bundle is 1722 included here. 1724 Time of Signal. A DTN time indicating the time at which the signal 1725 was generated. 1727 Creation Timestamp of Subject Bundle. A copy of the creation 1728 timestamp of the bundle to which the signal applies. 1730 Length of Source Endpoint ID. The length in bytes of the source 1731 endpoint ID of the bundle to which the signal applied. 1733 Source Endpoint ID text. The text of the source endpoint ID of the 1734 bundle to which the signal applies. 1736 5.2 Generation of administrative records 1737 Whenever the application agent's administrative element is directed 1738 by the bundle protocol agent to generate an administrative record 1739 with reference to some bundle, the following procedure must be 1740 followed: 1742 Step 1: The administrative record must be constructed. If the 1743 referenced bundle is a fragment, the administrative record must 1744 have the Fragment flag set and must contain the fragment offset 1745 and fragment length fields; the value of the fragment offset field 1746 must be the value of the referenced bundle's fragment offset, and 1747 the value of the fragment length field must be the length of the 1748 referenced bundle's payload. 1750 Step 2: A request for transmission of a bundle whose payload is this 1751 administrative record must be presented to the bundle protocol 1752 agent. 1754 5.3 Reception of custody signals 1756 For each received custody signal that has the Custody Transfer 1757 Succeeded flag set to 1, the administrative element of the 1758 application agent must direct the bundle protocol agent to follow the 1759 custody transfer success procedure in 4.11. 1761 For each received custody signal that has the Custody Transfer 1762 Succeeded flag set to 0, the administrative element of the 1763 application agent must direct the bundle protocol agent to follow the 1764 custody transfer failure procedure in 4.12. 1766 6. Services Required of the Convergence Layer 1768 6.1 The Convergence Layer 1770 The successful operation of the end-to-end bundle protocol depends on 1771 the operation of underlying protocols at what is termed the 1772 "convergence layer"; these protocols accomplish communication between 1773 nodes. A wide variety of protocols may serve this purpose, so long 1774 as each convergence layer protocol adapter provides a defined minimal 1775 set of services to the bundle protocol agent. This convergence layer 1776 service specification enumerates those services. 1778 6.2 Summary of Convergence Layer Services 1780 Each convergence layer protocol adapter is expected to provide the 1781 following services to the bundle protocol agent: 1783 a) sending a bundle to all bundle nodes in the minimum reception 1784 group of the endpoint identified by a specified endpoint ID 1785 that are reachable via the convergence layer protocol; 1787 b) delivering to the bundle protocol agent a bundle that was sent 1788 by a remote bundle node via the convergence layer protocol. 1790 The convergence layer service interface specified here is neither 1791 exhaustive nor exclusive. That is, supplementary DTN protocol 1792 specifications (including, but not restricted to, the Bundle Security 1793 Protocol) may expect convergence layer adapters which serve BP 1794 implementations conforming to those protocols to provide additional 1795 services. 1797 7. Security Considerations 1799 The bundle protocol has taken security into concern from the outset 1800 of its design. It was always assumed that security services would be 1801 needed in the use of the bundle protocol. As a result, the bundle 1802 protocol security architecture and the available security services 1803 are specified in an accompanying document, the Bundle Security 1804 Protocol specification [5]; an informative overview of this 1805 architecture is provided in [6]. 1807 The bundle protocol has been designed with the notion that it will be 1808 run over networks with scarce resources. For example, the networks 1809 might have limited bandwidth, limited connectivity, constrained 1810 storage in relay nodes, etc. Therefore, the bundle protocol must 1811 ensure that only those entities authorized to send bundles over such 1812 constrained environments are actually allowed to do so. All 1813 unauthorized entities should be prevented from consuming valuable 1814 resources. 1816 Likewise, because of the potentially long latencies and delays 1817 involved in the networks that make use of the bundle protocol, data 1818 sources should be concerned with the integrity of the data received 1819 at the intended destination(s) and may also be concerned with 1820 ensuring confidentiality of the data as it traverses the network. 1821 Without integrity, the bundle payload data might be corrupted while 1822 in transit without the destination able to detect it. Similarly, the 1823 data source can be concerned with ensuring that the data can only be 1824 used by those authorized; hence the need for confidentiality. 1826 Internal to the bundle-aware overlay network, the bundle nodes should 1827 be concerned with the authenticity of other bundle nodes as well as 1828 the preservation of bundle payload data integrity as it is forwarded 1829 between bundle nodes. 1831 As a result, bundle security is concerned with the authenticity, 1832 integrity, and confidentiality of bundles conveyed among bundle 1833 nodes. This is accomplished via the use of three, independent 1834 security specific bundle headers which may be used together to 1835 provide multiple bundle security services or independently of one 1836 another, depending on perceived security threats, mandated security 1837 requirements, and security policies that must be enforced. 1839 The Bundle Authentication Header (BAH) ensures the authenticity and 1840 integrity of bundles on a hop-by-hop basis between bundle nodes. The 1841 BAH allows each bundle node to verify a bundle�s authenticity before 1842 processing or forwarding the bundle. In this way, entities that are 1843 not authorized to send bundles will have unauthorized transmissions 1844 blocked by security-aware bundle nodes. 1846 Additionally, to provide "security-source" to "security-destination" 1847 bundle authenticity and integrity, the Payload Security Header (PSH) 1848 is used. A "security-source" may not actually be the origination 1849 point of the bundle but instead may be the first point along the path 1850 that is security-aware and is able to apply security services. For 1851 example, an enclave of networked systems may generate bundles but 1852 only their gateway may be required and/or able to apply security 1853 services. The PSH allows any security-enabled entity along the 1854 delivery path, in addition to the "security-destination" (the 1855 recipient counterpart to the "security-source"), to ensure the 1856 bundle�s authenticity. 1858 Finally, to provide payload confidentiality, the use of the 1859 Confidentiality Header (CH) is available. The bundle payload may be 1860 encrypted to provide "security-source" to "security-destination" 1861 payload confidentiality/privacy. The CH indicates the cryptographic 1862 algorithm and key IDs that were used to encrypt the payload. 1864 Inclusion of the Bundle Security Protocol in any Bundle Protocol 1865 implementation is RECOMMENDED. Use of the Bundle Security Protocol 1866 in Bundle Protocol operations is OPTIONAL. 1868 8. IANA Considerations 1870 The new Uniform Resource Identifier scheme "dtn", defined by the 1871 Bundle Protocol, will need to be documented. 1873 9. Normative References 1875 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 1876 3978, March 2005. 1878 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 1879 Technology", BCP 79, RFC 3979, March 2005. 1881 [RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 1882 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Jan 1883 2005. 1885 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 1886 Scheme Names", BCP 35, RFC 2717, November 1999. 1888 10. Informative References 1890 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1891 Levels", BCP 14, RFC 2119, March 1997 1893 [2] V. Cerf, et. al., "Delay-Tolerant Network Architecture," work in 1894 progress, draft-irtf-dtnrg-arch-03.txt, July 2005 1896 [3] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial", 1897 Warthman Associates, available from http://www.dtnrg.org 1899 [4] Mills, D., "Network Time Protocol (Version 3) Specification, 1900 Implementation and Analysis", RFC 1305, March 1992 1902 [5] S. Symington, et. al., "Bundle Security Protocol Specification," 1903 draft-irtf-dtnrg-bundle-security-00.txt, June 2005 1905 [6] S. Farrell, S. Symington, and H. Weiss, "Delay-Tolerant 1906 Networking Security Overview," draft-irtf-dtnrg-sec-overview- 1907 00.txt, September 2005 1909 [7] E. F. Arias and B. Guinot, B., "Coordinated universal time UTC: 1910 historical background and perspectives" in Journ�es systemes de 1911 reference spatio-temporels 2004 1913 [8] K. Fall, " A Delay-Tolerant Network Architecture for Challenged 1914 Internets", SIGCOMM 2003 1916 Author's Addresses 1918 Dr. Keith L. Scott Scott C. Burleigh 1919 The MITRE Corporation Jet Propulsion Laboratory 1920 7515 Colshire Drive 4800 Oak Grove Drive 1921 McLean, VA 22102 M/S: 179-206 1922 Telephone +1 (703) 883-6547 Pasadena, CA 91109-8099 1923 FAX +1 (703) 883-7142 Telephone +1 (818) 393-3353 1924 Email kscott@mitre.org FAX +1 (818) 354-1075 1925 Email Scott.Burleigh@jpl.nasa.gov 1927 Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay 1928 Tolerant Networking Research Group (DTNRG) web site is located at 1929 http://www.dtnrg.org. 1931 Intellectual Property Statement 1933 The IETF takes no position regarding the validity or scope of any 1934 Intellectual Property Rights or other rights that might be claimed to 1935 pertain to the implementation or use of the technology described in 1936 this document or the extent to which any license under such rights 1937 might or might not be available; nor does it represent that it has 1938 made any independent effort to identify any such rights. Information 1939 on the procedures with respect to rights in RFC documents can be 1940 found in BCP 78 and BCP 79. 1942 Copies of IPR disclosures made to the IETF Secretariat and any 1943 assurances of licenses to be made available, or the result of an 1944 attempt made to obtain a general license or permission for the use of 1945 such proprietary rights by implementers or users of this 1946 specification can be obtained from the IETF on-line IPR repository at 1947 http://www.ietf.org/ipr. 1949 The IETF invites any interested party to bring to its attention any 1950 copyrights, patents or patent applications, or other proprietary 1951 rights that may cover technology that may be required to implement 1952 this standard. Please address the information to the IETF at ietf- 1953 ipr@ietf.org. 1955 Disclaimer 1957 This document and the information contained herein are provided on an 1958 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1959 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1960 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1961 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1962 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1963 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1965 Copyright Notice 1967 Copyright (C) The Internet Society (2005). This document is subject 1968 to the rights, licenses and restrictions contained in BCP 78, and 1969 except as set forth therein, the authors retain all their rights. 1971 Acknowledgements 1973 The authors gratefully acknowledge the contributions of Dr. Vint Cerf 1974 of MCI, Dr. Kevin Fall and Michael Demmer of Intel Corporation, 1975 Adrian Hooke and Leigh Torgerson of the Jet Propulsion Laboratory, 1976 Stephen Farrell of Trinity College Dublin, and Robert Durst and Susan 1977 Symington of The MITRE Corporation. Thanks to Howard Weiss of 1978 SPARTA, Inc., for the text of section 7 and to Manikantan Ramadas of 1979 Ohio University for most of the text of section 3.4, which is adapted 1980 from the specification for the Licklider Transmission Protocol.