idnits 2.17.1 draft-irtf-dtnrg-arch-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1523. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 678 has weird spacing: '...network is...' == Line 1340 has weird spacing: '...rotocol for ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4088' is mentioned on line 369, but not defined == Missing Reference: 'RFC792' is mentioned on line 579, but not defined == Missing Reference: 'JPF04' is mentioned on line 702, but not defined == Unused Reference: 'RFC3978' is defined on line 1312, but no explicit reference was found in the text == Unused Reference: 'RFC3979' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: 'DTNSOV' is defined on line 1390, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-spec-04 == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-00 == Outdated reference: A later version (-06) exists of draft-irtf-dtnrg-sec-overview-00 Summary: 5 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DTN Research Group V. Cerf 2 INTERNET-DRAFT Google/Jet Propulsion Laboratory 3 S. Burleigh 4 December 2005 A. Hooke 5 Expires June 2006 L. Torgerson 6 NASA/Jet Propulsion Laboratory 7 R. Durst 8 K. Scott 9 The MITRE Corporation 10 K. Fall 11 Intel Corporation 12 H. Weiss 13 SPARTA, Inc. 14 Delay-Tolerant Network Architecture 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This document was produced by members of the IRTF's Delay Tolerant 40 Networking Research Group (DTNRG). Please see http://www.dtnrg.org. 42 Abstract 44 This document describes an architecture for delay-tolerant and 45 disruption-tolerant networks, and is an evolution of the architecture 46 originally designed for the Interplanetary Internet, a communication 47 system envisioned to provide Internet-like services across 48 interplanetary distances in support of deep space exploration. This 49 document describes an architecture that addresses a variety of 50 problems with internetworks having operational and performance 51 characteristics that make conventional (Internet-like) networking 52 approaches either unworkable or impractical. We define a message- 53 oriented overlay that exists above the transport (or other) layers of 54 the networks it interconnects. The document presents a motivation 55 for the architecture, an architectural overview, review of state 56 management required for its operation, and a discussion of 57 application design issues. 59 Table of Contents 60 Status of this Memo................................................1 61 Abstract...........................................................1 62 Table of Contents..................................................2 63 1 Introduction.................................................4 64 2 Why an Architecture for Delay-Tolerant Networking?...........5 65 3 DTN Architectural Description................................6 66 3.1 Virtual Message Switching using Store-and-Forward 67 Operation...............................................6 68 3.2 Nodes...................................................7 69 3.3 Endpoint Identifiers (EIDs) and Registrations...........7 70 3.4 Naming of Groups........................................9 71 3.5 Priority Classes.......................................10 72 3.6 Postal-Style Delivery Options and Administrative Records11 73 3.7 Primary Bundle Fields..................................13 74 3.8 Routing and Forwarding.................................14 75 3.9 Fragmentation and Reassembly...........................16 76 3.10 Reliability and Custody Transfer.......................17 77 3.11 DTN Support for Proxies and Application Layer Gateways.18 78 3.12 Time Stamps and Time Synchronization...................19 79 3.13 Congestion and Flow Control at the Bundle Layer........19 80 3.14 Security...............................................20 81 4 State Management Considerations.............................22 82 4.1 Application Registration State.........................22 83 4.2 Custody Transfer State.................................22 84 4.3 Bundle Routing and Forwarding State....................23 85 4.4 Security-Related State.................................23 86 4.5 Policy and Configuration State.........................24 87 5 Application Structuring Issues..............................24 88 6 Convergence Layer Considerations for Use of Underlying 89 Protocols...................................................25 90 7 Summary.....................................................26 91 8 Security Considerations.....................................26 92 9 IANA Considerations.........................................26 93 10 Normative References........................................26 94 11 Informative References......................................26 96 Acknowledgments 98 John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe 99 Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen 100 Farrell, Melissa Ho, Ting Liu, Mike Demmer, Jakob Ericsson, Susan 101 Symington and Craig Partridge all contributed useful thoughts and 102 criticisms to previous versions of this document. We are grateful 103 for their time and participation. 105 This work was performed in part under DOD Contract DAA-B07-00-CC201, 106 DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA 107 Contract NAS7-1407. 109 Release Notes 111 draft-irtf-dtnrg-arch-00.txt, March 2003: 113 -Revised model for delay tolerant network infrastructure security. 114 -Introduced fragmentation and reassembly to the architecture. 115 -Removed significant amounts of rationale and redundant text. Moved 116 bundle transfer example(s) to separate draft(s). 118 draft-irtf-dtnrg-arch-02.txt, July 2004: 119 -Revised assumptions about reachability within DTN regions. 120 -Added management endpoint identifiers for nodes. 121 -Moved list of bundle header information to protocol spec document. 123 draft-irtf-dtnrg-arch-03.txt, July 2005: 124 -Revised regions to become URI schemes 125 -Added discussion of multicast and anycast 126 -Revised motivation/introduction section (2) and 127 -Much of the security discussion has moved to the security draft 128 -Updated terminology to match current bundle protocol specification 130 draft-irtf-dtnrg-arch-04.txt, November 2005: 131 -Further terminology updates and minor editing 133 1 Introduction 135 This document describes an architecture for delay and disruption- 136 tolerant interoperable networking (DTN). The architecture embraces 137 the concepts of occasionally-connected networks that may suffer from 138 frequent partitions and that may be comprised of more than one 139 divergent set of protocols or protocol families. The basis for this 140 architecture lies with that of the Interplanetary Internet, which 141 focused primarily on the issue of deep space communication in high- 142 delay environments. We expect the DTN architecture described here to 143 be utilized in various operational environments, including those 144 subject to disruption and disconnection and those with high-delay; 145 the case of deep space is one specialized example of these, and is 146 being pursued as a specialization of this architecture (See 147 http://www.ipnsig.org and [SB03] for more details). 149 Other networks to which we believe this architecture applies include 150 sensor-based networks using scheduled intermittent connectivity, 151 terrestrial wireless networks that cannot ordinarily maintain end-to- 152 end connectivity, satellite networks with moderate delays and 153 periodic connectivity, and underwater acoustic networks with moderate 154 delays and frequent interruptions due to environmental factors. A 155 DTN tutorial [FW03], aimed at introducing DTN and the types of 156 networks for which it is designed, is available to introduce new 157 readers to the fundamental concepts and motivation. More technical 158 descriptions may be found in [KF03], [JFP04], [JDPF05] and [WJMF05]. 160 We define an end-to-end message-oriented overlay called the "bundle 161 layer" that exists at a layer above the transport (or other) layers 162 of the networks on which it is hosted and below applications. Devices 163 implementing the bundle layer are called DTN nodes. The bundle layer 164 forms an overlay that employs persistent storage to help combat 165 network interruption. It includes a hop-by-hop transfer of reliable 166 delivery responsibility and optional end-to-end acknowledgement. It 167 also includes a number of diagnostic and management features. For 168 interoperability, it uses a flexible naming scheme (based on Uniform 169 Resource Identifiers [RFC3986]) capable of encapsulating different 170 naming and addressing schemes in the same overall naming syntax. It 171 also has a basic security model, optionally enabled, aimed at 172 protecting infrastructure from unauthorized use. 174 The bundle layer provides functionality similar to the internet layer 175 of gateways described in the original ARPANET/Internet designs 176 [CK74]. It differs from ARPANET gateways, however, because it is 177 layer-agnostic and is focused on virtual message forwarding rather 178 than packet switching. However, both generally provide 179 interoperability between underlying protocols specific to one 180 environment and those protocols specific to another, and both provide 181 a store-and-forward forwarding service (with the bundle layer 182 employing persistent storage for its store and forward function). 184 In a sense, the DTN architecture provides a common method for 185 interconnecting heterogeneous gateways or proxies that employ store- 186 and-forward message routing to overcome communication disruptions. 187 It provides services similar to electronic mail, but with enhanced 188 naming, routing, and security capabilities. Nodes unable to support 189 the full capabilities required by this architecture may be supported 190 by application layer proxies acting as DTN applications. 192 2 Why an Architecture for Delay-Tolerant Networking? 194 Our motivations for pursuing an architecture for delay tolerant 195 networking stems from several factors. These factors are summarized 196 below; much more detail on their rationale can be explored in [SB03], 197 [KF03], and [DFS02]. 199 The existing Internet protocols do not work well for some 200 environments, due to some fundamental assumptions built into the 201 Internet architecture: 203 - that an end-to-end path between source and destination exists for 204 the duration of a communication session 205 - (for reliable communication) that retransmissions based on timely 206 and stable feedback from data receivers is an effective means for 207 repairing errors 208 - that end-to-end loss is relatively small 209 - that all routers and end stations support the TCP/IP protocols 210 - that applications need not worry about communication performance 211 - that endpoint-based security mechanisms are sufficient for meeting 212 most security concerns 213 - that packet switching is the most appropriate abstraction for 214 interoperability and performance 215 - that selecting a single route between sender and receiver is 216 sufficient for achieving acceptable communication performance 218 The DTN architecture is conceived to relax most of these assumptions, 219 based on a number of design principles that are summarized here (and 220 further discussed in [KF03]): 222 - use variable-length (possibly long) messages (not streams or 223 limited-sized packets) as the communication abstraction to help 224 enhance the ability of the network to make good scheduling/path 225 selection decisions when possible 226 - use a naming syntax that supports a wide range of naming and 227 addressing conventions to enhance interoperability 228 - use storage within the network to support store-and-forward 229 operation over multiple paths, and over potentially long 230 timescales (i.e. to support operation in environments where many 231 and/or no end-to-end paths may ever exist); do not require end-to- 232 end reliability 233 - provide security mechanisms that protect the infrastructure from 234 unauthorized use by discarding traffic as quickly as possible 235 - provide coarse-grained classes of service, delivery options, time 236 stamps and an expression of the useful life for data to further 237 allow the network to better serve the needs of applications 239 In addition to the principles guiding the design of the bundle layer 240 itself, its use is also guided by a few application design 241 principles: 243 - applications should minimize the number of round-trip exchanges 244 - applications should cope with restarts after failure while network 245 transactions remain pending 247 These issues are discussed in further detail in Section 5. 249 3 DTN Architectural Description 251 The previous section summarized the design principles that guide the 252 definition of the DTN architecture. This section presents a 253 description of the major features of the architecture resulting from 254 design decisions guided by the aforementioned design principles. 256 3.1 Virtual Message Switching using Store-and-Forward Operation 258 A DTN-enabled application sends messages, also called Application 259 Data Units or ADUs [CT90] of arbitrary length, subject to any 260 implementation limitations. The relative order of messages might not 261 be preserved. Messages are transformed into protocol data units 262 called "bundles" that contain ADUs and other information used to 263 deliver bundles to their destination(s). Messages are typically sent 264 by and delivered to applications in complete units; bundles may be 265 split up ("fragmented") into multiple constituent bundles (also 266 called "fragments" or "bundle fragments") during transmission. 268 Bundle sources and destinations are identified by (variable-length) 269 Endpoint Identifiers (EIDs, described below), which identify the 270 original sender and final destination(s) of bundles, respectively. 271 Bundles also contain a "report-to" EID used when special operations 272 are requested to direct diagnostic output to an arbitrary entity 273 (e.g., other than the source). 275 While IP networks are based on "store-and-forward" operation, there 276 is an assumption that the "storing" will not persist for more than a 277 modest amount of time, on the order of the queuing and transmission 278 delay. In contrast, the DTN architecture does not expect that 279 network links are always available or reliable, and instead expects 280 that nodes may choose to store messages for some time. We anticipate 281 that most DTN nodes will use some form of persistent storage for this 282 -- disk, flash memory, etc., and that stored messages will survive 283 system restarts. 285 A message-oriented abstraction provides bundle layer routing with a- 286 priori knowledge of the size and performance requirements of 287 requested data transfers. When there is a significant amount of 288 queuing that can occur in the network (as is the case in the DTN 289 version of store-and-forward), the advantage provided by knowing this 290 information may be significant for making scheduling and path 291 selection decisions [JFP04]. An alternative abstraction (i.e. of 292 stream-based delivery) would make such scheduling much more 293 difficult. Although packets provide some of the same benefits as 294 messages, larger aggregates provide a way for the network to apply 295 scheduling and buffer management to entire units of data that are 296 useful to applications. 298 An essential element of the message-based style of operation for 299 networking is that messages have a place to wait in a queue until a 300 communication opportunity ("contact") is available. This highlights 301 the following assumptions: 303 1. that storage is available and well-distributed throughout the 304 network 305 2. that storage is sufficiently persistent and robust to store 306 messages until forwarding can occur, and 307 3. (implicitly) that this 'store-and-forward' model is a better 308 choice than attempting to effect continuous connectivity or other 309 alternatives 311 For a network to effectively support the DTN architecture, these 312 assumptions must be considered and must be found to hold. 314 3.2 Nodes 316 A DTN node (or simply "node" in this document) is an engine for 317 sending and receiving bundles-- an implementation of the bundle 318 layer. Applications utilize DTN nodes to send or receive messages 319 carried in bundles (or act as report-to destinations for diagnostic 320 information carried in bundles). Nodes are identified by one or more 321 Endpoint Identifiers (EIDs). 323 3.3 Endpoint Identifiers (EIDs) and Registrations 325 An Endpoint Identifier (EID) is a name, using the general syntax of 326 URIs (see below), that refers to a set of DTN nodes. Such a set is 327 called a "DTN endpoint." A node is able to determine from an EID the 328 corresponding endpoint's "minimum reception group" (MRG). The MRG of 329 an endpoint is the set of nodes "in" the endpoint to which a bundle 330 must be delivered in order to complete a data transfer. In 331 particular, the MRG of an endpoint may refer to one node (unicast), 332 one of a group of nodes (anycast), or all of a group of nodes 333 (multicast and broadcast). A single node may be in the MRG of 334 multiple endpoints and an endpoint may have an MRG with cardinality 335 greater than one (e.g., for anycast and multicast delivery, see 336 below). Each node is also required to have at least one EID that 337 uniquely identifies it. 339 Applications send messages destined for an EID, and they may arrange 340 for bundles sent to a particular EID to be delivered to them. 341 Depending on the construction of the EID being used (see below), 342 there may be a provision for wildcarding some portion of an EID, 343 which is often useful for diagnostic and routing purposes. 345 An application's desire to receive traffic destined for a particular 346 EID is called a "registration," and in general is maintained 347 persistently by a DTN node. This allows application registration 348 information to survive application and operating system restarts. 350 An application's attempt to establish a registration is not 351 guaranteed to succeed. For example, an application could request to 352 register itself as a member of an endpoint by specifying an Endpoint 353 ID that is uninterpretable or unavailable to the DTN node servicing 354 the request. Such requests are likely to fail. 356 3.3.1 URI Schemes 358 Each Endpoint ID is expressed syntactically as a Uniform Resource 359 Identifier (URI) [RFC3986]. The URI syntax has been designed as a 360 way to express names or addresses for a wide range of purposes, and 361 is therefore useful for constructing DTN names. 363 In URI terminology, each URI begins with a scheme name. The scheme 364 name is an element of the set of globally-managed scheme names 365 maintained by IANA [ISCHEMES]. Lexically following the scheme name 366 in a URI is a series of characters constrained by the syntax defined 367 by the scheme. This portion of the URI is called the scheme-specific 368 part (SSP), and can be quite general. (See, as one example, the URI 369 scheme for SNMP [RFC4088]). Note that scheme-specific syntactical 370 and semantic restrictions may be more constraining than the basic 371 rules of RFC 3986. Section 3.1 of RFC 3986 provides guidance on the 372 syntax of scheme names. 374 URI schemes are a key concept in the DTN architecture, and evolved 375 from an earlier concept called regions, which were tied more closely 376 to assumptions of the network topology. Using URIs, significant 377 flexibility is attained in the structuring of EIDs. They might, for 378 example, be constructed based on DNS names, or might look like 379 "expressions of interest" or forms of database-like queries as in a 380 directed diffusion-routed network [IGE00] or in intentional naming 381 [WSBL99]. As names, EIDs are not required to be related to routing 382 or topological organization. Such a relationship is not prohibited, 383 however, and in some environments using EIDs this way may be 384 advantageous. 386 A single EID may refer to more than one DTN node, as suggested above. 387 It is the responsibility of a scheme designer to define how to 388 interpret the SSP of an EID so as to determine whether it refers to a 389 unicast, multicast or anycast set of nodes. See Section 3.4 for more 390 details. 392 URIs are constructed based on rules specified in RFC 3986, using the 393 US-ASCII character set. However, note this excerpt from RFC 3986, 394 section 1.2.1, on dealing with characters that cannot be represented 395 by US-ASCII: "Percent-encoded octets (Section 2.1) may be used 396 within a URI to represent characters outside the range of the US- 397 ASCII coded character set if this representation is allowed by the 398 scheme or by the protocol element in which the URI is referenced. 399 Such a definition should specify the character encoding used to map 400 those characters to octets prior to being percent-encoded for the 401 URI." 403 3.3.2 Late Binding 405 Binding means interpreting the SSP of an EID for the purpose of 406 carrying an associated message to a recipient over some underlying 407 protocol. For example, binding might require mapping an EID to a 408 lower-layer address or an alternate EID in a fashion similar to DNS 409 name-to-address mappings in the Internet. "Late binding" means that 410 this interpretation may take place relatively late in the delivery 411 process of a message. Late binding is in contrast with typical 412 Internet communication sessions in which a DNS resolution takes place 413 prior to data exchange at the IP layer. Such a circumstance would be 414 considered "early binding" because the name-to-address translation is 415 performed prior to data being sent into the network. 417 In a frequently-disconnected network, late binding may be 418 advantageous because the transit time of a message may exceed the 419 validity time of a binding. Furthermore, use of name-based routing 420 with late binding may reduce the amount of administrative (mapping) 421 information that must propagate through the network, and may also 422 limit the scope of mapping synchronization requirements to a local 423 topological neighborhood of its origin. 425 3.4 Naming of Groups 427 As mentioned above, an EID may refer to one node or a group of DTN 428 nodes. When referring to a group of nodes, the delivery semantics 429 may be of either the anycast or multicast variety (broadcast is 430 considered to be of the multicast variety). For anycast group 431 delivery, a message is delivered to one node among a group of 432 potentially many nodes, and for multicast delivery it is intended to 433 be delivered to all of them, subject to the normal DTN quality of 434 service and maximum useful lifetime semantics. Group join operations 435 are initiated at receivers. 437 Multicast group delivery in a DTN presents an unfamiliar issue with 438 respect to group membership. In relatively low-delay networks, such 439 as the Internet, nodes may be considered to be part of the group if 440 they have expressed interest to join it "recently." In a DTN, 441 however, nodes may wish to receive data sent to a group during an 442 interval of time earlier than when they are actually able to receive 443 it [ZAZ05]. More precisely, an application expresses its desire to 444 receive data sent to EID e at time t. Prior to this, during the 445 interval [t0, t1], t > t1, data may have been generated for group e. 446 For the application to receive any of this data, the data must be 447 available a potentially long time after senders have ceased sending 448 to the group. Thus, the data may need to be stored within the 449 network in order to support temporal group semantics of this kind. 450 How to design and implement this remains a research issue, as it is 451 likely to be at least as hard as problems related to reliable 452 multicast. 454 3.5 Priority Classes 456 The DTN architecture offers *relative* measures of priority (low, 457 medium, high) for delivering traffic. These priorities differentiate 458 traffic based upon an application's desire to affect the delivery 459 urgency for messages. 461 The (U.S. or similar) Postal Service provides a strong metaphor for 462 the priority classes offered by the DTN architecture. Traffic is 463 generally not interactive and is often one-way. There are generally 464 no strong guarantees of timely delivery, yet there are some forms of 465 class of service, reliability, and security. 467 We have currently defined three relative priority classes. These 468 priority classes typically imply some relative scheduling 469 prioritization among bundles in queue at a sender: 471 - Bulk - Bulk bundles are shipped on a "least effort" basis. No 472 bundles of this class will be shipped until all bundles of other 473 classes bound for the same destination and originating from the 474 same source have been shipped. 475 - Normal - Normal class bundles are shipped prior to any bulk class 476 bundles and are otherwise the same as bulk bundles. 477 - Expedited - Expedited bundles, in general, are shipped prior to 478 bundles of other classes and are otherwise the same. 480 Applications specify their requested priority class and data lifetime 481 (see below) for each message they send. This information, coupled 482 with policy applied at DTN nodes that forward messages and routing 483 algorithms in use, affects the overall likelihood and timeliness of 484 message delivery. 486 The priority class of a message is only required to relate to other 487 messages from the same source. This means that a high priority 488 message from one source may not be delivered faster (or with some 489 other superior quality of service) than a medium priority message 490 from a different source. It does mean that a high priority message 491 from one source will be handled preferentially to a lower priority 492 message sent from the same source. 494 Depending on a particular DTN node's forwarding/scheduling policy, 495 priority may or may not be enforced across different sources. That 496 is, in some DTN nodes, expedited bundles might always be sent prior 497 to any bulk bundles, irrespective of source. Many variations are 498 possible. 500 3.6 Postal-Style Delivery Options and Administrative Records 502 Continuing with the postal analogy of message delivery, the DTN 503 architecture supports several delivery options that may be selected 504 by an application when it requests the transmission of a message. In 505 addition, the architecture defines two types of administrative 506 records: "status reports" and "signals." These records are bundles 507 that provide information about the delivery of other bundles, and are 508 used in conjunction with the delivery options. 510 3.6.1 Delivery Options 512 We have currently defined eight basic delivery options. Applications 513 sending a message may request any combination of the following: 515 - Custody Transfer Requested - requests a bundle be delivered with 516 enhanced reliability using custody transfer procedures. A bundle 517 will be transmitted by the bundle layer using reliable transfer 518 protocols (if available), and the responsibility for reliable 519 delivery of the bundle to its destination(s) may move among one or 520 more "custodians" in the network. This capability is described in 521 more detail in Section 3.10. 523 - Source Node Custody Acceptance Required - requires the source DTN 524 node to provide custody transfer for the message being sent. If 525 custody transfer is not available at the source when this delivery 526 option is requested, the requested transmission fails. This 527 provides a means for applications to insist that the source DTN 528 node take custody of the message. 530 - Report when Bundle Received - requests a Bundle Reception Status 531 Report be generated when the subject bundle arrives at a DTN node. 533 - Report when Bundle Custody Accepted - requests a Custody 534 Acceptance Status Report be generated when the subject bundle has 535 been accepted using custody transfer. 537 - Report when Bundle Forwarded - requests a Bundle Forwarding Status 538 Report be generated when the subject bundle departs a DTN node 539 that has forwarded it. 541 - Report when Bundle Delivered - requests a Bundle Delivery Status 542 Report be generated when the bundle reaches its intended 543 recipient(s). This request is also known as "return-receipt." 545 - Report when Bundle Deleted - requests a Bundle Deletion Status 546 Report be generated when the subject bundle is deleted at a DTN 547 node. 549 - Report when Bundle Acknowledged by Application - requests an 550 Acknowledgement Status Report be generated when the subject bundle 551 is acknowledged by a receiving application. This only happens by 552 action of the receiving application, and differs from the Bundle 553 Delivery Status Report. It is intended for cases where the 554 application may be acting as a form of application layer gateway 555 and wishes to indicate the status of a protocol operation external 556 to DTN back to the requesting source. 558 If the security procedures defined in [DTNSEC] are also enabled, then 559 three additional delivery options become available: 561 - Confidentiality Required - requires a bundle's data be made secret 562 from parties other than the source and the members of the 563 destination EID 565 - Authentication Required - requires all non-mutable fields in the 566 headers of bundles (i.e., those which do not change as the bundle 567 is forwarded) be made strongly verifiable (i.e. cryptographically 568 strong). This protects several fields, including the source and 569 destination EIDs and the bundle's data. 571 - Error Detection Required - requires modifications to a bundle's 572 non-mutable fields be made detectable with high probability at 573 each destination 575 3.6.2 Bundle Status Reports and Custody Signals 577 Bundle Status Reports (BSRs) provide information and diagnostic 578 responses in DTN and correspond (approximately) to the ICMP protocol 579 in IP [RFC792]. In ICMP, however, messages are returned to the 580 source. In DTN, they are instead directed to the report-to EID, 581 which might differ from the source's EID. BSRs are sent as bundles 582 with a source EID set to one of the EIDs associated with the DTN node 583 generating the BSR. In some cases, arrival of a single bundle or 584 bundle fragment may elicit multiple BSRs (e.g., in the case where a 585 bundle is replicated for multicast forwarding). Many of the BSRs are 586 used in forming responses to the delivery options discussed in the 587 previous sub-section. 589 The following BSRs are currently defined (also see [BSPEC] for more 590 details): 592 - Bundle Reception - sent when a bundle arrives at a DTN node 594 - Custody Acceptance - sent when a node has accepted custody of a 595 bundle with the Custody Transfer Requested option set 597 - Bundle Forwarded - sent when a bundle containing a Report when 598 Bundle Forwarded option departs from a DTN node after having been 599 forwarded. 601 - Bundle Delivery - sent from a final recipient's (destination) node 602 when a bundle containing a Report when Bundle Delivered option is 603 consumed by an application 605 - Bundle Deletion - sent from a DTN node when a bundle containing a 606 Report when Bundle Deleted option is discarded. This can happen 607 for several reasons, such as expiration 609 - Acknowledged by application - sent from a DTN node when a bundle 610 containing an Application Acknowledgment option has been processed 611 by an application. This generally involves specific action on the 612 receiving application's part 614 In addition to the status reports, a signal is currently defined to 615 indicate the status of a custody transfer. These are sent to the 616 current-custodian EID contained in an arriving bundle: 618 - Custody Signal - indicates that custody has been successfully 619 transferred. This signal appears as a Boolean indicator, and may 620 therefore indicate either a successful or a failed custody 621 transfer attempt 623 The BSRs must reference a received bundle. This is accomplished by a 624 method for uniquely identifying bundles based on a transmission 625 timestamp and sequence number discussed in Section 3.12. 627 3.7 Primary Bundle Fields 629 The bundles carried between and among DTN nodes obey a standard 630 bundle protocol specified in [BSPEC]. Here we provide an overview of 631 most of the fields carried with every bundle. The protocol is 632 designed with a mandatory primary header, an optional payload header 633 (which contains the payload itself), and a set of optional extension 634 headers. Headers may be cascaded in a way similar to IPv6. The 635 following selected fields are all present in the primary header, and 636 therefore are present for every bundle and fragment: 638 - Creation Timestamp - a concatenation of the bundle's creation time 639 and a monotonically increasing sequence number such that the 640 creation timestamp is guaranteed to be unique for each bundle 641 originating from the same source. The creation timestamp is based 642 on the time-of-day an application requested a message to be sent 643 (and a bundle containing the message was formed by the sender's DTN 644 node). DTN nodes are assumed to have a basic time synchronization 645 capability (see Section 3.11). 647 - Lifespan - the time-of-day at which the message is no longer 648 useful. If a bundle is stored in the network (including the 649 source's DTN node) when its lifespan is reached, it may be 650 discarded. The lifespan of a bundle is expressed as an offset 651 relative to its creation time. 653 - Class of Service Flags - indicates the delivery options and 654 priority class for the bundle. Priority classes may be one of 655 bulk, normal, or expedited. See Section 3.6.1. 657 - Source EID - EID of the source (the first sender) 658 - Destination EID - EID of the destination (the final intended 659 recipient(s)) 661 - Report-To Endpoint ID - an EID identifying where reports (return- 662 receipt, route-tracing functions) should be sent. This may or may 663 not identify the same node as the Source EID. 665 - Custodian EID - EID of the current custodian of a bundle (if any) 667 The payload header indicates information about the contained payload 668 (e.g. its length) and, somewhat unusually, includes the payload 669 itself. In addition to the fields found in the primary and payload 670 headers, each bundle may have fields in the extension headers carried 671 with each bundle. See [BSPEC] for additional details. 673 3.8 Routing and Forwarding 675 The DTN architecture provides a framework for routing and forwarding 676 at the bundle layer for unicast, anycast, and multicast messages. 677 Because nodes in a DTN network might be interconnected using more 678 than one type of underlying network technology, a DTN network is 679 best described abstractly using a *multigraph* (a graph where 680 vertices may be interconnected with more than one edge). Edges in 681 this graph are, in general, time-varying with respect to their delay 682 and capacity and directional because of the possibility of one-way 683 connectivity. When an edges has zero capacity, it is considered to 684 not be connected. 686 Because edges in a DTN graph may have significant delay, it is 687 important to distinguish where time is measured when expressing an 688 edge's capacity or delay. We adopt the convention of expressing 689 capacity and delay as functions of time where time is measured at the 690 point where data is inserted into a network edge. For example, 691 consider an edge having capacity C(t) and delay D(t) at time t. If B 692 bits are placed in this edge at time t, they arrives at time t + D(t) 693 + (1/C(t))*B. 695 Because edges may vary between positive and zero capacity, it is 696 possible to describe a period of time (interval) during which the 697 capacity is strictly positive, and the delay and capacity can be 698 considered to be constant [AF03]. This period of time is called a 699 "contact." In addition, the product of the capacity and the interval 700 is known as a contact's "volume." If contacts and their volumes are 701 known ahead of time, intelligent routing and forwarding decisions can 702 be made (optimally for small networks) [JPF04]. Optimally using a 703 contact's volume, however, requires the ability to divide large 704 messages into smaller routable units. This is provided by DTN 705 fragmentation (see Section 3.9). 707 When delivery paths through a DTN graph are lossy or contact 708 intervals and volumes are not known precisely ahead of time, routing 709 computations become especially challenging. How to handle these 710 situations is an active area of work in the (emerging) research area 711 of delay tolerant networking. 713 3.8.1 Types of Contacts 715 Contacts typically fall into one of several categories, based largely 716 on the predictability of their performance characteristics and 717 whether some action is required to bring them into existence. To 718 date, the following major types of contacts have been defined: 720 Persistent Contacts 722 Persistent contacts are always available (i.e., no connection- 723 initiation action is required to instantiate a persistent contact). 724 An 'always-on' Internet connection such as a DSL or Cable Modem 725 connection would be representatives of this class. 727 On-Demand Contacts 729 On-Demand contacts require some action in order to instantiate, but 730 then function as persistent contacts until terminated. A dial-up 731 connection is an example of an On-Demand contact (at least, from the 732 viewpoint of the dialer; it may be viewed as an Opportunistic Contact 733 - below - from the viewpoint of the dial-up service provider). 735 Intermittent - Scheduled Contacts 737 A scheduled contact is an agreement to establish a contact at a 738 particular time, for a particular duration. An example of a 739 scheduled contact is a link with a low-earth orbiting satellite. A 740 node's list of contacts with the satellite can be constructed from 741 the satellite's schedule of view times, capacities and latencies. 742 Note that for networks with substantial delays, the notion of the 743 "particular time" is delay-dependent. For example, a single 744 scheduled contact between Earth and Mars would not be at the same 745 instant in each location, but would instead be offset by the (non- 746 negligible) propagation delay. 748 Intermittent - Opportunistic Contacts 750 Opportunistic contacts are not scheduled, but rather present 751 themselves unexpectedly. For example, an unscheduled aircraft flying 752 overhead and beaconing, advertising its availability for 753 communication, would present an opportunistic contact. Another type 754 of opportunistic contact might be via an infrared or BlueTooth 755 communication link between a personal digital assistant (PDA) and a 756 kiosk in an airport concourse. The opportunistic contact begins as 757 the PDA is brought near the kiosk, lasting an undetermined amount of 758 time (i.e., until the link is lost or terminated). 760 Intermittent - Predicted Contacts 761 Predicted contacts are based on no fixed schedule, but rather are 762 predictions of likely contact times and durations based on a history 763 of previously observed contacts or some other information. Given a 764 great enough confidence in a predicted contact, routes may be chosen 765 based on this information. This is an active research area, and a 766 few approaches having been proposed [LFC05]. 768 3.9 Fragmentation and Reassembly 770 DTN fragmentation and reassembly is designed to improve the 771 efficiency of message transfers by ensuring that contact volumes are 772 fully utilized and by avoiding re-transmission of partially-forwarded 773 messages. There are two forms of DTN fragmentation/reassembly: 775 Proactive Fragmentation 777 A DTN node may divide a block of application data into multiple 778 smaller blocks and transmit each such block as an independent 779 bundle. In this case the *final destination(s)* are responsible 780 for extracting the smaller blocks from incoming bundles and 781 reassembling them into the original larger bundle. This approach 782 is called proactive fragmentation because it is used primarily when 783 contact volumes are known (or predicted) in advance. 785 Reactive Fragmentation 787 DTN nodes sharing an edge in the DTN graph may fragment a bundle 788 cooperatively when a bundle is only partially transferred. In this 789 case, the receiving bundle layer modifies the incoming bundle to 790 indicate it is a fragment, and forwards it normally. The previous- 791 hop sender may learn that only a portion of the bundle was 792 delivered to the next hop, and send the remaining portion(s) when 793 subsequent contacts become available (possibly to different next- 794 hops if routing changes). This is called reactive fragmentation 795 because the fragmentation process occurs after an attempted 796 transmission has taken place. 798 The reactive fragmentation capability is not required to be available 799 in every DTN implementation. It presents significant challenges with 800 respect to handling digital signatures and authentication codes on 801 messages because a signed message may be only partially received, 802 thereby causing most message authentication codes to fail. When DTN 803 security is present and enabled, it may therefore be necessary to 804 proactively fragment large bundles into smaller units that are more 805 convenient for digital signatures. 807 Even if reactive fragmentation is not present in an implementation, 808 the ability to re-assemble fragments at a destination is required in 809 order to support DTN fragmentation. Furthermore, for contacts with 810 volumes that are small compared to typical bundle sizes, some 811 incremental delivery approach must be used (e.g. checkpoint/restart) 812 to prevent data delivery livelock. Reactive fragmentation is one 813 such approach, but other protocol layers could potentially handle 814 this issue as well. 816 3.10 Reliability and Custody Transfer 818 The most basic service provided by the bundle layer is 819 unacknowledged, prioritized (but not guaranteed) unicast message 820 delivery. It also provides two options for enhancing delivery 821 reliability: end-to-end acknowledgments and custody transfer. 822 Applications wishing to implement their own end-to-end message 823 reliability mechanisms are free to utilize the acknowledgment. The 824 custody transfer feature of the DTN architecture only specifies a 825 coarse-grained retransmission capability, described next. 827 Transmission of bundles with the Custody Transfer Requested option 828 specified generally involves moving the responsibility for reliable 829 delivery of the message among different DTN nodes in the network. 830 For unicast delivery, this will typically involve moving a copy of 831 the message "closer" (in terms of some routing metric) to its 832 ultimate destination. The nodes receiving these copies along the way 833 (and agreeing to accept the reliable delivery responsibility) are 834 called "custodians." The movement of a message (and its delivery 835 responsibility) from one node to another is called a "custody 836 transfer." It is analogous to a database commit transaction [FHM03]. 837 The exact meaning and design of custody transfer for multicast and 838 anycast delivery remains to be fully explored. 840 Custody transfer allows the source to delegate retransmission 841 responsibility and recover its retransmission-related resources 842 relatively soon after sending a bundle (on the order of the minimum 843 round-trip time to the first bundle hop(s)). Not all nodes in a DTN 844 are required by the DTN architecture to accept custody transfers, so 845 it is not a true 'hop-by-hop' mechanism. For example, some nodes may 846 have sufficient storage resources to sometimes act as custodians, but 847 may elect to not offer such services when congested or running low on 848 power. 850 The existence of custodians can alter the way DTN routing is 851 performed. In some circumstances, it may be beneficial to move a 852 message to a custodian as quickly as possible even if it is further 853 away (in terms of distance, time or some routing metric) from the 854 final destination(s). Designing a system with this capability 855 involves constructing more than one routing graph, and is an area of 856 continued research. 858 Custody transfer in DTN not only provides a method for tracking 859 messages that require special handling and identifying DTN nodes that 860 participate in custody transfer, it also provides a (weak) mechanism 861 for enhancing the reliability of message delivery. Generally 862 speaking, custody transfer relies on underlying reliable delivery 863 protocols of the networks that it operates over to provide the 864 primary means of reliable transfer from one bundle node to the next 865 (set). However, when custody transfer is requested, the bundle layer 866 provides an additional coarse-grained timeout and retransmission 867 mechanism and an accompanying (bundle-layer) custodian-to-custodian 868 acknowledgment signaling mechanism. When an application does *not* 869 request custody transfer, this bundle layer timeout and 870 retransmission mechanism is typically not employed, and successful 871 bundle layer delivery depends solely on the reliability mechanisms of 872 the underlying protocols. 874 When a node accepts custody for a bundle that contains the Custody 875 Transfer Requested option, a Custody Transfer Accepted Signal is sent 876 by the bundle layer to the Current Custodian EID contained in the 877 bundle header. In addition, the Current Custodian EID is updated to 878 contain one of the forwarding node's (unicast) EIDs before the bundle 879 is forwarded. 881 When an application requests a message to be delivered with custody 882 transfer, the request is advisory. In some circumstances, a source 883 of a bundle for which custody transfer has been requested may not be 884 able to provide this service. In such circumstances, the subject 885 bundle may traverse multiple DTN nodes before it obtains a custodian. 886 Bundles in this condition are specially marked with their Current 887 Custodian EID field set to a null endpoint. In cases where 888 applications wish to require the source to take custody of the bundle 889 they may supply the Source Node Custody Acceptance Required delivery 890 option. This may be useful to applications that desire a continuous 891 "chain" of custody or that wish to exit after being ensured their 892 data is safely held in a custodian. 894 In a DTN network where one or more custodian-to-custodian hops are 895 strictly one directional (and cannot be reversed), the DTN custody 896 transfer mechanism will be affected over such hops due to the lack of 897 any way to receive a custody signal (or any other information) back 898 across the path, resulting in the expiration of the bundle at the 899 ingress to the one-way hop. This situation does not necessarily mean 900 the bundle has been lost; nodes on the other side of the hop may 901 continue to transfer custody, and the bundle may be delivered 902 successfully to its destination(s). However, in this circumstance a 903 source that has requested to receive expiration BSRs for this bundle 904 will receive an expiration report for the bundle, and possibly 905 conclude (incorrectly) the bundle has been discarded and not 906 delivered. Although this problem cannot be fully solved in this 907 situation, a mechanism is provided to help ameliorate the seemingly 908 incorrect information that may be reported when the bundle expires 909 after having been transferred over a one-way hop. This is 910 accomplished by the node at the ingress to the one-way hop reporting 911 the existence of a known one-way path using a variant of a bundle 912 status report. These types of reports are provided if the subject 913 bundle requests the report using the 'report when bundle forwarded' 914 delivery option. 916 3.11 DTN Support for Proxies and Application Layer Gateways 917 One of the aims of DTN is to provide a common method for 918 interconnecting application layer gateways and proxies. In cases 919 where existing Internet applications can be made to tolerate delays, 920 local proxies can be constructed to benefit from the existing 921 communication capabilities provided by DTN [S05, T02]. Making such 922 proxies compatible with DTN reduces the burden on the proxy author 923 from being concerned with how to implement routing and reliability 924 management and allows existing TCP/IP-based applications to operate 925 unmodified over a DTN-based network. 927 When DTN is used to provide a form of tunnel encapsulation for other 928 protocols, it can be used in constructing overlay networks comprised 929 of application layer gateways. The application acknowledgment 930 capability is designed for such circumstances. This provides a 931 common way for remote application layer gateways to signal the 932 success or failure of non-DTN protocol operations initiated as a 933 result of receiving DTN messages. Without this capability, such 934 indicators would have to implemented by applications themselves in 935 non-standard ways. 937 3.12 Time Stamps and Time Synchronization 939 The DTN architecture depends on time synchronization among DTN nodes 940 (supported by external, non-DTN protocols) for four primary purposes: 941 bundle and fragment identification, routing with scheduled or 942 predicted contacts, bundle expiration time computations, and 943 application registration expiration. 945 Bundle identification and expiration are supported by placing a 946 creation timestamp and an explicit expiration field (expressed in 947 seconds after the source time stamp) in each bundle header. The 948 origination time stamp on an arriving bundle is made available to 949 consuming applications by some system interface function. Each 950 bundle is required to contain a timestamp unique to the bundle 951 sender's EID. The concatenation of the Source EID and the creation 952 timestamp serves as a unique identifier for a particular bundle, and 953 is used for a number of purposes, including custody transfer and 954 reassembly of bundle fragments. 956 Time is also used in conjunction with application registrations. 957 When an application expresses its desire to receive data for a 958 particular EID, this registration is only maintained for a finite 959 period of time, and may be specified by the application. For 960 multicast registrations, an application may also specify a time range 961 or "interest interval" for its registration. In this case, traffic 962 sent to the specified EID any time during the specified interval will 963 eventually be delivered to the application (unless such traffic has 964 expired due to the expiration time provided by the application at the 965 source or some other reason prevents such delivery). 967 3.13 Congestion and Flow Control at the Bundle Layer 968 The subject of congestion control and flow control at the bundle 969 layer is one on which the authors of this document have not yet 970 reached complete consensus. We have unresolved concerns about the 971 efficiency and efficacy of congestion and flow control schemes 972 implemented across long and/or highly variable delay environments, 973 especially with the custody transfer mechanism that may require nodes 974 to retain messages for long periods of time. 976 For the purposes of this document, we define "flow control" as a 977 means of assuring that the average rate at which a sending node 978 transmits data to a receiving node does not exceed the average rate 979 at which the receiving node is prepared to receive data from that 980 sender. (Note that this is a generalized notion of flow control, 981 rather than one that applies only to end-to-end communication.) We 982 define "congestion control" as a means of assuring that the aggregate 983 rate at which all traffic sources inject data into a network does not 984 exceed the maximum aggregate rate at which the network can deliver 985 data to destination nodes over time. If flow control is propagated 986 backward from congested nodes toward traffic sources, then the flow 987 control mechanism can be used as at least a partial solution to the 988 problem of congestion as well. 990 DTN flow control decisions must be made within the bundle layer 991 itself based on information about resources (in this case, primarily 992 persistent storage) available within the bundle node. When storage 993 resources become scarce, a DTN node has only a certain degree of 994 freedom in handling the situation. It can always discard bundles 995 which have expired-- an activity DTN nodes should perform regularly 996 in any case. If it ordinarily is willing to accept custody for 997 bundles, it can cease doing so. It can also discard bundles which 998 have not expired but for which it has not accepted custody. A node 999 must avoid discarding bundles for which it has accepted custody. 1000 Determining when a node should engage in or cease to engage in 1001 custody transfers is a resource allocation and scheduling problem of 1002 current research interest. 1004 In addition to the bundle layer mechanisms described above, a DTN 1005 node may be able to avail itself of support from lower layer 1006 protocols in affecting its own resource utilization. For example, a 1007 DTN node receiving a bundle using TCP/IP might intentionally slow 1008 down its receiving rate by performing read operations less frequently 1009 in order to reduce its offered load. This is possible because TCP 1010 provides its own flow control, so reducing the application data 1011 consumption rate could effectively implement a form of hop-by-hop 1012 flow control. Unfortunately, it may also lead to head-of-line 1013 blocking issues, depending on the nature of bundle multiplexing 1014 within a TCP connection. A protocol with more relaxed ordering 1015 constraints (e.g. SCTP [RFC2960]) might be preferable in such 1016 circumstances. 1018 3.14 Security 1019 The possibility of severe resource scarcity in some delay-tolerant 1020 networks dictates that some form of authentication and access control 1021 to the network itself is required in many circumstances. It is not 1022 acceptable for an unauthorized user to flood the network with traffic 1023 easily, possibly denying service to authorized users. In many cases 1024 it is also not acceptable for unauthorized traffic to be forwarded 1025 over certain network links at all. This is especially true for 1026 exotic, mission-critical links. In light of these considerations, 1027 several goals are established for the security component of the DTN 1028 architecture: 1030 - Promptly prevent unauthorized applications from having their data 1031 carried through the DTN 1032 - Prevent unauthorized applications from asserting control over the 1033 DTN infrastructure 1034 - Prevent otherwise authorized applications from sending bundles at a 1035 rate or class of service for which they lack permission 1036 - Promptly discard bundles that are damaged or improperly modified in 1037 transit 1038 - Promptly detect and de-authorize compromised entities 1040 Many existing authentication and access control protocols designed 1041 for operation in low-delay, connected environments may not perform 1042 well in DTNs. In particular, updating access control lists and 1043 revoking ("blacklisting") credentials may be especially difficult. 1044 Also, approaches that require frequent access to centralized servers 1045 to complete an authentication or authorization transaction are not 1046 attractive. The consequences of these difficulties include delays in 1047 the onset of communication, delays in detecting and recovering from 1048 system compromise, and delays in completing transactions due to 1049 inappropriate access control or authentication settings. 1051 To help satisfy these security requirements in light of the 1052 challenges, the DTN architecture adopts a standard but optionally 1053 deployed security architecture [DTNSEC] that utilizes hop-by-hop and 1054 end-to-end authentication and integrity mechanisms. The purpose of 1055 using both approaches is to be able to handle access control for data 1056 forwarding separately from application-layer data integrity. While 1057 the end-to-end mechanism provides authentication for a principal such 1058 as a user (of which there may be many), the hop-by-hop mechanism is 1059 intended to authenticate DTN nodes as legitimate transceivers of 1060 bundles to each-other. Note that it is conceivable to construct a 1061 DTN in which only a subset of the nodes participate in the security 1062 mechanisms, resulting in a secure DTN overlay existing atop an 1063 insecure DTN overlay. This idea is relatively new and is still being 1064 explored. 1066 In accordance with the goals listed above, DTN nodes discard traffic 1067 as early as possible if authentication or access control checks fail. 1068 This approach meets the goals of removing unwanted traffic from being 1069 forwarded over specific high-value links, but also has the associated 1070 benefit of making denial-of-service attacks considerably harder to 1071 mount more generally, as compared with conventional Internet routers. 1073 However, the obvious cost for this capability is potentially larger 1074 computation and storage overhead required at DTN nodes. 1076 4 State Management Considerations 1078 An important aspect of any networking architecture is its management 1079 of state. This section describes the state managed at the bundle 1080 layer and discusses how it is established and removed. 1082 4.1 Application Registration State 1084 In long/variable delay environments, an asynchronous application 1085 interface seems most appropriate. Such interfaces typically include 1086 methods for applications to register callback actions when certain 1087 triggering events occur (e.g. when messages arrive). These 1088 registrations create state information called application 1089 registration state. 1091 Application registration state is typically created by explicit 1092 request of the application, and is removed by a separate explicit 1093 request, but may also be removed by an application-specified timer 1094 (it is thus "firm" state). In most cases, there must be a provision 1095 for retaining this state across application and operating system 1096 termination/restart conditions because a client/server message round- 1097 trip time may exceed the requesting application's execution time (or 1098 hosting system's uptime). In cases where applications are not 1099 automatically restarted but application registration state remains 1100 persistent, a method must be provided to indicate to the system what 1101 action to perform when the triggering event occurs (e.g. restarting 1102 some application, ignoring the event, etc.). 1104 To initiate a registration and thereby establish application 1105 registration state, an application specifies an Endpoint ID for which 1106 it wishes to receive messages, along with an optional time value 1107 indicating how long the registration should remain active. This 1108 operation is somewhat analogous to the bind() operation in the common 1109 sockets API. 1111 For registrations to groups (i.e., joins), a time interval may also 1112 be specified. The time interval refers to the range of origination 1113 times of messages sent to the specified EID. See Section 3.4 above 1114 for more details. 1116 4.2 Custody Transfer State 1117 Custody transfer state includes information required to keep account 1118 of bundles for which a node has taken custody, as well as the 1119 protocol state related to transferring custody for one or more of 1120 them. The accounting-related state is created when a bundle is 1121 received. Custody transfer retransmission state is created when a 1122 transfer of custody is initiated by forwarding a bundle with the 1123 custody transfer requested delivery option specified. Retransmission 1124 state and accounting state may be released upon receipt of one or 1125 more Custody Transfer Succeeded signals, indicating custody has been 1126 moved. In addition, the bundle's expiration time (possibly mitigated 1127 by local policy) provides an upper bound on the time when this state 1128 is purged from the system in the event that it is not purged 1129 explicitly due to receipt of a signal. 1131 4.3 Bundle Routing and Forwarding State 1133 As with the Internet architecture, we distinguish between routing and 1134 forwarding. Routing refers to the execution of a (possibly 1135 distributed) algorithm for computing routing paths according to some 1136 objective function (see [JFP04], for example). Forwarding refers to 1137 the act of moving a message from one DTN node to another. Routing 1138 makes use of routing state (the RIB, or routing information base), 1139 while forwarding makes use of state derived from routing, and is 1140 maintained as forwarding state (the FIB, or forwarding information 1141 base). The structure of the FIB and the rules for maintaining it are 1142 implementation choices. In some DTNs exchange of information used to 1143 update state in the RIB may take place on network paths distinct from 1144 those where exchange of application data takes place. 1146 The maintenance of state in the RIB is dependent on the type of 1147 routing algorithm being used. A routing algorithm may consider 1148 requested class of service and the location of potential custodians 1149 (for custody transfer, see section 3.10), and this information will 1150 tend to increase the size of the RIB. The separation between FIB and 1151 RIB is not required by this document, as these are implementation 1152 details to be decided by system implementers. The choice of routing 1153 algorithms is still under study. 1155 Bundles may occupy queues in nodes for a considerable amount of time. 1156 For unicast or anycast delivery, the amount of time is likely to be 1157 the interval between when a bundle arrives at a node and when it can 1158 be forwarded to its next hop. For multicast delivery of bundles, 1159 this could be significantly longer, up to a bundle's expiration time. 1160 This situation occurs when multicast delivery is utilized in such a 1161 way that nodes joining a group can obtain information previously sent 1162 to the group. In such cases, some nodes may act as "archivers" that 1163 provide copies of bundles to new participants that have already been 1164 delivered to other participants. 1166 4.4 Security-Related State 1168 The DTN security approach described in [DTNSEC], when used, requires 1169 maintenance of state in all DTN nodes that use it. All such nodes 1170 are required to store their own private information (including their 1171 own policy and authentication material) and a block of information 1172 used to verify credentials. Furthermore, in most cases, DTN nodes 1173 will cache some public information (and possibly the credentials) of 1174 their next-hop (bundle) neighbors. All cached information has 1175 expiration times, and nodes are responsible for acquiring and 1176 distributing updates of public information and credentials prior to 1177 the expiration of the old set (in order to avoid a disruption in 1178 network service). 1180 In addition to basic end-to-end and hop-by-hop authentication, access 1181 control may be used in a DTN by one or more mechanisms such as 1182 capabilities or access control lists (ACLs). ACLs would represent 1183 another block of state present in any node that wishes to enforce 1184 security policy. ACLs are typically initialized at node 1185 configuration time and may be updated dynamically by DTN bundles or 1186 by some out of band technique. Capabilities or credentials may be 1187 revoked, requiring the maintenance of a revocation list ("black 1188 list," another form of state) to check for invalid authentication 1189 material that has already been distributed. 1191 Some DTNs may implement security boundaries enforced by selected 1192 nodes in the network, where end-to-end credentials may be checked in 1193 addition to checking the hop-by-hop credentials. (Doing so may 1194 require routing to be adjusted to ensure complete bundles pass 1195 through these points). Public information used to verify end-to-end 1196 authentication will typically be cached at these points. 1198 4.5 Policy and Configuration State 1200 DTN nodes will contain some amount of configuration and policy 1201 information. Such information may alter the behavior of bundle 1202 forwarding. Examples of policy state include the types of 1203 cryptographic algorithms and access control procedures to use if DTN 1204 security is employed, whether nodes may become custodians, what types 1205 of convergence layer and routing protocols are in use, how bundles of 1206 differing priorities should be scheduled, where and for how long 1207 bundles and other data is stored, etc. 1209 5 Application Structuring Issues 1211 DTN bundle delivery is intended to operate in a delay-tolerant 1212 fashion over a broad range of network types. This does not mean 1213 there *must* be large delays in the network; it means there *may* be 1214 very significant delays (including extended periods of disconnection 1215 between sender and intended recipient). The DTN protocols are delay 1216 tolerant, so applications using them must also be delay tolerant in 1217 order to operate effectively in environments subject to significant 1218 delay or disruption. 1220 The communication primitives provided by the DTN architecture are 1221 based on asynchronous, message-oriented communication which differs 1222 from conversational request/response communication. In general, 1223 applications should attempt to include enough information in a 1224 message so that it may be treated as an independent unit of work by 1225 the receiving entity. (This represents a form of "application data 1226 unit" [CT90]). The goal is to minimize synchronous interchanges 1227 between applications that are separated by a network characterized by 1228 long and possibly highly variable delays. A single file transfer 1229 request message, for example, might include authentication 1230 information, file location information, and requested file operation 1231 (thus "bundling" this information together). Comparing this style of 1232 operation to a classic FTP transfer, one sees that the bundled model 1233 can complete in one round trip, whereas an FTP file "put" operation 1234 can take as many as eight round trips to get to a point where file 1235 data can flow [DFS02]. 1237 Delay-tolerant applications must consider additional factors beyond 1238 the conversational implications of long delay paths. For example, an 1239 application may terminate (voluntarily or not) between the time it 1240 sends a message and the time it expects a response. If this 1241 possibility has been anticipated, the application can be "re- 1242 instantiated" with state information saved in persistent storage. 1243 This is an implementation issue, but also an application design 1244 consideration. 1246 Some consideration of delay-tolerant application design can result in 1247 applications that work reasonably well in low-delay environments, and 1248 that do not suffer extraordinarily in high or highly-variable delay 1249 environments. 1251 6 Convergence Layer Considerations for Use of Underlying Protocols 1253 Implementation experience with the DTN architecture has revealed an 1254 important architectural construct and interface for DTN nodes 1255 [DBFJHP04]. Not all underlying protocols in different protocol 1256 families provide the same exact functionality, so some additional 1257 adaptation or augmentation on a per-protocol or per-protocol-family 1258 basis may be required. This adaptation is accomplished by a set of 1259 convergence layers placed between the bundle layer and underlying 1260 protocols. The convergence layers manage the protocol-specific 1261 details of interfacing with particular underlying protocols and 1262 present a consistent interface to the bundle layer. 1264 The complexity of one convergence layer may vary substantially from 1265 another, depending on the type of underlying protocol it adapts. For 1266 example, a TCP/IP convergence layer for use in the Internet might 1267 only have to add message boundaries to TCP streams, whereas a 1268 convergence layer for some network where no reliable transport 1269 protocol exists might be considerably more complex (e.g. it might 1270 have to implement reliability, fragmentation, flow-control, etc.) if 1271 reliable delivery is to be offered to the bundle layer. 1273 As convergence layers implement protocols above and beyond the basic 1274 bundle protocol specified in [BSPEC], they will be defined in their 1275 own documents (in a fashion similar to the way encapsulations for IP 1276 datagrams are specified on a per-underlying-protocol basis, such as 1277 in RFC 894 [RFC894]). 1279 7 Summary 1281 The DTN architecture addresses many of the problems of heterogeneous 1282 networks that must operate in environments subject to long delays and 1283 discontinuous end-to-end connectivity. It is based on asynchronous 1284 messaging and uses postal mail as a model of service classes and 1285 delivery semantics. It accommodates many different forms of 1286 connectivity, including scheduled, predicted, and opportunistically 1287 connected links. It introduces a novel approach to end-to-end 1288 reliability across frequently partitioned and unreliable networks. 1289 It also proposes a model for securing the network infrastructure 1290 against unauthorized access. 1292 It is our belief that this architecture is applicable to many 1293 different types of challenged environments. 1295 8 Security Considerations 1297 Security is an integral concern for the design of the Delay Tolerant 1298 Network Architecture, but its use is optional. Section 3.13 of this 1299 document presents some factors to consider for securing the DTN 1300 architecture, but a separate document [DTNSEC] defines the security 1301 architecture in much more detail. 1303 9 IANA Considerations 1305 This document specifies the architecture for Delay Tolerant 1306 Networking which uses Internet-standard URIs for its Endpoint 1307 Identifiers. URIs intended for use with DTN should be compliant with 1308 the guidelines given in [RFC3986]. 1310 10 Normative References 1312 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 1313 3978, March 2005. 1315 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 1316 Technology", BCP 79, RFC 3979, March 2005. 1318 [RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 1319 Identifier (URI): Generic Syntax", STD 66, RFC 3986, Jan 2005. 1321 11 Informative References 1323 [SB03] S. Burleigh et al, "Delay-Tolerant Networking - An Approach to 1324 Interplanetary Internet," IEEE Communications Magazine, July 2003. 1326 [FW03] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial 1327 v1.1," Wartham Associates, 2003. Available from 1328 http://www.dtnrg.org. 1330 [KF03] K. Fall, "A Delay-Tolerant Network Architecture for Challenged 1331 Internets," Proceedings SIGCOMM, Aug 2003. 1333 [JFP04] S. Jain, K. Fall, R. Patra, "Routing in a Delay Tolerant 1334 Network," Proceedings SIGCOMM, Aug/Sep 2004. 1336 [DFS02] R. Durst, P. Feighery, K. Scott, "Why not use the Standard 1337 Internet Suite for the Interplanetary Internet?", MITRE White Paper, 1338 2002. Available from http://www.ipnsig.org/reports/TCP_IP.pdf 1340 [CK74] V. Cerf, R. Kahn, "A Protocol for Packet Network 1341 Intercommunication," IEEE Trans. on Comm., COM-22(5), May 1974. 1343 [IGE00] C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed 1344 Diffusion: A scalable and robust communication paradigm for sensor 1345 networks," Proceedings MobiCOM, Aug 2000. 1347 [WSBL99] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, J. Lilley, 1348 "The design and implementation of an intentional naming system", 1349 Proc. 17th ACM SOSP, Kiawah Island, SC, Dec. 1999. 1351 [CT90] D. Clark, D. Tennenhouse, "Architectural Considerations for a 1352 new generation of protocols," Proceedings SIGCOMM, 1990. 1354 [ISCHEMES] http://www.iana.org/assignments/uri-schemes 1356 [JDPF05] S. Jain, M. Demmer, R. Patra, K. Fall, "Using Redundancy to 1357 Cope with Failures in a Delay Tolerant Network," Proceedings SIGCOMM 1358 2005. 1360 [WJMF05] Y. Wang, S. Jain, M. Martonosi, K. Fall, "Erasure coding 1361 based routing in opportunistic Networks", Proceedings SIGCOMM 1362 Workshop on Delay Tolerant Networks, 2005. 1364 [ZAZ05] W. Zhao, M. Ammar, E. Zegura, "Multicast in Delay Tolerant 1365 Networks", Proceedings SIGCOMM Workshop on Delay Tolerant Networks, 1366 2005. 1368 [LFC05] J. Leguay, T. Friedman, V. Conan, "DTN Routing in a Mobility 1369 Pattern Space", Proceedings SIGCOMM Workshop on Delay Tolerant 1370 Networks, 2005. 1372 [AF03] J. Alonso, K. Fall, "A Linear Programming Formulation of Flows 1373 over Time with Piecewise Constant Capacity and Transit Times", Intel 1374 Research Technical Report IRB-TR-03-007, June 2003. 1376 [FHM03] K. Fall, W. Hong, S. Madden, "Custody Transfer for Reliable 1377 Delivery in Delay Tolerant Networks", Intel Research Technical Report 1378 IRB-TR-03-030, July 2003. 1380 [RFC2960] R. Stewart et. al., "Stream Control Transmission Protocol", 1381 RFC 2960, Oct. 2000. 1383 [BSPEC] K. Scott, S. Burleigh, "Bundle Protocol Specification", 1384 draft-irtf-dtnrg-bundle-spec-04.txt, Work in Progress, Oct. 2005. 1386 [DTNSEC] S. Symington, S. Farrell, H. Weiss, "Bundle Security 1387 Protocol Specification", draft-irtf-dtnrg-bundle-security-00.txt, 1388 Work in Progress, June 2005. 1390 [DTNSOV] S. Farrell, S. Symington, H. Weiss, "Delay-Tolerant 1391 Networking Security Overview", draft-irtf-dtnrg-sec-overview-00.txt, 1392 Work in Progress, Sep 2005. 1394 [DBFJHP04] M. Demmer, E. Brewer, K. Fall, S. Jain, M. Ho, R. Patra, 1395 "Implementing Delay Tolerant Networking", Intel Research Technical 1396 Report IRB-TR-04-020, Dec. 2004. 1398 [RFC894] C. Hornig, "Standard for the Transmission of IP Datagrams 1399 over Ethernet Networks", RFC 894, Apr. 1984. 1401 [S05] K. Scott, "Disruption Tolerant Networking Proxies for On-the- 1402 Move Tactical Networks", Proc. MILCOM 2005 (unclassified track), Oct. 1403 2005. 1405 [T02] W. Thies, et. al, "Searching the World Wide Web in Low- 1406 Connectivity Communities", Proc. WWW Conference (Global Community 1407 track), May 2002. 1409 Authors' Addresses 1411 Dr. Vinton G. Cerf 1412 Google Corporation 1413 Suite 384 1414 13800 Coppermine Rd. 1415 Herndon, VA 20171 1416 Telephone +1 (703) 234-1823 1417 FAX +1 (703) 848-0727 1418 Email vint@google.com 1420 Scott C. Burleigh 1421 Jet Propulsion Laboratory 1422 4800 Oak Grove Drive 1423 M/S: 179-206 1424 Pasadena, CA 91109-8099 1425 Telephone +1 (818) 393-3353 1426 FAX +1 (818) 354-1075 1427 Email Scott.Burleigh@jpl.nasa.gov 1429 Robert C. Durst 1430 The MITRE Corporation 1431 7515 Colshire Blvd. 1432 M/S H300 1433 McLean, VA 22102 1434 Telephone +1 (703) 883-7535 1435 FAX +1 (703) 883-7142 1436 Email durst@mitre.org 1438 Dr. Kevin Fall 1439 Intel Research, Berkeley 1440 2150 Shattuck Ave., #1300 1441 Berkeley, CA 94704 1442 Telephone +1 (510) 495-3014 1443 FAX +1 (510) 495-3049 1444 Email kfall@intel.com 1446 Adrian J. Hooke 1447 Jet Propulsion Laboratory 1448 4800 Oak Grove Drive 1449 M/S: 303-400 1450 Pasadena, CA 91109-8099 1451 Telephone +1 (818) 354-3063 1452 FAX +1 (818) 393-3575 1453 Email Adrian.Hooke@jpl.nasa.gov 1455 Dr. Keith L. Scott 1456 The MITRE Corporation 1457 7515 Colshire Blvd. 1458 M/S H300 1459 McLean, VA 22102 1460 Telephone +1 (703) 883-6547 1461 FAX +1 (703) 883-7142 1462 Email kscott@mitre.org 1464 Leigh Torgerson 1465 Jet Propulsion Laboratory 1466 4800 Oak Grove Drive 1467 M/S: T1710- 1468 Pasadena, CA 91109-8099 1469 Telephone +1 (818) 393-0695 1470 FAX +1 (818) 354-9068 1471 Email Leigh.Torgerson@jpl.nasa.gov 1473 Howard S. Weiss 1474 SPARTA, Inc. 1475 9861 Broken Land Parkway 1476 Columbia, MD 21046 1477 Telephone +1 (410) 381-9400 x201 1478 FAX +1 (410) 381-5559 1479 Email hsw@sparta.com 1481 Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay 1482 Tolerant Networking Research Group (DTNRG) web site is located at 1483 http://www.dtnrg.org. 1485 Copyright Notice 1487 Copyright (C) The Internet Society (2005). This document is subject 1488 to the rights, licenses and restrictions contained in BCP 78, and 1489 except as set forth therein, the authors retain all their rights. 1491 Disclaimer of Validity 1493 This document and the information contained herein are provided on an 1494 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1495 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1496 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1497 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1498 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1499 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1501 Intellectual Property 1503 The IETF takes no position regarding the validity or scope of any 1504 Intellectual Property Rights or other rights that might be claimed to 1505 pertain to the implementation or use of the technology described in 1506 this document or the extent to which any license under such rights 1507 might or might not be available; nor does it represent that it has 1508 made any independent effort to identify any such rights. Information 1509 on the procedures with respect to rights in RFC documents can be 1510 found in BCP 78 and BCP 79. 1512 Copies of IPR disclosures made to the IETF Secretariat and any 1513 assurances of licenses to be made available, or the result of an 1514 attempt made to obtain a general license or permission for the use of 1515 such proprietary rights by implementers or users of this 1516 specification can be obtained from the IETF on-line IPR repository at 1517 http://www.ietf.org/ipr. 1519 The IETF invites any interested party to bring to its attention any 1520 copyrights, patents or patent applications, or other proprietary 1521 rights that may cover technology that may be required to implement 1522 this standard. Please address the information to the IETF at ietf- 1523 ipr@ietf.org.