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