idnits 2.17.1 draft-ietf-dtn-bpbis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 11, 2016) is 3020 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ASN1' is defined on line 1953, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay-Tolerant Networking Working Group S. Burleigh 2 Internet Draft JPL, Calif. Inst. Of Technology 3 Intended status: Standards Track K. Fall 4 Expires: December 2015 Carnegie Mellon University / SEI 5 E. Birrane 6 APL, Johns Hopkins University 7 January 11, 2016 9 Bundle Protocol 10 draft-ietf-dtn-bpbis-02.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 This document may contain material from IETF Documents or IETF 18 Contributions published or made publicly available before November 19 10, 2008. The person(s) controlling the copyright in some of this 20 material may not have granted the IETF Trust the right to allow 21 modifications of such material outside the IETF Standards Process. 22 Without obtaining an adequate license from the person(s) controlling 23 the copyright in such materials, this document may not be modified 24 outside the IETF Standards Process, and derivative works of it may 25 not be created outside the IETF Standards Process, except to format 26 it for publication as an RFC or to translate it into languages other 27 than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on July 14, 2016. 47 Internet-Draft Proposed Revised Bundle Protocol January 20166 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Abstract 66 This Internet Draft presents a specification for Bundle Protocol, 67 adapted from the experimental Bundle Protocol specification 68 developed by the Delay-Tolerant Networking Research group of the 69 Internet Research Task Force and documented in RFC 5050. 71 Table of Contents 73 1. Introduction...................................................3 74 2. Conventions used in this document..............................5 75 3. Service Description............................................6 76 3.1. Definitions...............................................6 77 3.2. Discussion of BP concepts.................................9 78 3.3. Services Offered by Bundle Protocol Agents...............14 79 4. Bundle Format.................................................14 80 4.1. Bundle Processing Control Flags..........................14 81 4.2. Block Processing Control Flags...........................16 82 4.3. Identifiers..............................................16 83 4.3.1. Endpoint ID.........................................16 84 4.3.2. Node ID.............................................17 85 4.4. Contents of Bundle Blocks................................17 86 4.4.1. Primary Bundle Block................................17 87 4.4.2. Canonical Bundle Block Format.......................19 88 4.5. Extension Blocks.........................................20 89 4.5.1. Current Custodian...................................20 90 4.5.2. Flow Label..........................................20 91 4.5.3. Previous Node ID....................................21 92 4.5.4. Bundle Age..........................................21 93 4.5.5. Hop Count...........................................21 94 5. Bundle Processing.............................................21 96 Internet-Draft Proposed Revised Bundle Protocol January 20166 98 5.1. Generation of Administrative Records.....................22 99 5.2. Bundle Transmission......................................23 100 5.3. Bundle Dispatching.......................................23 101 5.4. Bundle Forwarding........................................23 102 5.4.1. Forwarding Contraindicated..........................25 103 5.4.2. Forwarding Failed...................................26 104 5.5. Bundle Expiration........................................26 105 5.6. Bundle Reception.........................................27 106 5.7. Local Bundle Delivery....................................28 107 5.8. Bundle Fragmentation.....................................28 108 5.9. Application Data Unit Reassembly.........................30 109 5.10. Custody Transfer........................................30 110 5.10.1. Custody Acceptance.................................30 111 5.10.2. Custody Release....................................31 112 5.11. Custody Transfer Success................................31 113 5.12. Custody Transfer Failure................................31 114 5.13. Bundle Deletion.........................................32 115 5.14. Discarding a Bundle.....................................32 116 5.15. Canceling a Transmission................................32 117 6. Administrative Record Processing..............................33 118 6.1. Administrative Records...................................33 119 6.1.1. Bundle Status Reports...............................33 120 6.1.2. Custody Signals.....................................36 121 6.2. Generation of Administrative Records.....................37 122 6.3. Reception of Custody Signals.............................37 123 7. Services Required of the Convergence Layer....................38 124 7.1. The Convergence Layer....................................38 125 7.2. Summary of Convergence Layer Services....................38 126 8. Security Considerations.......................................38 127 9. IANA Considerations...........................................40 128 10. References...................................................40 129 10.1. Normative References....................................40 130 10.2. Informative References..................................40 131 11. Acknowledgments..............................................41 132 12. Significant Changes from RFC 5050............................41 133 13. Open Issues..................................................42 134 13.1. Application Agent.......................................42 135 13.2. Primary block CRC type..................................42 136 Appendix A. For More Information.................................43 138 1. Introduction 140 Since the publication of the Bundle Protocol Specification 141 (Experimental RFC 5050[RFC5050]) in 2007, the Delay-Tolerant 142 Networking Bundle Protocol has been implemented in multiple 143 programming languages and deployed to a wide variety of computing 144 platforms for a wide range of successful exercises. This 146 Internet-Draft Proposed Revised Bundle Protocol January 20166 148 implementation and deployment experience has demonstrated the 149 general utility of the protocol for challenged network operations. 151 It has also, as expected, identified opportunities for making the 152 protocol simpler, more capable, and easier to use. The present 153 document, standardizing the Bundle Protocol (BP), is adapted from 154 RFC 5050 in that context. 156 This document describes version 7 of BP. 158 Delay Tolerant Networking is a network architecture providing 159 communications in and/or through highly stressed environments. 160 Stressed networking environments include those with intermittent 161 connectivity, large and/or variable delays, and high bit error 162 rates. To provide its services, BP may be viewed as sitting at the 163 application layer of some number of constituent networks, forming a 164 store-carry-forward overlay network. Key capabilities of BP 165 include: 167 . Custodial forwarding 168 . Ability to cope with intermittent connectivity, including cases 169 where the sender and receiver are not concurrently present in 170 the network 171 . Ability to take advantage of scheduled, predicted, and 172 opportunistic connectivity, whether bidirectional or 173 unidirectional, in addition to continuous connectivity 174 . Late binding of overlay network endpoint identifiers to 175 underlying constituent network addresses 177 For descriptions of these capabilities and the rationale for the DTN 178 architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial- 179 level overview of DTN concepts. 181 BP's location within the standard protocol stack is as shown in 182 Figure 1. BP uses underlying "native" transport and/or network 183 protocols for communications within a given constituent network. 185 The interface between the bundle protocol and a specific underlying 186 protocol is termed a "convergence layer adapter". 188 Figure 1 shows three distinct transport and network protocols 189 (denoted T1/N1, T2/N2, and T3/N3). 191 Internet-Draft Proposed Revised Bundle Protocol January 20166 193 +-----------+ +-----------+ 194 | BP app | | BP app | 195 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 196 | BP v | | ^ BP v | | ^ BP v | | ^ BP | 197 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 198 | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | 199 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 200 | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | 201 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 202 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 203 +-----------+ +-------------+ +-------------+ +-----------+ 204 | | | | 205 |<---- A network ---->| |<---- A network ---->| 206 | | | | 208 Figure 1: The Bundle Protocol in the Protocol Stack Model 210 This document describes the format of the protocol data units 211 (called "bundles") passed between entities participating in BP 212 communications. 214 The entities are referred to as "bundle nodes". This document does 215 not address: 217 . Operations in the convergence layer adapters that bundle nodes 218 use to transport data through specific types of internets. 219 (However, the document does discuss the services that must be 220 provided by each adapter at the convergence layer.) 221 . The bundle route computation algorithm. 222 . Mechanisms for populating the routing or forwarding information 223 bases of bundle nodes. 224 . The mechanisms for securing bundles en-route. 225 . The mechanisms for managing bundle nodes. 227 2. Conventions used in this document 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in RFC-2119 [RFC2119]. 233 In this document, these words will appear with that interpretation 234 only when in ALL CAPS. Lower case uses of these words are not to be 235 interpreted as carrying RFC-2119 significance. 237 Internet-Draft Proposed Revised Bundle Protocol January 20166 239 3. Service Description 241 3.1. Definitions 243 Bundle - A bundle is a protocol data unit of BP, so named because 244 negotiation of the parameters of a data exchange may be impractical 245 in a delay-tolerant network: it is often better practice to "bundle" 246 with a unit of data all metadata that might be needed in order to 247 make the data immediately usable when delivered to applications. 248 Each bundle comprises a sequence of two or more "blocks" of protocol 249 data, which serve various purposes. 251 Block - A bundle protocol block is one of the protocol data 252 structures that together constitute a well-formed bundle. 254 Bundle payload - A bundle payload (or simply "payload") is the 255 application data whose conveyance to the bundle's destination is the 256 purpose for the transmission of a given bundle; it is the content of 257 the bundle's payload block. The terms "bundle content", "bundle 258 payload", and "payload" are used interchangeably in this document. 260 Partial payload - A partial payload is a payload that comprises 261 either the first N bytes or the last N bytes of some other payload 262 of length M, such that 0 < N < M. 264 Fragment - A fragment is a bundle whose payload block contains a 265 partial payload. 267 Bundle node - A bundle node (or, in the context of this document, 268 simply a "node") is any entity that can send and/or receive bundles. 269 Each bundle node has three conceptual components, defined below: a 270 "bundle protocol agent", a set of zero or more "convergence layer 271 adapters", and an "application agent". 273 Bundle protocol agent - The bundle protocol agent (BPA) of a node is 274 the node component that offers the BP services and executes the 275 procedures of the bundle protocol. 277 Convergence layer adapter - A convergence layer adapter (CLA) is a 278 node component that sends and receives bundles on behalf of the BPA, 279 utilizing the services of some 'native' protocol stack that is 280 supported in one of the networks within which the node is 281 functionally located. 283 Application agent - The application agent (AA) of a node is the node 284 component that utilizes the BP services to effect communication for 286 Internet-Draft Proposed Revised Bundle Protocol January 20166 288 some user purpose. The application agent in turn has two elements, 289 an administrative element and an application-specific element. 291 Application-specific element - The application-specific element of 292 an AA is the node component that constructs, requests transmission 293 of, accepts delivery of, and processes units of user application 294 data. 296 Administrative element - The administrative element of an AA is the 297 node component that constructs and requests transmission of 298 administrative records (defined below), including status reports and 299 custody signals, and accepts delivery of and processes any custody 300 signals that the node receives. 302 Administrative record - A BP administrative record is an application 303 data unit that is exchanged between the administrative elements of 304 nodes' application agents for some BP administrative purpose. The 305 formats of some fundamental administrative records (and of no other 306 application data units) are defined in this specification. 308 Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set 309 of zero or more bundle nodes that all identify themselves for BP 310 purposes by some common identifier, called a "bundle endpoint ID" 311 (or, in this document, simply "endpoint ID"; endpoint IDs are 312 described in detail in Section 4.3.1 below). 314 Singleton endpoint - A singleton endpoint is an endpoint that always 315 contains exactly one member. 317 Registration - A registration is the state machine characterizing a 318 given node's membership in a given endpoint. Any single 319 registration has an associated delivery failure action as defined 320 below and must at any time be in one of two states: Active or 321 Passive. 323 Delivery - A bundle is considered to have been delivered at a node 324 subject to a registration as soon as the application data unit that 325 is the payload of the bundle, together with any relevant metadata 326 (an implementation matter), has been presented to the node's 327 application agent in a manner consistent with the state of that 328 registration. 330 Deliverability - A bundle is considered "deliverable" subject to a 331 registration if and only if (a) the bundle's destination endpoint is 332 the endpoint with which the registration is associated, (b) the 333 bundle has not yet been delivered subject to this registration, and 335 Internet-Draft Proposed Revised Bundle Protocol January 20166 337 (c) the bundle has not yet been "abandoned" (as defined below) 338 subject to this registration. 340 Abandonment - To abandon a bundle subject to some registration is to 341 assert that the bundle is not deliverable subject to that 342 registration. 344 Delivery failure action - The delivery failure action of a 345 registration is the action that is to be taken when a bundle that is 346 "deliverable" subject to that registration is received at a time 347 when the registration is in the Passive state. 349 Destination - The destination of a bundle is the endpoint comprising 350 the node(s) at which the bundle is to be delivered (as defined 351 below). 353 Minimum transmission group - The minimum transmission group of an 354 endpoint is the minimum number of members of the endpoint (nodes) at 355 which the bundle must have been delivered in order for the bundle to 356 be considered delivered to the endpoint. 358 Transmission - A transmission is an attempt by a node's BPA to cause 359 copies of a bundle to be delivered at all nodes in the minimum 360 reception group of some endpoint (the bundle's destination) in 361 response to a transmission request issued by the node's application 362 agent. 364 Forwarding - To forward a bundle to a node is to invoke the services 365 of a CLA in a sustained effort to cause a copy of the bundle to be 366 received by that node. 368 Discarding - To discard a bundle is to cease all operations on the 369 bundle and functionally erase all references to it. The specific 370 procedures by which this is accomplished are an implementation 371 matter. 373 Retention constraint - A retention constraint is an element of the 374 state of a bundle that prevents the bundle from being discarded. 375 That is, a bundle cannot be discarded while it has any retention 376 constraints. 378 Deletion - To delete a bundle is to remove unconditionally all of 379 the bundle's retention constraints, enabling the bundle to be 380 discarded. 382 Custodian - A custodian of a bundle is a node that has determined 383 that it will retain a copy of that bundle for an indefinite period 385 Internet-Draft Proposed Revised Bundle Protocol January 20166 387 of time, forwarding and possibly re-forwarding the bundle as 388 appropriate, until it detects one of the conditions under which it 389 may cease being a custodian of that bundle (discussed later). 391 Taking custody - To take custody of a bundle is to become a 392 custodian of that bundle. 394 Accepting custody - To accept custody of a bundle is to take custody 395 of the bundle, mark the bundle in such a way as to indicate this 396 custodianship to nodes that subsequently receive copies of the 397 bundle, and announce this custodianship to all current custodians of 398 the bundle. 400 Refusing custody - To "refuse custody" of a bundle is to notify all 401 current custodians of that bundle that an opportunity to take 402 custody of the bundle has been declined. 404 Releasing custody - To release custody of a bundle is to cease to be 405 a custodian of the bundle. 407 3.2. Discussion of BP concepts 409 Multiple instances of the same bundle (the same unit of DTN protocol 410 data) might exist concurrently in different parts of a network -- 411 possibly in different representations and/or differing in some 412 blocks -- in the memory local to one or more bundle nodes and/or in 413 transit between nodes. In the context of the operation of a bundle 414 node, a bundle is an instance (copy), in that node's local memory, 415 of some bundle that is in the network. 417 The payload for a bundle forwarded in response to a bundle 418 transmission request is the application data unit whose location is 419 provided as a parameter to that request. The payload for a bundle 420 forwarded in response to reception of a bundle is the payload of the 421 received bundle. 423 In the most familiar case, a bundle node is instantiated as a single 424 process running on a general-purpose computer, but in general the 425 definition is meant to be broader: a bundle node might alternatively 426 be a thread, an object in an object-oriented operating system, a 427 special-purpose hardware device, etc. 429 The manner in which the functions of the BPA are performed is wholly 430 an implementation matter. For example, BPA functionality might be 431 coded into each node individually; it might be implemented as a 432 shared library that is used in common by any number of bundle nodes 433 on a single computer; it might be implemented as a daemon whose 435 Internet-Draft Proposed Revised Bundle Protocol January 20166 437 services are invoked via inter-process or network communication by 438 any number of bundle nodes on one or more computers; it might be 439 implemented in hardware. 441 Every CLA implements its own thin layer of protocol, interposed 442 between BP and the (usually "top") protocol(s) of the underlying 443 native protocol stack; this "CL protocol" may only serve to 444 multiplex and de-multiplex bundles to and from the underlying native 445 protocol, or it may offer additional CL-specific functionality. The 446 manner in which a CLA sends and receives bundles is, again, wholly 447 an implementation matter. The definitions of CLAs and CL protocols 448 are beyond the scope of this specification. 450 Note that the administrative element of a node's application agent 451 may itself, in some cases, function as a convergence-layer adapter. 452 That is, outgoing bundles may be "tunneled" through encapsulating 453 bundles: 455 . An outgoing bundle that has been encoded in some documented 456 representation constitutes a byte array. This byte array may, 457 like any other, be presented to the bundle protocol agent as an 458 application data unit that is to be transmitted to some 459 endpoint. 460 . The original encoded bundle thus forms the payload of an 461 encapsulating bundle that is forwarded using some other 462 convergence-layer protocol(s). 463 . When the encapsulating bundle is received, its payload is 464 delivered to the peer application agent administrative element, 465 which then instructs the bundle protocol agent to dispatch that 466 original encoded bundle in the usual way. 468 The purposes for which this technique may be useful (such as cross- 469 domain security) are beyond the scope of this specification. 471 The only interface between the BPA and the application-specific 472 element of the AA is the BP service interface. But between the BPA 473 and the administrative element of the AA there is a (conceptual) 474 private control interface in addition to the BP service interface. 475 This private control interface enables the BPA and the 476 administrative element of the AA to direct each other to take action 477 under specific circumstances 479 In the case of a node that serves simply as a BP "router", the AA 480 may have no application-specific element at all. The application- 481 specific elements of other nodes' AAs may perform arbitrarily 482 complex application functions, perhaps even offering multiplexed DTN 483 communication services to a number of other applications. As with 485 Internet-Draft Proposed Revised Bundle Protocol January 20166 487 the BPA, the manner in which the AA performs its functions is wholly 488 an implementation matter. 490 Singletons are the most familiar sort of endpoint, but in general 491 the endpoint notion is meant to be broader. For example, the nodes 492 in a sensor network might constitute a set of bundle nodes that 493 identify themselves by a single common endpoint ID and thus form a 494 single bundle endpoint. *Note* too that a given bundle node might 495 identify itself by multiple endpoint IDs and thus be a member of 496 multiple bundle endpoints. 498 The destination of every bundle is an endpoint, which may or may not 499 be singleton. The source of every bundle is a node, identified by 500 the endpoint ID for some singleton endpoint that contains that node. 502 Upon reception, the processing of a bundle that has been received by 503 a given node depends on whether or not the receiving node is 504 registered in the bundle's destination endpoint. If it is, and if 505 the payload of the bundle is non-fragmentary (possibly as a result 506 of successful payload reassembly from fragmentary payloads, 507 including the original payload of the newly received bundle), then 508 the bundle is normally "delivered" to the node's application agent 509 subject to the registration characterizing the node's membership in 510 the destination endpoint. 512 The minimum reception group of an endpoint may be any one of the 513 following: (a) ALL of the nodes registered in an endpoint that is 514 permitted to contain multiple nodes (in which case forwarding to the 515 endpoint is functionally similar to "multicast" operations in the 516 Internet, though possibly very different in implementation); (b) ANY 517 N of the nodes registered in an endpoint that is permitted to 518 contain multiple nodes, where N is in the range from zero to the 519 cardinality of the endpoint; or (c) THE SOLE NODE registered in a 520 singleton endpoint (in which case forwarding to the endpoint is 521 functionally similar to "unicast" operations in the Internet). 523 The nature of the minimum reception group for a given endpoint can 524 typically be determined from the endpoint's ID. For some endpoint 525 ID "schemes", the nature of the minimum reception group is fixed - 526 in a manner that is defined by the scheme - for all endpoints 527 identified under the scheme. For other schemes, the nature of the 528 minimum reception group is indicated by some lexical feature of the 529 "scheme-specific part" of the endpoint ID, in a manner that is 530 defined by the scheme. 532 Any number of transmissions may be concurrently undertaken by the 533 bundle protocol agent of a given node. 535 Internet-Draft Proposed Revised Bundle Protocol January 20166 537 When the bundle protocol agent of a node determines that a bundle 538 must be forwarded to a node (either to a node that is a member of 539 the bundle's destination endpoint or to some intermediate forwarding 540 node) in the course of completing the successful transmission of 541 that bundle, it invokes the services of a CLA in a sustained effort 542 to cause a copy of the bundle to be received by that node. 544 Upon reception, the processing of a bundle that has been received by 545 a given node depends on whether or not the receiving node is 546 registered in the bundle's destination endpoint. If it is, and if 547 the payload of the bundle is non-fragmentary (possibly as a result 548 of successful payload reassembly from fragmentary payloads, 549 including the original payload of the newly received bundle), then 550 the bundle is normally delivered to the node's application agent 551 subject to the registration characterizing the node's membership in 552 the destination endpoint. 554 Whenever, for some implementation-specific reason, a node's BPA 555 finds it impossible to immediately deliver a bundle that is 556 deliverable, delivery of the bundle has failed. In this event, the 557 delivery failure action associated with the applicable registration 558 must be taken. Delivery failure action MUST be one of the following: 560 . defer delivery of the bundle subject to this registration until 561 (a) this bundle is the least recently received of all bundles 562 currently deliverable subject to this registration and (b) 563 either the registration is polled or else the registration is 564 in the Active state; or 566 . abandon delivery of the bundle subject to this registration. 568 An additional implementation-specific delivery deferral procedure 569 MAY optionally be associated with the registration. 571 While the state of a registration is Passive, reception of a bundle 572 that is deliverable subject to this registration MUST cause delivery 573 of the bundle to be abandoned or deferred as mandated by the 574 registration's current delivery failure action; in the latter case, 575 any additional delivery deferral procedure associated with the 576 registration MUST also be performed. 578 While the state of a registration is Active, reception of a bundle 579 that is deliverable subject to this registration MUST cause the 580 bundle to be delivered automatically as soon as it is the next 581 bundle that is due for delivery according to the BPA's bundle 582 delivery scheduling policy, an implementation matter. 584 Internet-Draft Proposed Revised Bundle Protocol January 20166 586 Normally only registrations' registered delivery failure actions 587 cause deliveries to be abandoned. 589 Custody of a bundle MAY be taken only if the destination of the 590 bundle is a singleton endpoint. Custody MAY be released only when 591 either (a) notification is received that some other node has 592 accepted custody of the same bundle; (b) notification is received 593 that the bundle has been delivered at the (sole) node registered in 594 the bundle's destination endpoint; (c) the current custodian chooses 595 to fragment the bundle, releasing custody of the original bundle and 596 taking custody of the fragments instead, or (d) the bundle is 597 explicitly deleted for some reason, such as lifetime expiration. 599 The custody transfer mechanism in BP is primarily intended as a 600 means of recovering from forwarding failures. When a bundle arrives 601 at a node from which it must be forwarded, but forwarding is 602 impossible, BP must recover from this error. BP can "return" the 603 bundle back toward some node for forwarding along some other path in 604 the network, or else it can instead send a small "signal" bundle 605 back to such a node, in the event that this node has retained a copy 606 of the bundle ("taken custody") and is therefore able to re-forward 607 the bundle without receiving a copy. Custody transfer sharply 608 reduces the network traffic required for recovery from forwarding 609 failures, at the cost of increased buffer occupancy and state 610 management at the custodial nodes. 612 Note that custodial re-forwarding can also be initiated by 613 expiration of a timer prior to reception of a custody acceptance or 614 refusal signal. Since the absence of a custody acceptance signal 615 might be caused by failure to receive the bundle, rather than only a 616 disinclination to take custody, custody transfer can additionally 617 serve as an automated retransmission mechanism. 619 However, because custody transfer's only remedy for loss of any part 620 of a bundle is retransmission of the entire bundle (not just the 621 lost portion), custody transfer is a less efficient automated 622 retransmission mechanism than the reliable transport protocols that 623 are typically available at the convergence layer; configuring BPAs 624 to use reliable convergence-layer protocols between nodes is 625 generally the best means of ensuring bundle delivery at the 626 destination node(s). But there are some use cases (typically 627 involving unidirectional links) in which custody transfer in BP may 628 be a more cost-effective solution for reliable transmission between 629 two BP agents than invoking retransmission protocols at the 630 convergence layer. 632 Internet-Draft Proposed Revised Bundle Protocol January 20166 634 3.3. Services Offered by Bundle Protocol Agents 636 The BPA of each node is expected to provide the following services 637 to the node's application agent: 639 . commencing a registration (registering the node in an 640 endpoint); 641 . terminating a registration; 642 . switching a registration between Active and Passive states; 643 . transmitting a bundle to an identified bundle endpoint; 644 . canceling a transmission; 645 . polling a registration that is in the Passive state; 646 . delivering a received bundle. 648 4. Bundle Format 650 NOTE that only the abstract structures of blocks are defined here. 651 The specific bitstream that is emitted when a CLA sends a bundle 652 will be dictated by the applicable bundle representation 653 specification to which the sending and receiving nodes conform, an 654 implementation matter. It is important to note that not all BP 655 implementations are required to implement all bundle representation 656 specifications. The BP implementations used to instantiate nodes in 657 a given network must be chosen with care in order for every node to 658 be able to exchange bundles with every other node. Bundle 659 representation specifications are beyond the scope of this document. 661 Each bundle SHALL be a concatenated sequence of at least two blocks. 662 The first block in the sequence MUST be a primary bundle block, and 663 the bundle MUST have exactly one primary bundle block. Additional 664 bundle protocol blocks of other types MAY follow the primary block 665 to support extensions to the bundle protocol, such as the Bundle 666 Security Protocol [BPSEC]. Exactly one of the blocks in the sequence 667 MUST be a payload block, and the payload block MUST be the last 668 block in the sequence. 670 4.1. Bundle Processing Control Flags 672 Bundle processing control flags assert properties of the bundle as a 673 whole rather than of any particular block of the bundle. They are 674 conveyed in the primary block of the bundle. 676 The following properties are asserted by the bundle processing 677 control flags: 679 . The bundle is a fragment. (Boolean) 681 Internet-Draft Proposed Revised Bundle Protocol January 20166 683 . The bundle's payload is an administrative record. (Boolean) 685 . The bundle must not be fragmented. (Boolean) 687 . Custody transfer is requested for this bundle. (Boolean) 689 . The bundle's destination endpoint is a singleton. (Boolean) 691 . Acknowledgment by the user application is requested. (Boolean) 693 . Status time is requested in all status reports. (Boolean) 695 . Type of CRC that is present in the bundle's primary block. (An 696 unsigned integer CRC type code; 0 indicates that the block 697 contains no CRC, other valid values TBD) 699 . Flags requesting types of status reports (all Boolean): 701 o Request reporting of bundle reception. 703 o Request reporting of custody acceptance. 705 o Request reporting of bundle forwarding. 707 o Request reporting of bundle delivery. 709 o Request reporting of bundle deletion. 711 If the bundle processing control flags indicate that the bundle's 712 application data unit is an administrative record, then the custody 713 transfer requested flag value must be zero and all status report 714 request flag values must be zero. 716 If the custody transfer requested flag is 1, then the source node is 717 requesting that every receiving node accept custody of the bundle. 719 If the bundle's source node is omitted (i.e., the source endpoint ID 720 is the null endpoint, which has no members as discussed below), then 721 the bundle is not uniquely identifiable and all bundle protocol 722 features that rely on bundle identity must therefore be disabled: 723 the bundle's custody transfer requested flag value must be zero, the 724 "Bundle must not be fragmented" flag value must be 1, and all status 725 report request flag values must be zero. 727 Internet-Draft Proposed Revised Bundle Protocol January 20166 729 4.2. Block Processing Control Flags 731 The block processing control flags assert properties of individual 732 bundle blocks other than the primary block. They are conveyed in 733 the header of the block to which they pertain. 735 The following properties are asserted by the block processing 736 control flags: 738 . This block must be replicated in every fragment. (Boolean) 740 . Status report must be transmitted if this block can't be 741 processed. (Boolean) 743 . Block must be removed from the bundle if it can't be processed. 744 (Boolean) 746 . Bundle must be deleted if this block can't be processed. 747 (Boolean) 749 For each bundle whose bundle processing control flags indicate that 750 the bundle's application data unit is an administrative record, the 751 value of the "Transmit status report if block can't be processed" 752 flag in every block of the bundle other than the primary block must 753 be zero. 755 4.3. Identifiers 757 4.3.1. Endpoint ID 759 The destinations of bundles are bundle endpoints, identified by text 760 strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID 761 (EID) conveyed in any bundle block takes the form of a Uniform 762 Resource Identifier (URI; [URI]). As such, each endpoint ID can be 763 characterized as having this general structure: 765 < scheme name > : < scheme-specific part, or "SSP" > 767 The scheme identified by the < scheme name > in an endpoint ID is a 768 set of syntactic and semantic rules that fully explain how to parse 769 and interpret the SSP. The set of allowable schemes is effectively 770 unlimited. Any scheme conforming to [URIREG] may be used in a bundle 771 protocol endpoint ID. 773 Note that, although endpoint IDs are URIs, implementations of the BP 774 service interface may support expression of endpoint IDs in some 776 Internet-Draft Proposed Revised Bundle Protocol January 20166 778 internationalized manner (e.g., Internationalized Resource 779 Identifiers (IRIs); see [RFC3987]). 781 Note also that the representation of an EID in the bitstream that is 782 emitted when a CLA sends a bundle will be dictated by the applicable 783 bundle representation specification to which the sending and 784 receiving nodes conform, an implementation matter. 786 The endpoint ID "dtn:none" identifies the "null endpoint", the 787 endpoint that by definition never has any members. 789 4.3.2. Node ID 791 For many purposes of the Bundle Protocol it is important to identify 792 the node that is operative in some context. 794 As discussed in 3.1 above, nodes are distinct from endpoints; 795 specifically, an endpoint is a set of zero or more nodes. But 796 rather than define a separate namespace for node identifiers, we 797 instead use endpoint identifiers to identify nodes, subject to the 798 following restrictions: 800 . Every node MUST be a member of at least one singleton endpoint. 801 . The EID of any singleton endpoint of which a node is a member 802 MAY be used to identify that node. A "node ID" is an EID that 803 is used in this way. 804 . A node's membership in a given singleton endpoint MUST be 805 sustained at least until the nominal operation of the Bundle 806 Protocol no longer depends on the identification of that node 807 using that endpoint's ID. 809 4.4. Contents of Bundle Blocks 811 This section describes the contents of the primary block in detail 812 and the contents of all non-primary blocks in general. Rules for 813 processing these blocks appear in Section 5 of this document. 815 Note that supplementary DTN protocol specifications (including, but 816 not restricted to, the Bundle Security Protocol [BPSEC]) may require 817 that BP implementations conforming to those protocols construct and 818 process additional blocks. 820 4.4.1. Primary Bundle Block 822 The primary bundle block contains the basic information needed to 823 forward bundles to their destinations. The fields of the primary 824 bundle block are: 826 Internet-Draft Proposed Revised Bundle Protocol January 20166 828 Version: An unsigned integer value indicating the version of the 829 bundle protocol that constructed this block. The present document 830 describes version 7 of the bundle protocol. 832 Bundle Processing Control Flags: The Bundle Processing Control Flags 833 are discussed in Section 4.1 above. 835 Destination EID: The Destination EID field identifies the bundle 836 endpoint that is the bundle's destination, i.e., the endpoint that 837 contains the node(s) at which the bundle is to be delivered. 839 Source node ID: The Source node ID field identifies the bundle node 840 at which the bundle was initially transmitted, except that Source 841 node ID may be the null endpoint ID in the event that the bundle's 842 source chooses to remain anonymous. 844 Report-to EID: The Report-to EID field identifies the bundle 845 endpoint to which status reports pertaining to the forwarding and 846 delivery of this bundle are to be transmitted. 848 Creation Timestamp: The creation timestamp is a pair of unsigned 849 integers that, together with the source node ID and (if the bundle 850 is a fragment) the fragment offset and payload length, serve to 851 identify the bundle. The first of these integers is the bundle's 852 creation time, while the second is the bundle's creation timestamp 853 sequence number. Bundle creation time is the time - expressed in 854 seconds since the start of the year 2000, on the Coordinated 855 Universal Time (UTC) scale [UTC] - at which the transmission request 856 was received that resulted in the creation of the bundle. Sequence 857 count is the latest value (as of the time at which that transmission 858 request was received) of a monotonically increasing positive integer 859 counter managed by the source node's bundle protocol agent that may 860 be reset to zero whenever the current time advances by one second. 861 For nodes that lack accurate clocks (that is, nodes that are not at 862 all moments able to determine the current UTC time to within 30 863 seconds), bundle creation time MUST be set to zero and the counter 864 used as the source of the bundle sequence count MUST NEVER be reset 865 to zero. In any case, a source Bundle Protocol Agent must never 866 create two distinct bundles with the same source node ID and bundle 867 creation timestamp. The combination of source node ID and bundle 868 creation timestamp serves to identify a single transmission request, 869 enabling it to be acknowledged by the receiving application 870 (provided the source node ID is not the null endpoint ID). 872 Lifetime: The lifetime field is an unsigned integer that indicates 873 the time at which the bundle's payload will no longer be useful, 874 encoded as a number of seconds past the creation time. When a 876 Internet-Draft Proposed Revised Bundle Protocol January 20166 878 bundle's age exceeds its lifetime, bundle nodes need no longer 879 retain or forward the bundle; the bundle SHOULD be deleted from the 880 network. 882 The CRC field of the Primary Bundle Block is present only if the CRC 883 type field in the block's processing flags field is non-zero. 885 Fragment Offset: If and only if the Bundle Processing Control Flags 886 of this Primary block indicate that the bundle is a fragment, then 887 the Fragment Offset field SHALL be an unsigned integer indicating 888 the offset from the start of the original application data unit at 889 which the bytes comprising the payload of this bundle were located. 890 If not, then the Fragment Offset field SHALL be omitted from the 891 block. 893 Total Application Data Unit Length: If and only if the Bundle 894 Processing Control Flags of this Primary block indicate that the 895 bundle is a fragment, then the Total Application Data Unit Length 896 field SHALL be an unsigned integer indicating the total length of 897 the original application data unit of which this bundle's payload is 898 a part. If not, then the Total Application Data Unit Length field 899 SHALL be omitted from the block. 901 If and only if the CRC type in the Bundle Processing Control Flags 902 of this Primary block is non-zero, a CRC SHALL be present the 903 primary block. The length and nature of the CRC SHALL be as 904 indicated by the CRC type. The CRC SHALL be computed over the 905 concatenation of all bytes of the primary block including the CRC 906 field itself, which for this purpose is temporarily populated with 907 the value zero. 909 4.4.2. Canonical Bundle Block Format 911 Every bundle block of every type other than the primary bundle block 912 comprises the following fields, in this order: 914 . Block type code, an unsigned integer. Bundle block type code 1 915 indicates that the block is a bundle payload block. Block type 916 codes 2 through 9 are explicitly reserved as noted later in 917 this specification. Block type codes 192 through 255 are not 918 reserved and are available for private and/or experimental use. 919 All other block type code values are reserved for future use. 920 . Block number, an unsigned integer. The block number uniquely 921 identifies the block within the bundle, enabling blocks 922 (notably bundle security protocol blocks) to explicitly 923 reference other blocks in the same bundle. Block numbers need 924 not be in continuous sequence, and blocks need not appear in 926 Internet-Draft Proposed Revised Bundle Protocol January 20166 928 block number sequence in the bundle. The block number of the 929 payload block is always zero. 930 . Block processing control flags as discussed above. 931 . Block data length, an unsigned integer. The block data length 932 field contains the aggregate length of all remaining fields of 933 the block, i.e., the block-type-specific data fields. 934 . Block-type-specific data fields, whose nature and order are 935 type-specific and whose aggregate length in octets is the value 936 of the block data length field. For the Payload Block in 937 particular (block type 1), there SHALL be exactly one block- 938 type-specific data field, the "payload", i.e., the application 939 data carried by this bundle. 941 4.5. Extension Blocks 943 "Extension blocks" are all blocks other than the primary and payload 944 blocks. Because not all extension blocks are defined in the Bundle 945 Protocol specification (the present document), not all nodes 946 conforming to this specification will necessarily instantiate Bundle 947 Protocol implementations that include procedures for processing 948 (that is, recognizing, parsing, acting on, and/or producing) all 949 extension blocks. It is therefore possible for a node to receive a 950 bundle that includes extension blocks that the node cannot process. 951 The values of the block processing control flags indicate the action 952 to be taken by the bundle protocol agent when this is the case. 954 The extension blocks of the Bundle Security Protocol (block types 2 955 and 3) are defined separately in the Bundle Security Protocol 956 specification (work in progress). 958 The following extension blocks are defined in the current document. 960 4.5.1. Current Custodian 962 The Current Custodian block, block type 5, identifies a node that is 963 known to have accepted custody of the bundle. The block-type- 964 specific data of this block is the node ID of a custodian. The 965 bundle MAY contain one or more occurrences of this type of block. 967 4.5.2. Flow Label 969 The Flow Label block, block type 6, indicates the flow label that is 970 intended to govern transmission of the bundle by convergence-layer 971 adapters. The syntax and semantics of BP flow labels are beyond the 972 scope of this document. 974 Internet-Draft Proposed Revised Bundle Protocol January 20166 976 4.5.3. Previous Node ID 978 The Previous Node ID block, block type 7, identifies the node that 979 forwarded this bundle to the local node; its block-type-specific 980 data is the node ID of that node. If the local node is the source 981 of the bundle, then the bundle MUST NOT contain any Previous Node ID 982 block. Otherwise the bundle MUST contain one (1) occurrence of this 983 type of block. If present, the Previous Node ID block MUST be the 984 FIRST block following the primary block, as the processing of other 985 extension blocks may depend on its value. 987 4.5.4. Bundle Age 989 The Bundle Age block, block type 8, contains the number of seconds 990 that have elapsed between the time the bundle was created and time 991 at which it was most recently forwarded. It is intended for use by 992 nodes lacking access to an accurate clock, to aid in determining the 993 time at which a bundle's lifetime expires. The block-type-specific 994 data of this block is an unsigned integer containing the age of the 995 bundle (the sum of all known intervals of the bundle's residence at 996 forwarding nodes, up to the time at which the bundle was most 997 recently forwarded) in seconds. If the bundle's creation time is 998 zero, then the bundle MUST contain exactly one (1) occurrence of 999 this type of block; otherwise, the bundle MAY contain at most one 1000 (1) occurrence of this type of block. 1002 4.5.5. Hop Count 1004 The Hop Count block, block type 9, contains two unsigned integers, 1005 hop limit and hop count. It is mainly intended as a safety 1006 mechanism, a means of identifying bundles for removal from the 1007 network that can never be delivered due to a persistent forwarding 1008 error: a bundle may be deleted when its hop count exceeds its hop 1009 limit. Procedures for determining the appropriate hop limit for a 1010 block are beyond the scope of this specification. A bundle MAY 1011 contain at most one (1) occurrence of this type of block. 1013 5. Bundle Processing 1015 The bundle processing procedures mandated in this section and in 1016 Section 6 govern the operation of the Bundle Protocol Agent and the 1017 Application Agent administrative element of each bundle node. They 1018 are neither exhaustive nor exclusive. Supplementary DTN protocol 1019 specifications (including, but not restricted to, the Bundle 1020 Security Protocol [BPSEC]) may augment, override, or supersede the 1021 mandates of this document. 1023 Internet-Draft Proposed Revised Bundle Protocol January 20166 1025 5.1. Generation of Administrative Records 1027 All transmission of bundles is in response to bundle transmission 1028 requests presented by nodes' application agents. When required to 1029 "generate" an administrative record (such as a bundle status report 1030 or a custody signal), the bundle protocol agent itself is 1031 responsible for causing a new bundle to be transmitted, conveying 1032 that record. In concept, the bundle protocol agent discharges this 1033 responsibility by directing the administrative element of the node's 1034 application agent to construct the record and request its 1035 transmission as detailed in Section 6 below. In practice, the manner 1036 in which administrative record generation is accomplished is an 1037 implementation matter, provided the constraints noted in Section 6 1038 are observed. 1040 Under some circumstances, the requesting of status reports could 1041 result in an unacceptable increase in the bundle traffic in the 1042 network. For this reason, the generation of status reports is 1043 mandatory only in one case, the deletion of a bundle for which 1044 custody transfer is requested. In all other cases, the decision on 1045 whether or not to generate a requested status report is left to the 1046 discretion of the bundle protocol agent. Mechanisms that could 1047 assist in making such decisions, such as pre-placed agreements 1048 authorizing the generation of status reports under specified 1049 circumstances, are beyond the scope of this specification. 1051 Notes on administrative record terminology: 1053 . A "bundle reception status report" is a bundle status report 1054 with the "reporting node received bundle" flag set to 1. 1055 . A "custody acceptance status report" is a bundle status report 1056 with the "reporting node accepted custody of bundle" flag set 1057 to 1. 1058 . A "bundle forwarding status report" is a bundle status report 1059 with the "reporting node forwarded the bundle" flag set to 1. 1060 . A "bundle delivery status report" is a bundle status report 1061 with the "reporting node delivered the bundle" flag set to 1. 1062 . A "bundle deletion status report" is a bundle status report 1063 with the "reporting node deleted the bundle" flag set to 1. 1064 . A "Succeeded" custody signal is a custody signal with the 1065 "custody transfer succeeded" flag set to 1. 1066 . A "Failed" custody signal is a custody signal with the "custody 1067 transfer succeeded" flag set to zero. 1068 . A "current custodian" of a bundle is a node identified in a 1069 Current Custodian extension block of that bundle. 1071 Internet-Draft Proposed Revised Bundle Protocol January 20166 1073 5.2. Bundle Transmission 1075 The steps in processing a bundle transmission request are: 1077 Step 1: If custody transfer is requested for this bundle 1078 transmission then the destination MUST be a singleton endpoint. If, 1079 moreover, custody acceptance by the source node is required but the 1080 conditions under which custody of the bundle may be accepted are not 1081 satisfied, then the request cannot be honored and all remaining 1082 steps of this procedure MUST be skipped. 1084 Step 2: Transmission of the bundle is initiated. An outbound bundle 1085 MUST be created per the parameters of the bundle transmission 1086 request, with the retention constraint "Dispatch pending". The 1087 source node ID of the bundle MUST be either the null endpoint ID, 1088 indicating that the source of the bundle is anonymous, or else the 1089 EID of a singleton endpoint whose only member is the node of which 1090 the BPA is a component. 1092 Step 3: Processing proceeds from Step 1 of Section 5.4. 1094 5.3. Bundle Dispatching 1096 The steps in dispatching a bundle are: 1098 Step 1: If the bundle's destination endpoint is an endpoint of which 1099 the node is a member, the bundle delivery procedure defined in 1100 Section 5.7 MUST be followed. 1102 Step 2: Processing proceeds from Step 1 of Section 5.4. 1104 5.4. Bundle Forwarding 1106 The steps in forwarding a bundle are: 1108 Step 1: The retention constraint "Forward pending" MUST be added to 1109 the bundle, and the bundle's "Dispatch pending" retention constraint 1110 MUST be removed. 1112 Step 2: The bundle protocol agent MUST determine whether or not 1113 forwarding is contraindicated for any of the reasons listed in 1114 Figure 12. In particular: 1116 . The bundle protocol agent MUST determine which node(s) to 1117 forward the bundle to. The bundle protocol agent MAY choose 1118 either to forward the bundle directly to its destination 1119 node(s) (if possible) or to forward the bundle to some other 1121 Internet-Draft Proposed Revised Bundle Protocol January 20166 1123 node(s) for further forwarding. The manner in which this 1124 decision is made may depend on the scheme name in the 1125 destination endpoint ID and/or on other state but in any case 1126 is beyond the scope of this document. If the BPA elects to 1127 forward the bundle to some other node(s) for further forwarding 1128 but finds it impossible to select any node(s) to forward the 1129 bundle to, then forwarding is contraindicated. 1130 o 1131 o 1132 . Provided the bundle protocol agent succeeded in selecting the 1133 node(s) to forward the bundle to, the bundle protocol agent 1134 MUST select the convergence layer adapter(s) whose services 1135 will enable the node to send the bundle to those nodes. The 1136 manner in which specific appropriate convergence layer adapters 1137 are selected is beyond the scope of this document. If the agent 1138 finds it impossible to select any appropriate convergence layer 1139 adapter(s) to use in forwarding this bundle, then forwarding is 1140 contraindicated. 1141 . Provided the bundle protocol agent succeeded in selecting the 1142 node(s) to forward the bundle to and additionally succeeded in 1143 selecting the appropriate convergence layer adapter(s), the 1144 bundle protocol agent MUST determine the applicable bundle 1145 representation by which the bundle must be encoded when sent to 1146 each such node so that the bundle will be intelligible when 1147 received by that node. The manner in which applicable bundle 1148 representations are selected is beyond the scope of this 1149 document. If the agent finds that there are no applicable 1150 bundle representations for any of the nodes to which the bundle 1151 is to be sent, then forwarding is contraindicated. 1153 Step 3: If forwarding of the bundle is determined to be 1154 contraindicated for any of the reasons listed in Figure 12, then the 1155 Forwarding Contraindicated procedure defined in Section 5.4.1 MUST 1156 be followed; the remaining steps of Section 5 are skipped at this 1157 time. 1159 Step 4: If the bundle's custody transfer requested flag (in the 1160 bundle processing flags field) is set to 1, then the custody 1161 transfer procedure defined in Section 5.10.2 MUST be followed. 1163 Step 5: For each node selected for forwarding, the bundle protocol 1164 agent MUST encode the bundle in the selected applicable 1165 representation(s) and then invoke the services of the selected 1166 convergence layer adapter(s) in order to effect the sending of the 1167 bundle to that node. Determining the time at which the bundle 1168 protocol agent invokes convergence layer adapter services is a BPA 1169 implementation matter. Determining the time at which each 1171 Internet-Draft Proposed Revised Bundle Protocol January 20166 1173 convergence layer adapter subsequently responds to this service 1174 invocation by sending the bundle is a convergence-layer adapter 1175 implementation matter. Note that: 1177 . If the bundle contains a flow label extension block then that 1178 flow label value MAY identify procedures for determining the 1179 order in which convergence layer adapters must send bundles, 1180 e.g., considering bundle source when determining the order in 1181 which bundles are sent. The definition of such procedures is 1182 beyond the scope of this specification. 1183 . If the bundle has a bundle age block, then at the last possible 1184 moment before the CLA initiates conveyance of the bundle node 1185 via the CL protocol the bundle age value MUST be increased by 1186 the difference between the current time and the time at which 1187 the bundle was received (or, if the local node is the source of 1188 the bundle, created). 1190 Step 6: When all selected convergence layer adapters have informed 1191 the bundle protocol agent that they have concluded their data 1192 sending procedures with regard to this bundle: 1194 . If the "request reporting of bundle forwarding" flag in the 1195 bundle's status report request field is set to 1, then a bundle 1196 forwarding status report SHOULD be generated, destined for the 1197 bundle's report-to endpoint ID. If the bundle has the retention 1198 constraint "custody accepted" and all of the nodes to which the 1199 bundle was forwarded are known to be unable to send bundles 1200 back to this node, then the reason code on this bundle 1201 forwarding status report MUST be "forwarded over unidirectional 1202 link"; otherwise, the reason code MUST be "no additional 1203 information". 1204 . The bundle's "Forward pending" retention constraint MUST be 1205 removed. 1207 5.4.1. Forwarding Contraindicated 1209 The steps in responding to contraindication of forwarding are: 1211 Step 1: The bundle protocol agent MUST determine whether or not to 1212 declare failure in forwarding the bundle. Note: this decision is 1213 likely to be influenced by the reason for which forwarding is 1214 contraindicated. 1216 Step 2: If forwarding failure is declared, then the Forwarding 1217 Failed procedure defined in Section 5.4.2 MUST be followed. 1219 Internet-Draft Proposed Revised Bundle Protocol January 20166 1221 Otherwise, (a) if the bundle's custody transfer requested flag (in 1222 the bundle processing flags field) is set to 1, then the custody 1223 transfer procedure defined in Section 5.10 MUST be followed; (b) 1224 when -- at some future time - the forwarding of this bundle ceases 1225 to be contraindicated, processing proceeds from Step 5 of Section 1226 5.4. 1228 5.4.2. Forwarding Failed 1230 The steps in responding to a declaration of forwarding failure are: 1232 Step 1: If the bundle's custody transfer requested flag (in the 1233 bundle processing flags field) is set to 1, custody transfer failure 1234 must be handled. The bundle protocol agent MUST handle the custody 1235 transfer failure by generating a "Failed" custody signal for the 1236 bundle, destined for the bundle's current custodian(s); the custody 1237 signal MUST contain a reason code corresponding to the reason for 1238 which forwarding was determined to be contraindicated. (Note that 1239 discarding the bundle will not delete it from the network, since 1240 each current custodian still has a copy.) 1242 If the bundle's custody transfer requested flag (in the bundle 1243 processing flags field) is set to 0, then the bundle protocol agent 1244 MAY forward the bundle back to the node that sent it, as identified 1245 by the Previous Node ID block. 1247 Step 2: If the bundle's destination endpoint is an endpoint of which 1248 the node is a member, then the bundle's "Forward pending" retention 1249 constraint MUST be removed. Otherwise, the bundle MUST be deleted: 1250 the bundle deletion procedure defined in Section 5.13 MUST be 1251 followed, citing the reason for which forwarding was determined to 1252 be contraindicated. 1254 5.5. Bundle Expiration 1256 A bundle expires when the bundle's age exceeds its lifetime as 1257 specified in the primary bundle block. Bundle age MAY be determined 1258 by subtracting the bundle's creation timestamp time from the current 1259 time if (a) that timestamp time is not zero and (b) the local node's 1260 clock is known to be accurate (as discussed in section 4.5.1 above); 1261 otherwise bundle age MUST be obtained from the Bundle Age extension 1262 block. Bundle expiration MAY occur at any point in the processing 1263 of a bundle. When a bundle expires, the bundle protocol agent MUST 1264 delete the bundle for the reason "lifetime expired": the bundle 1265 deletion procedure defined in Section 5.13 MUST be followed. 1267 Internet-Draft Proposed Revised Bundle Protocol January 20166 1269 5.6. Bundle Reception 1271 The steps in processing a bundle that has been received from another 1272 node and decoded from its serialized representation are: 1274 Step 1: The retention constraint "Dispatch pending" MUST be added to 1275 the bundle. 1277 Step 2: If the "request reporting of bundle reception" flag in the 1278 bundle's status report request field is set to 1, then a bundle 1279 reception status report with reason code "No additional information" 1280 SHOULD be generated, destined for the bundle's report-to endpoint 1281 ID. 1283 Step 3: For each block in the bundle that is an extension block that 1284 the bundle protocol agent cannot process: 1286 . If the block processing flags in that block indicate that a 1287 status report is requested in this event, then a bundle 1288 reception status report with reason code "Block unintelligible" 1289 SHOULD be generated, destined for the bundle's report-to 1290 endpoint ID. 1291 . If the block processing flags in that block indicate that the 1292 bundle must be deleted in this event, then the bundle protocol 1293 agent MUST delete the bundle for the reason "Block 1294 unintelligible"; the bundle deletion procedure defined in 1295 Section 5.13 MUST be followed and all remaining steps of the 1296 bundle reception procedure MUST be skipped. 1297 . If the block processing flags in that block do NOT indicate 1298 that the bundle must be deleted in this event but do indicate 1299 that the block must be discarded, then the bundle protocol 1300 agent MUST remove this block from the bundle. 1302 Step 4: If the bundle's custody transfer requested flag (in the 1303 bundle processing flags field) is set to 1 and the bundle has the 1304 same source node ID, creation timestamp, and (if the bundle is a 1305 fragment) fragment offset and payload length as another bundle that 1306 (a) has not been discarded and (b) currently has the retention 1307 constraint "Custody accepted", custody transfer redundancy MUST be 1308 handled; otherwise, processing proceeds from Step 5. The bundle 1309 protocol agent MUST handle custody transfer redundancy by generating 1310 a "Failed" custody signal for this bundle with reason code 1311 "Redundant reception", destined for this bundle's current custodian, 1312 and removing this bundle's "Dispatch pending" retention constraint. 1314 Step 5: Processing proceeds from Step 1 of Section 5.3. 1316 Internet-Draft Proposed Revised Bundle Protocol January 20166 1318 5.7. Local Bundle Delivery 1320 The steps in processing a bundle that is destined for an endpoint of 1321 which this node is a member are: 1323 Step 1: If the received bundle is a fragment, the application data 1324 unit reassembly procedure described in Section 5.9 MUST be followed. 1325 If this procedure results in reassembly of the entire original 1326 application data unit, processing of this bundle (whose fragmentary 1327 payload has been replaced by the reassembled application data unit) 1328 proceeds from Step 2; otherwise, the retention constraint 1329 "Reassembly pending" MUST be added to the bundle and all remaining 1330 steps of this procedure MUST be skipped. 1332 Step 2: Delivery depends on the state of the registration whose 1333 endpoint ID matches that of the destination of the bundle: 1335 . If the registration is in the Active state, then the bundle 1336 MUST be delivered subject to this registration (see Section 3.1 1337 above) as soon as all previously received bundles that are 1338 deliverable subject to this registration have been delivered. 1339 . If the registration is in the Passive state, then the 1340 registration's delivery failure action MUST be taken (see 1341 Section 3.1 above). 1343 Step 3: As soon as the bundle has been delivered: 1345 . If the "request reporting of bundle delivery" flag in the 1346 bundle's status report request field is set to 1, then a bundle 1347 delivery status report SHOULD be generated, destined for the 1348 bundle's report-to endpoint ID. Note that this status report 1349 only states that the payload has been delivered to the 1350 application agent, not that the application agent has processed 1351 that payload. 1352 . If the bundle's custody transfer requested flag (in the bundle 1353 processing flags field) is set to 1, custodial delivery MUST be 1354 reported. The bundle protocol agent MUST report custodial 1355 delivery by generating a "Succeeded" custody signal for the 1356 bundle, destined for the bundle's current custodian(s). 1358 5.8. Bundle Fragmentation 1360 It may at times be advantageous for bundle protocol agents to reduce 1361 the sizes of bundles in order to forward them. This might be the 1362 case, for example, if a node to which a bundle is to be forwarded is 1363 accessible only via intermittent contacts and no upcoming contact is 1364 long enough to enable the forwarding of the entire bundle. 1366 Internet-Draft Proposed Revised Bundle Protocol January 20166 1368 The size of a bundle can be reduced by "fragmenting" the bundle. To 1369 fragment a bundle whose payload is of size M is to replace it with 1370 two "fragments" -- new bundles with the same source node ID and 1371 creation timestamp as the original bundle -- whose payloads are the 1372 first N and the last (M - N) bytes of the original bundle's payload, 1373 where 0 < N < M. Note that fragments may themselves be fragmented, 1374 so fragmentation may in effect replace the original bundle with more 1375 than two fragments. (However, there is only one 'level' of 1376 fragmentation, as in IP fragmentation.) 1378 Any bundle that has any Current Custodian extension block citing any 1379 node other than the local node MUST NOT be fragmented. This 1380 restriction aside, any bundle whose primary block's bundle 1381 processing flags do NOT indicate that it must not be fragmented MAY 1382 be fragmented at any time, for any purpose, at the discretion of the 1383 bundle protocol agent. 1385 Fragmentation SHALL be constrained as follows: 1387 . The concatenation of the payloads of all fragments produced by 1388 fragmentation MUST always be identical to the payload of the 1389 fragmented bundle (that is, the bundle that is being 1390 fragmented). Note that the payloads of fragments resulting from 1391 different fragmentation episodes, in different parts of the 1392 network, may be overlapping subsets of the fragmented bundle's 1393 payload. 1394 . The primary block of each fragment MUST differ from that of the 1395 fragmented bundle, in that the bundle processing flags of the 1396 fragment MUST indicate that the bundle is a fragment and both 1397 fragment offset and total application data unit length must be 1398 provided. Additionally, the CRC of the fragmented bundle, if 1399 any, MUST be replaced in each fragment by a new CRC computed 1400 for the primary block of that fragment. 1401 . The payload blocks of fragments will differ from that of the 1402 fragmented bundle as noted above. 1403 . If the fragmented bundle is not a fragment or is the fragment 1404 with offset zero, then all extension blocks of the fragmented 1405 bundle MUST be replicated in the fragment whose offset is zero. 1406 . Each of the fragmented bundle's extension blocks whose "Block 1407 must be replicated in every fragment" flag is set to 1 MUST be 1408 replicated in every fragment. 1409 . Beyond these rules, replication of extension blocks in the 1410 fragments is an implementation matter. 1411 . If the local node is a custodian of the fragmented bundle, then 1412 the BPA MUST release custody of the fragmented bundle before 1413 fragmentation occurs and MUST take custody of every fragment. 1415 Internet-Draft Proposed Revised Bundle Protocol January 20166 1417 5.9. Application Data Unit Reassembly 1419 If the concatenation -- as informed by fragment offsets and payload 1420 lengths -- of the payloads of all previously received fragments with 1421 the same source node ID and creation timestamp as this fragment, 1422 together with the payload of this fragment, forms a byte array whose 1423 length is equal to the total application data unit length in the 1424 fragment's primary block, then: 1426 . This byte array -- the reassembled application data unit -- 1427 MUST replace the payload of this fragment. 1428 . The BPA MUST take custody of each fragmentary bundle whose 1429 payload is a subset of the reassembled application data unit, 1430 for which custody transfer is requested but the BPA has not yet 1431 taken custody. 1432 . The BPA MUST then release custody of every fragment whose 1433 payload is a subset of the reassembled application data unit, 1434 for which it has taken custody. 1435 . The "Reassembly pending" retention constraint MUST be removed 1436 from every other fragment whose payload is a subset of the 1437 reassembled application data unit. 1439 Note: reassembly of application data units from fragments occurs at 1440 the nodes that are members of destination endpoints as necessary; an 1441 application data unit MAY also be reassembled at some other node on 1442 the path to the destination. 1444 5.10. Custody Transfer 1446 The decision as to whether or not to accept custody of a bundle is 1447 an implementation matter that may involve both resource and policy 1448 considerations. 1450 If the bundle protocol agent elects to accept custody of the bundle, 1451 then it must follow the custody acceptance procedure defined in 1452 Section 5.10.1. 1454 5.10.1. Custody Acceptance 1456 Procedures for acceptance of custody of a bundle are defined as 1457 follows. 1459 The retention constraint "Custody accepted" MUST be added to the 1460 bundle. 1462 If the "request reporting of custody acceptance" flag in the 1463 bundle's status report request field is set to 1, a custody 1465 Internet-Draft Proposed Revised Bundle Protocol January 20166 1467 acceptance status report SHOULD be generated, destined for the 1468 report-to endpoint ID of the bundle. However, if a bundle reception 1469 status report was generated for this bundle (Step 1 of Section 5.6) 1470 but has not yet been transmitted, then this report SHOULD be 1471 generated by simply turning on the "Reporting node accepted custody 1472 of bundle" flag in that earlier report. 1474 The bundle protocol agent MUST generate a "Succeeded" custody signal 1475 for the bundle, destined for the bundle's current custodian(s). 1477 The bundle protocol agent MUST assert the new current custodian for 1478 the bundle. It does so by inserting a new Current Custodian 1479 extension block whose value is the node ID of the local node or by 1480 changing the value of an existing Current Custodian extension block 1481 to the local node ID. 1483 The bundle protocol agent MAY set a custody transfer countdown timer 1484 for this bundle; upon expiration of this timer prior to expiration 1485 of the bundle itself and prior to custody transfer success for this 1486 bundle, the custody transfer failure procedure detailed in Section 1487 5.12 MAY be followed. The manner in which the countdown interval for 1488 such a timer is determined is an implementation matter. 1490 The bundle SHOULD be retained in persistent storage if possible. 1492 5.10.2. Custody Release 1494 When custody of a bundle is released, the "Custody accepted" 1495 retention constraint MUST be removed from the bundle and any custody 1496 transfer timer that has been established for this bundle SHOULD be 1497 destroyed. 1499 5.11. Custody Transfer Success 1501 Upon receipt of a "Succeeded" custody signal at a node that is a 1502 custodial node of the bundle identified in the custody signal, 1503 custody of the bundle MUST be released as described in Section 1504 5.10.2. 1506 5.12. Custody Transfer Failure 1508 Custody transfer is determined to have failed at a custodial node 1509 for that bundle when either (a) that node's custody transfer timer 1510 for that bundle (if any) expires or (b) a "Failed" custody signal 1511 for that bundle is received at that node. 1513 Internet-Draft Proposed Revised Bundle Protocol January 20166 1515 Upon determination of custody transfer failure, the action taken by 1516 the bundle protocol agent is implementation-specific and may depend 1517 on the nature of the failure. For example, if custody transfer 1518 failure was inferred from expiration of a custody transfer timer or 1519 was asserted by a "Failed" custody signal with the "Depleted 1520 storage" reason code, the bundle protocol agent might choose to re- 1521 forward the bundle, possibly on a different route (Section 5.4). 1522 Receipt of a "Failed" custody signal with the "Redundant reception" 1523 reason code, on the other hand, might cause the bundle protocol 1524 agent to release custody of the bundle and to revise its algorithm 1525 for computing countdown intervals for custody transfer timers. 1527 5.13. Bundle Deletion 1529 The steps in deleting a bundle are: 1531 Step 1: If the retention constraint "Custody accepted" currently 1532 prevents this bundle from being discarded, then: 1534 . Custody of the node is released as described in Section 5.10.2. 1535 . A bundle deletion status report citing the reason for deletion 1536 MUST be generated, destined for the bundle's report-to endpoint 1537 ID. 1539 Otherwise, if the "request reporting of bundle deletion" flag in the 1540 bundle's status report request field is set to 1, then a bundle 1541 deletion status report citing the reason for deletion SHOULD be 1542 generated, destined for the bundle's report-to endpoint ID. 1544 Step 2: All of the bundle's retention constraints MUST be removed. 1546 5.14. Discarding a Bundle 1548 As soon as a bundle has no remaining retention constraints it MAY be 1549 discarded. 1551 5.15. Canceling a Transmission 1553 When requested to cancel a specified transmission, where the bundle 1554 created upon initiation of the indicated transmission has not yet 1555 been discarded, the bundle protocol agent MUST delete that bundle 1556 for the reason "transmission cancelled". For this purpose, the 1557 procedure defined in Section 5.13 MUST be followed. 1559 Internet-Draft Proposed Revised Bundle Protocol January 20166 1561 6. Administrative Record Processing 1563 6.1. Administrative Records 1565 Administrative records are standard application data units that are 1566 used in providing some of the features of the Bundle Protocol. Two 1567 types of administrative records have been defined to date: bundle 1568 status reports and custody signals. Note that additional types of 1569 administrative records may be defined by supplementary DTN protocol 1570 specification documents. 1572 Every administrative record consists of: 1574 . Record type code (an unsigned integer for which valid values 1575 are as defined below). 1576 . Record content in type-specific format. 1578 Valid administrative record type codes are defined as follows: 1580 +---------+--------------------------------------------+ 1582 | Value | Meaning | 1584 +=========+============================================+ 1586 | 1 | Bundle status report. | 1588 +---------+--------------------------------------------+ 1590 | 2 | Custody signal. | 1592 +---------+--------------------------------------------+ 1594 | (other) | Reserved for future use. | 1596 +---------+--------------------------------------------+ 1598 Figure 2: Administrative Record Type Codes 1600 The contents of the two types of administrative records defined in 1601 the present document are described below. 1603 6.1.1. Bundle Status Reports 1605 The transmission of 'bundle status reports' under specified 1606 conditions is an option that can be invoked when transmission of a 1607 bundle is requested. These reports are intended to provide 1609 Internet-Draft Proposed Revised Bundle Protocol January 20166 1611 information about how bundles are progressing through the system, 1612 including notices of receipt, custody transfer, forwarding, final 1613 delivery, and deletion. They are transmitted to the Report-to 1614 endpoints of bundles. 1616 Every bundle status report comprises the following fields, in this 1617 order: 1619 . Status flags. The following conditions are asserted by the 1620 bundle status report status flags (all Boolean): 1621 o Reporting node received bundle. 1622 o Reporting node accepted custody of bundle. 1623 o Reporting node forwarded the bundle. 1624 o Reporting node delivered the bundle. 1625 o Reporting node deleted the bundle. 1626 . Reason code, an unsigned integer explaining the values of the 1627 status flags. Status report reason codes are as defined below, 1628 but the list of status report reason codes provided here is 1629 neither exhaustive nor exclusive; supplementary DTN protocol 1630 specifications (including, but not restricted to, the Bundle 1631 Security Protocol [BPSEC]) may define additional reason codes. 1632 . Status times, one unsigned integer for each condition asserted 1633 by any status flag, indicating the time (as reported by the 1634 local system clock, an implementation matter) at which the 1635 indicated condition became true for this bundle. These fields 1636 are included in the status report if and only if the "Report 1637 status time" flag was set to 1 in the subject bundle's bundle 1638 processing flags. Status time is expressed in seconds since 1639 the start of the year 2000, on the Coordinated Universal Time 1640 (UTC) scale [UTC]. 1641 . Source node, the node ID of the source of the bundle whose 1642 status is being reported. 1643 . Creation timestamp, the creation timestamp of the bundle whose 1644 status is being reported. 1645 . Fragment offset, the fragment offset of the bundle whose status 1646 is being reported (omitted if omitted from the subject bundle's 1647 primary block). 1648 . Fragment length, the length of the payload of the bundle whose 1649 status is being reported (omitted if fragment offset is omitted 1650 from the subject bundle's primary block). 1652 Valid status report reason codes are defined as follows: 1654 +---------+--------------------------------------------+ 1656 | Value | Meaning | 1658 Internet-Draft Proposed Revised Bundle Protocol January 20166 1660 +=========+============================================+ 1662 | 0 | No additional information. | 1664 +---------+--------------------------------------------+ 1666 | 1 | Lifetime expired. | 1668 +---------+--------------------------------------------+ 1670 | 2 | Forwarded over unidirectional link. | 1672 +---------+--------------------------------------------+ 1674 | 3 | Transmission canceled. | 1676 +---------+--------------------------------------------+ 1678 | 4 | Depleted storage. | 1680 +---------+--------------------------------------------+ 1682 | 5 | Destination endpoint ID unintelligible. | 1684 +---------+--------------------------------------------+ 1686 | 6 | No known route to destination from here. | 1688 +---------+--------------------------------------------+ 1690 | 7 | No timely contact with next node on route. | 1692 +---------+--------------------------------------------+ 1694 | 8 | Block unintelligible. | 1696 +---------+--------------------------------------------+ 1698 | (other) | Reserved for future use. | 1700 +---------+--------------------------------------------+ 1702 Figure 3: Status Report Reason Codes 1704 Internet-Draft Proposed Revised Bundle Protocol January 20166 1706 6.1.2. Custody Signals 1708 Custody signals are administrative records that effect custody 1709 transfer operations. They are transmitted to the nodes that are the 1710 current custodians of bundles. 1712 Every custody signal comprises the following fields, in this order: 1714 . "Custody transfer succeeded" flag (Boolean). 1715 . Reason code, an unsigned integer explaining the value of the 1716 "Custody transfer succeeded" flag. Custody signal reason codes 1717 are as defined below. 1718 . Source node, the node ID of the source of the bundle for which 1719 custodial activity is being reported. 1720 . Creation timestamp, the creation timestamp of the bundle for 1721 which custodial activity is being reported. 1722 . Fragment offset, the fragment offset of the bundle for which 1723 custodial activity is being reported (omitted if omitted from 1724 the subject bundle's primary block). 1725 . Fragment length, the length of the payload of the bundle for 1726 which custodial activity is being reported (omitted if fragment 1727 offset is omitted from the subject bundle's primary block). 1729 Valid custody signal reason codes are defined as follows: 1731 +---------+--------------------------------------------+ 1733 | Value | Meaning | 1735 +=========+============================================+ 1737 | 0 | No additional information. | 1739 +---------+--------------------------------------------+ 1741 | 1 | Reserved for future use. | 1743 +---------+--------------------------------------------+ 1745 | 2 | Reserved for future use. | 1747 +---------+--------------------------------------------+ 1749 | 3 | Redundant (reception by a node that is a | 1751 | | custodial node for this bundle). | 1753 Internet-Draft Proposed Revised Bundle Protocol January 20166 1755 +---------+--------------------------------------------+ 1757 | 4 | Depleted storage. | 1759 +---------+--------------------------------------------+ 1761 | 5 | Destination endpoint ID unintelligible. | 1763 +---------+--------------------------------------------+ 1765 | 6 | No known route destination from here. | 1767 +---------+--------------------------------------------+ 1769 | 7 | No timely contact with next node on route. | 1771 +---------+--------------------------------------------+ 1773 | 8 | Block unintelligible. | 1775 +---------+--------------------------------------------+ 1777 | (other) | Reserved for future use. | 1779 +---------+--------------------------------------------+ 1781 Figure 4: Custody Signal Reason Codes 1783 6.2. Generation of Administrative Records 1785 Whenever the application agent's administrative element is directed 1786 by the bundle protocol agent to generate an administrative record 1787 with reference to some bundle, the following procedure must be 1788 followed: 1790 Step 1: The administrative record must be constructed. If the 1791 referenced bundle is a fragment, the administrative record MUST 1792 contain the fragment offset and fragment length. 1794 Step 2: A request for transmission of a bundle whose payload is this 1795 administrative record MUST be presented to the bundle protocol 1796 agent. 1798 6.3. Reception of Custody Signals 1800 For each received custody signal that has the "custody transfer 1801 succeeded" flag set to 1, the administrative element of the 1803 Internet-Draft Proposed Revised Bundle Protocol January 20166 1805 application agent MUST direct the bundle protocol agent to follow 1806 the custody transfer success procedure in Section 5.11. 1808 For each received custody signal that has the "custody transfer 1809 succeeded" flag set to 0, the administrative element of the 1810 application agent MUST direct the bundle protocol agent to follow 1811 the custody transfer failure procedure in Section 5.12. 1813 7. Services Required of the Convergence Layer 1815 7.1. The Convergence Layer 1817 The successful operation of the end-to-end bundle protocol depends 1818 on the operation of underlying protocols at what is termed the 1819 "convergence layer"; these protocols accomplish communication 1820 between nodes. A wide variety of protocols may serve this purpose, 1821 so long as each convergence layer protocol adapter provides a 1822 defined minimal set of services to the bundle protocol agent. This 1823 convergence layer service specification enumerates those services. 1825 7.2. Summary of Convergence Layer Services 1827 Each convergence layer protocol adapter is expected to provide the 1828 following services to the bundle protocol agent: 1830 . sending a bundle to a bundle node that is reachable via the 1831 convergence layer protocol; 1832 . delivering to the bundle protocol agent a bundle that was sent 1833 by a bundle node via the convergence layer protocol. 1835 The convergence layer service interface specified here is neither 1836 exhaustive nor exclusive. That is, supplementary DTN protocol 1837 specifications (including, but not restricted to, the Bundle 1838 Security Protocol [BPSEC]) may expect convergence layer adapters 1839 that serve BP implementations conforming to those protocols to 1840 provide additional services such as retransmitting data that were 1841 lost in transit, discarding bundle-conveying data units that the 1842 convergence layer protocol determines are corrupt or inauthentic, or 1843 reporting on the integrity and/or authenticity of delivered bundles. 1845 8. Security Considerations 1847 The bundle protocol has taken security into concern from the outset 1848 of its design. It was always assumed that security services would be 1849 needed in the use of the bundle protocol. As a result, the bundle 1850 protocol security architecture and the available security services 1851 are specified in an accompanying document, the Bundle Security 1853 Internet-Draft Proposed Revised Bundle Protocol January 20166 1855 Protocol specification [BPSEC]; an informative overview of this 1856 architecture is provided in [SECO]. 1858 The bundle protocol has been designed with the notion that it may be 1859 run over networks with scarce resources. For example, the networks 1860 might have limited bandwidth, limited connectivity, constrained 1861 storage in relay nodes, etc. Therefore, the bundle protocol must 1862 ensure that only those entities authorized to send bundles over such 1863 constrained environments are actually allowed to do so. All 1864 unauthorized entities should be prevented from consuming valuable 1865 resources as soon as practicable. 1867 Likewise, because of the potentially high latencies and delays 1868 involved in the networks that make use of the bundle protocol, data 1869 sources should be concerned with the integrity of the data received 1870 at the intended destination(s) and may also be concerned with 1871 ensuring confidentiality of the data as it traverses the network. 1872 Without integrity, the bundle payload data might be corrupted while 1873 in transit without the destination able to detect it. Similarly, the 1874 data source can be concerned with ensuring that the data can only be 1875 used by those authorized, hence the need for confidentiality. 1877 Internal to the bundle-aware overlay network, the bundle nodes 1878 should be concerned with the authenticity of other bundle nodes as 1879 well as the preservation of bundle payload data integrity as it is 1880 forwarded between bundle nodes. 1882 As a result, bundle security is concerned with the authenticity, 1883 integrity, and confidentiality of bundles conveyed among bundle 1884 nodes. This is accomplished via the use of two independent security- 1885 specific bundle blocks, which may be used together to provide 1886 multiple bundle security services or independently of one another, 1887 depending on perceived security threats, mandated security 1888 requirements, and security policies that must be enforced. 1890 To provide end-to-end bundle authenticity and integrity, the Block 1891 Integrity Block (BIB) is used. The BIB allows any security-enabled 1892 entity along the delivery path to ensure the integrity of the 1893 bundle's payload or any other block other than a Block 1894 Confidentiality Block. 1896 To provide payload confidentiality, the use of the Block 1897 Confidentiality Block (BCB) is available. The bundle payload, or any 1898 other block aside from the primary block and the Bundle Security 1899 Protocol blocks, may be encrypted to provide end-to-end payload 1900 confidentiality/privacy. 1902 Internet-Draft Proposed Revised Bundle Protocol January 20166 1904 Additionally, convergence-layer protocols that ensure authenticity 1905 of communication between adjacent nodes in BP network topology 1906 SHOULD be used where available, to minimize the ability of 1907 unauthenticated nodes to introduce inauthentic traffic into the 1908 network. 1910 Bundle security MUST NOT be invalidated by forwarding nodes even 1911 though they themselves might not use the Bundle Security Protocol. 1913 In particular, while blocks MAY be added to bundles transiting 1914 intermediate nodes, removal of blocks with the 'Discard block if it 1915 can't be processed' flag unset in the block processing control flags 1916 may cause security to fail. 1918 Inclusion of the Bundle Security Protocol in any Bundle Protocol 1919 implementation is RECOMMENDED. Use of the Bundle Security Protocol 1920 in Bundle Protocol operations is OPTIONAL. 1922 9. IANA Considerations 1924 The "dtn" and "ipn" URI schemes have been provisionally registered 1925 by IANA. See http://www.iana.org/assignments/uri-schemes.html for 1926 the latest details. 1928 Registries of scheme type numbers, extension block type numbers, and 1929 administrative record type numbers will be required. 1931 10. References 1933 10.1. Normative References 1935 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1936 Requirement Levels", BCP 14, RFC 2119, March 1997. 1938 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1939 Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, 1940 January 2005. 1942 [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 1943 Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 1944 2015. 1946 10.2. Informative References 1948 [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 1949 4838, April 2007. 1951 Internet-Draft Proposed Revised Bundle Protocol January 20166 1953 [ASN1] "Abstract Syntax Notation One (ASN.1), "ASN.1 Encoding Rules: 1954 Specification of Basic Encoding Rules (BER), Canonical Encoding 1955 Rules (CER) and Distinguished Encoding Rules (DER)," ITU-T Rec. 1956 X.690 (2002) | ISO/IEC 8825- 1:2002", 2003. 1958 [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work 1959 In Progress, October 2015. 1961 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1962 Identifiers (IRIs)", RFC 3987, January 2005. 1964 [RFC5050] Scott, M. and S. Burleigh, "Bundle Protocol 1965 Specification", RFC 5050, November 2007. 1967 [SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay- 1968 Tolerant Networking Security Overview", Work Progress, July 2007. 1970 [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for 1971 Challenged Internets", SIGCOMM 2003. 1973 [TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A Tutorial", 1974 . 1976 [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: 1977 historical background and perspectives" in "Journees systemes de 1978 reference spatio-temporels", 2004. 1980 11. Acknowledgments 1982 This work is freely adapted from [RFC5050], which was an effort of 1983 the Delay Tolerant Networking Research Group. The following DTNRG 1984 participants contributed significant technical material and/or 1985 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 1986 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 1987 Michael Demmer of the University of California at Berkeley, Robert 1988 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 1989 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 1990 College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of 1991 Ohio University, and Howard Weiss of SPARTA, Inc. 1993 This document was prepared using 2-Word-v2.0.template.dot. 1995 12. Significant Changes from RFC 5050 1997 Points on which this draft significantly differs from RFC 5050 1998 include the following: 2000 Internet-Draft Proposed Revised Bundle Protocol January 20166 2002 . Clarify the difference between transmission and forwarding. 2003 . Amplify discussion of custody transfer. Move current custodian 2004 to an extension block, of which there can be multiple 2005 occurrences (possible support for the MITRE idea of multiple 2006 concurrent custodians, from several years ago); define that 2007 block in this specification. 2008 . Introduce the concept of "node ID" as functionally distinct 2009 from endpoint ID, while having the same syntax. 2010 . Restructure primary block, making it immutable. Add optional 2011 CRC. 2012 . Add optional CRCs to non-primary blocks. 2013 . Add block ID number to canonical block format (to support 2014 streamlined BSP). 2015 . Add bundle age extension block, defined in this specification. 2016 . Add previous node ID extension block, defined in this 2017 specification. 2018 . Add flow label block, *not* defined in this specification. 2019 . Add hop count extension block, defined in this specification. 2020 . Clean up a conflict between fragmentation and custody transfer 2021 that Ed Birrane pointed out. 2022 . Remove representation specifications from the document, making 2023 the protocol specification representation-neutral. 2025 13. Open Issues 2027 13.1. Application Agent 2029 Need to add a diagram explaining how the various components of the 2030 BPA interact. 2032 13.2. Primary block CRC type 2034 What are the best CRC options to support here? CRC-16-ARINC, CRC- 2035 16-CCITT, CRC-16-CDMA2000, CRC-16-DECT, etc.? 2037 Internet-Draft Proposed Revised Bundle Protocol January 20166 2039 Appendix A. For More Information 2041 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 2042 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 2044 Copyright (c) 2016 IETF Trust and the persons identified as authors 2045 of the code. All rights reserved. 2047 Redistribution and use in source and binary forms, with or without 2048 modification, is permitted pursuant to, and subject to the license 2049 terms contained in, the Simplified BSD License set forth in Section 2050 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 2051 (http://trustee.ietf.org/license-info). 2053 Authors' Addresses 2055 Scott Burleigh 2056 Jet Propulsion Laboratory, California Institute of Technology 2057 4800 Oak Grove Dr. 2058 Pasadena, CA 91109-8099 2059 US 2060 Phone: +1 818 393 3353 2061 Email: Scott.Burleigh@jpl.nasa.gov 2063 Kevin Fall 2064 Carnegie Mellon University / Software Engineering Institute 2065 4500 Fifth Avenue 2066 Pittsburgh, PA 15213 2067 US 2068 Phone: +1 412 268 3304 2069 Email: kfall@cmu.edu 2071 Edward J. Birrane 2072 Johns Hopkins University Applied Physics Laboratory 2073 11100 Johns Hopkins Rd 2074 Laurel, MD 20723 2075 US 2076 Phone: +1 443 778 7423 2077 Email: Edward.Birrane@jhuapl.edu