diff options
Diffstat (limited to 'doc/rfc/rfc4838.txt')
| -rw-r--r-- | doc/rfc/rfc4838.txt | 1963 |
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc4838.txt b/doc/rfc/rfc4838.txt new file mode 100644 index 0000000..d4ac8a7 --- /dev/null +++ b/doc/rfc/rfc4838.txt @@ -0,0 +1,1963 @@ + + + + + + +Network Working Group V. Cerf +Request for Comments: 4838 Google/Jet Propulsion Laboratory +Category: Informational S. Burleigh + A. Hooke + L. Torgerson + NASA/Jet Propulsion Laboratory + R. Durst + K. Scott + The MITRE Corporation + K. Fall + Intel Corporation + H. Weiss + SPARTA, Inc. + April 2007 + + + Delay-Tolerant Networking Architecture + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +IESG Note + + This RFC is a product of the Internet Research Task Force and is not + a candidate for any level of Internet Standard. The IRTF publishes + the results of Internet-related research and development activities. + These results might not be suitable for deployment on the public + Internet. + +Abstract + + This document describes an architecture for delay-tolerant and + disruption-tolerant networks, and is an evolution of the architecture + originally designed for the Interplanetary Internet, a communication + system envisioned to provide Internet-like services across + interplanetary distances in support of deep space exploration. This + document describes an architecture that addresses a variety of + problems with internetworks having operational and performance + characteristics that make conventional (Internet-like) networking + approaches either unworkable or impractical. We define a message- + oriented overlay that exists above the transport (or other) layers of + + + +Cerf, et al. Informational [Page 1] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + the networks it interconnects. The document presents a motivation + for the architecture, an architectural overview, review of state + management required for its operation, and a discussion of + application design issues. This document represents the consensus of + the IRTF DTN research group and has been widely reviewed by that + group. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Why an Architecture for Delay-Tolerant Networking? ..............4 + 3. DTN Architectural Description ...................................5 + 3.1. Virtual Message Switching Using Store-and-Forward + Operation ..................................................5 + 3.2. Nodes and Endpoints ........................................7 + 3.3. Endpoint Identifiers (EIDs) and Registrations ..............8 + 3.4. Anycast and Multicast .....................................10 + 3.5. Priority Classes ..........................................10 + 3.6. Postal-Style Delivery Options and Administrative Records ..11 + 3.7. Primary Bundle Fields .....................................15 + 3.8. Routing and Forwarding ....................................16 + 3.9. Fragmentation and Reassembly ..............................18 + 3.10. Reliability and Custody Transfer .........................19 + 3.11. DTN Support for Proxies and Application Layer Gateways ...21 + 3.12. Timestamps and Time Synchronization ......................22 + 3.13. Congestion and Flow Control at the Bundle Layer ..........22 + 3.14. Security .................................................23 + 4. State Management Considerations ................................25 + 4.1. Application Registration State ............................25 + 4.2. Custody Transfer State ....................................26 + 4.3. Bundle Routing and Forwarding State .......................26 + 4.4. Security-Related State ....................................27 + 4.5. Policy and Configuration State ............................27 + 5. Application Structuring Issues .................................28 + 6. Convergence Layer Considerations for Use of Underlying + Protocols ......................................................28 + 7. Summary ........................................................29 + 8. Security Considerations ........................................29 + 9. IANA Considerations ............................................30 + 10. Normative References ..........................................30 + 11. Informative References ........................................30 + 12. Acknowledgments ...............................................32 + + + + + + + + + +Cerf, et al. Informational [Page 2] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + +1. Introduction + + This document describes an architecture for delay and disruption- + tolerant interoperable networking (DTN). The architecture embraces + the concepts of occasionally-connected networks that may suffer from + frequent partitions and that may be comprised of more than one + divergent set of protocols or protocol families. The basis for this + architecture lies with that of the Interplanetary Internet, which + focused primarily on the issue of deep space communication in high- + delay environments. We expect the DTN architecture described here to + be utilized in various operational environments, including those + subject to disruption and disconnection and those with high-delay; + the case of deep space is one specialized example of these, and is + being pursued as a specialization of this architecture (See [IPN01] + and [SB03] for more details). + + Other networks to which we believe this architecture applies include + sensor-based networks using scheduled intermittent connectivity, + terrestrial wireless networks that cannot ordinarily maintain end-to- + end connectivity, satellite networks with moderate delays and + periodic connectivity, and underwater acoustic networks with moderate + delays and frequent interruptions due to environmental factors. A + DTN tutorial [FW03], aimed at introducing DTN and the types of + networks for which it is designed, is available to introduce new + readers to the fundamental concepts and motivation. More technical + descriptions may be found in [KF03], [JFP04], [JDPF05], and [WJMF05]. + + We define an end-to-end message-oriented overlay called the "bundle + layer" that exists at a layer above the transport (or other) layers + of the networks on which it is hosted and below applications. + Devices implementing the bundle layer are called DTN nodes. The + bundle layer forms an overlay that employs persistent storage to help + combat network interruption. It includes a hop-by-hop transfer of + reliable delivery responsibility and optional end-to-end + acknowledgement. It also includes a number of diagnostic and + management features. For interoperability, it uses a flexible naming + scheme (based on Uniform Resource Identifiers [RFC3986]) capable of + encapsulating different naming and addressing schemes in the same + overall naming syntax. It also has a basic security model, + optionally enabled, aimed at protecting infrastructure from + unauthorized use. + + The bundle layer provides functionality similar to the internet layer + of gateways described in the original ARPANET/Internet designs + [CK74]. It differs from ARPANET gateways, however, because it is + layer-agnostic and is focused on virtual message forwarding rather + than packet switching. However, both generally provide + interoperability between underlying protocols specific to one + + + +Cerf, et al. Informational [Page 3] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + environment and those protocols specific to another, and both provide + a store-and-forward forwarding service (with the bundle layer + employing persistent storage for its store and forward function). + + In a sense, the DTN architecture provides a common method for + interconnecting heterogeneous gateways or proxies that employ store- + and-forward message routing to overcome communication disruptions. + It provides services similar to electronic mail, but with enhanced + naming, routing, and security capabilities. Nodes unable to support + the full capabilities required by this architecture may be supported + by application-layer proxies acting as DTN applications. + +2. Why an Architecture for Delay-Tolerant Networking? + + Our motivation for pursuing an architecture for delay tolerant + networking stems from several factors. These factors are summarized + below; much more detail on their rationale can be explored in [SB03], + [KF03], and [DFS02]. + + The existing Internet protocols do not work well for some + environments, due to some fundamental assumptions built into the + Internet architecture: + + - that an end-to-end path between source and destination exists for + the duration of a communication session + + - (for reliable communication) that retransmissions based on timely + and stable feedback from data receivers is an effective means for + repairing errors + + - that end-to-end loss is relatively small + + - that all routers and end stations support the TCP/IP protocols + + - that applications need not worry about communication performance + + - that endpoint-based security mechanisms are sufficient for meeting + most security concerns + + - that packet switching is the most appropriate abstraction for + interoperability and performance + + - that selecting a single route between sender and receiver is + sufficient for achieving acceptable communication performance + + The DTN architecture is conceived to relax most of these assumptions, + based on a number of design principles that are summarized here (and + further discussed in [KF03]): + + + +Cerf, et al. Informational [Page 4] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + - Use variable-length (possibly long) messages (not streams or + limited-sized packets) as the communication abstraction to help + enhance the ability of the network to make good scheduling/path + selection decisions when possible. + + - Use a naming syntax that supports a wide range of naming and + addressing conventions to enhance interoperability. + + - Use storage within the network to support store-and-forward + operation over multiple paths, and over potentially long timescales + (i.e., to support operation in environments where many and/or no + end-to-end paths may ever exist); do not require end-to-end + reliability. + + - Provide security mechanisms that protect the infrastructure from + unauthorized use by discarding traffic as quickly as possible. + + - Provide coarse-grained classes of service, delivery options, and a + way to express the useful lifetime of data to allow the network to + better deliver data in serving the needs of applications. + + The use of the bundle layer is guided not only by its own design + principles, but also by a few application design principles: + + - Applications should minimize the number of round-trip exchanges. + + - Applications should cope with restarts after failure while network + transactions remain pending. + + - Applications should inform the network of the useful life and + relative importance of data to be delivered. + + These issues are discussed in further detail in Section 5. + +3. DTN Architectural Description + + The previous section summarized the design principles that guide the + definition of the DTN architecture. This section presents a + description of the major features of the architecture resulting from + design decisions guided by the aforementioned design principles. + +3.1. Virtual Message Switching Using Store-and-Forward Operation + + A DTN-enabled application sends messages of arbitrary length, also + called Application Data Units or ADUs [CT90], which are subject to + any implementation limitations. The relative order of ADUs might not + be preserved. ADUs are typically sent by and delivered to + + + + +Cerf, et al. Informational [Page 5] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + applications in complete units, although a system interface that + behaves differently is not precluded. + + ADUs are transformed by the bundle layer into one or more protocol + data units called "bundles", which are forwarded by DTN nodes. + Bundles have a defined format containing two or more "blocks" of + data. Each block may contain either application data or other + information used to deliver the containing bundle to its + destination(s). Blocks serve the purpose of holding information + typically found in the header or payload portion of protocol data + units in other protocol architectures. The term "block" is used + instead of "header" because blocks may not appear at the beginning of + a bundle due to particular processing requirements (e.g., digital + signatures). + + Bundles may be split up ("fragmented") into multiple constituent + bundles (also called "fragments" or "bundle fragments") during + transmission. Fragments are themselves bundles, and may be further + fragmented. Two or more fragments may be reassembled anywhere in the + network, forming a new bundle. + + Bundle sources and destinations are identified by (variable-length) + Endpoint Identifiers (EIDs, described below), which identify the + original sender and final destination(s) of bundles, respectively. + Bundles also contain a "report-to" EID used when special operations + are requested to direct diagnostic output to an arbitrary entity + (e.g., other than the source). An EID may refer to one or more DTN + nodes (i.e., for multicast destinations or "report-to" destinations). + + While IP networks are based on "store-and-forward" operation, there + is an assumption that the "storing" will not persist for more than a + modest amount of time, on the order of the queuing and transmission + delay. In contrast, the DTN architecture does not expect that + network links are always available or reliable, and instead expects + that nodes may choose to store bundles for some time. We anticipate + that most DTN nodes will use some form of persistent storage for this + -- disk, flash memory, etc. -- and that stored bundles will survive + system restarts. + + Bundles contain an originating timestamp, useful life indicator, a + class of service designator, and a length. This information provides + bundle-layer routing with a priori knowledge of the size and + performance requirements of requested data transfers. When there is + a significant amount of queuing that can occur in the network (as is + the case in the DTN version of store-and-forward), the advantage + provided by knowing this information may be significant for making + scheduling and path selection decisions [JFP04]. An alternative + abstraction (i.e., of stream-based delivery based on packets) would + + + +Cerf, et al. Informational [Page 6] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + make such scheduling much more difficult. Although packets provide + some of the same benefits as bundles, larger aggregates provide a way + for the network to apply scheduling and buffer management to units of + data that are more useful to applications. + + An essential element of the bundle-based style of forwarding is that + bundles have a place to wait in a queue until a communication + opportunity ("contact") is available. This highlights the following + assumptions: + + 1. that storage is available and well-distributed throughout the + network, + + 2. that storage is sufficiently persistent and robust to store + bundles until forwarding can occur, and + + 3. (implicitly) that this "store-and-forward" model is a better + choice than attempting to effect continuous connectivity or other + alternatives. + + For a network to effectively support the DTN architecture, these + assumptions must be considered and must be found to hold. Even so, + the inclusion of long-term storage as a fundamental aspect of the DTN + architecture poses new problems, especially with respect to + congestion management and denial-of-service mitigation. Node storage + in essence represents a new resource that must be managed and + protected. Much of the research in DTN revolves around exploring + these issues. Congestion is discussed in Section 3.13, and security + mechanisms, including methods for DTN nodes to protect themselves + from handling unauthorized traffic from other nodes, are discussed in + [DTNSEC] and [DTNSOV]. + +3.2. Nodes and Endpoints + + A DTN node (or simply "node" in this document) is an engine for + sending and receiving bundles -- an implementation of the bundle + layer. Applications utilize DTN nodes to send or receive ADUs + carried in bundles (applications also use DTN nodes when acting as + report-to destinations for diagnostic information carried in + bundles). Nodes may be members of groups called "DTN endpoints". A + DTN endpoint is therefore a set of DTN nodes. A bundle is considered + to have been successfully delivered to a DTN endpoint when some + minimum subset of the nodes in the endpoint has received the bundle + without error. This subset is called the "minimum reception group" + (MRG) of the endpoint. The MRG of an endpoint may refer to one node + (unicast), one of a group of nodes (anycast), or all of a group of + nodes (multicast and broadcast). A single node may be in the MRG of + multiple endpoints. + + + +Cerf, et al. Informational [Page 7] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + +3.3. Endpoint Identifiers (EIDs) and Registrations + + An Endpoint Identifier (EID) is a name, expressed using the general + syntax of URIs (see below), that identifies a DTN endpoint. Using an + EID, a node is able to determine the MRG of the DTN endpoint named by + the EID. Each node is also required to have at least one EID that + uniquely identifies it. + + Applications send ADUs destined for an EID, and may arrange for ADUs + sent to a particular EID to be delivered to them. Depending on the + construction of the EID being used (see below), there may be a + provision for wildcarding some portion of an EID, which is often + useful for diagnostic and routing purposes. + + An application's desire to receive ADUs destined for a particular EID + is called a "registration", and in general is maintained persistently + by a DTN node. This allows application registration information to + survive application and operating system restarts. + + An application's attempt to establish a registration is not + guaranteed to succeed. For example, an application could request to + register itself to receive ADUs by specifying an Endpoint ID that is + uninterpretable or unavailable to the DTN node servicing the request. + Such requests are likely to fail. + +3.3.1. URI Schemes + + Each Endpoint ID is expressed syntactically as a Uniform Resource + Identifier (URI) [RFC3986]. The URI syntax has been designed as a + way to express names or addresses for a wide range of purposes, and + is therefore useful for constructing names for DTN endpoints. + + In URI terminology, each URI begins with a scheme name. The scheme + name is an element of the set of globally-managed scheme names + maintained by IANA [ISCHEMES]. Lexically following the scheme name + in a URI is a series of characters constrained by the syntax defined + by the scheme. This portion of the URI is called the scheme-specific + part (SSP), and can be quite general. (See, as one example, the URI + scheme for SNMP [RFC4088]). Note that scheme-specific syntactical + and semantic restrictions may be more constraining than the basic + rules of RFC 3986. Section 3.1 of RFC 3986 provides guidance on the + syntax of scheme names. + + URI schemes are a key concept in the DTN architecture, and evolved + from an earlier concept called regions, which were tied more closely + to assumptions of the network topology. Using URIs, significant + flexibility is attained in the structuring of EIDs. They might, for + example, be constructed based on DNS names, or might look like + + + +Cerf, et al. Informational [Page 8] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + "expressions of interest" or forms of database-like queries as in a + directed diffusion-routed network [IGE00] or in intentional naming + [WSBL99]. As names, EIDs are not required to be related to routing + or topological organization. Such a relationship is not prohibited, + however, and in some environments using EIDs this way may be + advantageous. + + A single EID may refer to an endpoint containing more than one DTN + node, as suggested above. It is the responsibility of a scheme + designer to define how to interpret the SSP of an EID so as to + determine whether it refers to a unicast, multicast, or anycast set + of nodes. See Section 3.4 for more details. + + URIs are constructed based on rules specified in RFC 3986, using the + US-ASCII character set. However, note this excerpt from RFC 3986, + Section 1.2.1, on dealing with characters that cannot be represented + by US-ASCII: "Percent-encoded octets (Section 2.1) may be used + within a URI to represent characters outside the range of the US- + ASCII coded character set if this representation is allowed by the + scheme or by the protocol element in which the URI is referenced. + Such a definition should specify the character encoding used to map + those characters to octets prior to being percent-encoded for the + URI". + +3.3.2. Late Binding + + Binding means interpreting the SSP of an EID for the purpose of + carrying an associated message towards a destination. For example, + binding might require mapping an EID to a next-hop EID or to a lower- + layer address for transmission. "Late binding" means that the + binding of a bundle's destination to a particular set of destination + identifiers or addresses does not necessarily happen at the bundle + source. Because the destination EID is potentially re-interpreted at + each hop, the binding may occur at the source, during transit, or + possibly at the destination(s). This contrasts with the name-to- + address binding of Internet communications where a DNS lookup at the + source fixes the IP address of the destination node before data is + sent. Such a circumstance would be considered "early binding" + because the name-to-address translation is performed prior to data + being sent into the network. + + In a frequently-disconnected network, late binding may be + advantageous because the transit time of a message may exceed the + validity time of a binding, making binding at the source impossible + or invalid. Furthermore, use of name-based routing with late binding + may reduce the amount of administrative (mapping) information that + + + + + +Cerf, et al. Informational [Page 9] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + must propagate through the network, and may also limit the scope of + mapping synchronization requirements to a local topological + neighborhood where changes are made. + +3.4. Anycast and Multicast + + As mentioned above, an EID may refer to an endpoint containing one or + more DTN nodes. When referring to a group of size greater than one, + the delivery semantics may be of either the anycast or multicast + variety (broadcast is considered to be of the multicast variety). + For anycast group delivery, a bundle is delivered to one node among a + group of potentially many nodes, and for multicast delivery it is + intended to be delivered to all of them, subject to the normal DTN + class of service and maximum useful lifetime semantics. + + Multicast group delivery in a DTN presents an unfamiliar issue with + respect to group membership. In relatively low-delay networks, such + as the Internet, nodes may be considered to be part of the group if + they have expressed interest to join it "recently". In a DTN, + however, nodes may wish to receive data sent to a group during an + interval of time earlier than when they are actually able to receive + it [ZAZ05]. More precisely, an application expresses its desire to + receive data sent to EID e at time t. Prior to this, during the + interval [t0, t1], t > t1, data may have been generated for group e. + For the application to receive any of this data, the data must be + available a potentially long time after senders have ceased sending + to the group. Thus, the data may need to be stored within the + network in order to support temporal group semantics of this kind. + How to design and implement this remains a research issue, as it is + likely to be at least as hard as problems related to reliable + multicast. + +3.5. Priority Classes + + The DTN architecture offers *relative* measures of priority (low, + medium, high) for delivering ADUs. These priorities differentiate + traffic based upon an application's desire to affect the delivery + urgency for ADUs, and are carried in bundle blocks generated by the + bundle layer based on information specified by the application. + + The (U.S. or similar) Postal Service provides a strong metaphor for + the priority classes offered by the forwarding abstraction offered by + the DTN architecture. Traffic is generally not interactive and is + often one-way. There are generally no strong guarantees of timely + delivery, yet there are some forms of class of service, reliability, + and security. + + + + + +Cerf, et al. Informational [Page 10] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + We have defined three relative priority classes to date. These + priority classes typically imply some relative scheduling + prioritization among bundles in queue at a sender: + + - Bulk - Bulk bundles are shipped on a "least effort" basis. No + bundles of this class will be shipped until all bundles of other + classes bound for the same destination and originating from the + same source have been shipped. + + - Normal - Normal-class bundles are shipped prior to any bulk-class + bundles and are otherwise the same as bulk bundles. + + - Expedited - Expedited bundles, in general, are shipped prior to + bundles of other classes and are otherwise the same. + + Applications specify their requested priority class and data lifetime + (see below) for each ADU they send. This information, coupled with + policy applied at DTN nodes that select how messages are forwarded + and which routing algorithms are in use, affects the overall + likelihood and timeliness of ADU delivery. + + The priority class of a bundle is only required to relate to other + bundles from the same source. This means that a high priority bundle + from one source may not be delivered faster (or with some other + superior quality of service) than a medium priority bundle from a + different source. It does mean that a high priority bundle from one + source will be handled preferentially to a lower priority bundle sent + from the same source. + + Depending on a particular DTN node's forwarding/scheduling policy, + priority may or may not be enforced across different sources. That + is, in some DTN nodes, expedited bundles might always be sent prior + to any bulk bundles, irrespective of source. Many variations are + possible. + +3.6. Postal-Style Delivery Options and Administrative Records + + Continuing with the postal analogy, the DTN architecture supports + several delivery options that may be selected by an application when + it requests the transmission of an ADU. In addition, the + architecture defines two types of administrative records: "status + reports" and "signals". These records are bundles that provide + information about the delivery of other bundles, and are used in + conjunction with the delivery options. + + + + + + + +Cerf, et al. Informational [Page 11] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + +3.6.1. Delivery Options + + We have defined eight delivery options. Applications sending an ADU + (the "subject ADU") may request any combination of the following, + which are carried in each of the bundles produced ("sent bundles") by + the bundle layer resulting from the application's request to send the + subject ADU: + + - Custody Transfer Requested - requests sent bundles be delivered + with enhanced reliability using custody transfer procedures. Sent + bundles will be transmitted by the bundle layer using reliable + transfer protocols (if available), and the responsibility for + reliable delivery of the bundle to its destination(s) may move + among one or more "custodians" in the network. This capability is + described in more detail in Section 3.10. + + - Source Node Custody Acceptance Required - requires the source DTN + node to provide custody transfer for the sent bundles. If custody + transfer is not available at the source when this delivery option + is requested, the requested transmission fails. This provides a + means for applications to insist that the source DTN node take + custody of the sent bundles (e.g., by storing them in persistent + storage). + + - Report When Bundle Delivered - requests a (single) Bundle Delivery + Status Report be generated when the subject ADU is delivered to its + intended recipient(s). This request is also known as "return- + receipt". + + - Report When Bundle Acknowledged by Application - requests an + Acknowledgement Status Report be generated when the subject ADU is + acknowledged by a receiving application. This only happens by + action of the receiving application, and differs from the Bundle + Delivery Status Report. It is intended for cases where the + application may be acting as a form of application layer gateway + and wishes to indicate the status of a protocol operation external + to DTN back to the requesting source. See Section 11 for more + details. + + - Report When Bundle Received - requests a Bundle Reception Status + Report be generated when each sent bundle arrives at a DTN node. + This is designed primarily for diagnostic purposes. + + - Report When Bundle Custody Accepted - requests a Custody + Acceptance Status Report be generated when each sent bundle has + been accepted using custody transfer. This is designed primarily + for diagnostic purposes. + + + + +Cerf, et al. Informational [Page 12] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + - Report When Bundle Forwarded - requests a Bundle Forwarding Status + Report be generated when each sent bundle departs a DTN node after + forwarding. This is designed primarily for diagnostic purposes. + + - Report When Bundle Deleted - requests a Bundle Deletion Status + Report be generated when each sent bundle is deleted at a DTN node. + This is designed primarily for diagnostic purposes. + + The first four delivery options are designed for ordinary use by + applications. The last four are designed primarily for diagnostic + purposes and their use may be restricted or limited in environments + subject to congestion or attack. + + If the security procedures defined in [DTNSEC] are also enabled, then + three additional delivery options become available: + + - Confidentiality Required - requires the subject ADU be made secret + from parties other than the source and the members of the + destination EID. + + - Authentication Required - requires all non-mutable fields in the + bundle blocks of the sent bundles (i.e., those which do not change + as the bundle is forwarded) be made strongly verifiable (i.e., + cryptographically strong). This protects several fields, including + the source and destination EIDs and the bundle's data. See Section + 3.7 and [BSPEC] for more details. + + - Error Detection Required - requires modifications to the non- + mutable fields of each sent bundle be made detectable with high + probability at each destination. + +3.6.2. Administrative Records: Bundle Status Reports and Custody + Signals + + Administrative records are used to report status information or error + conditions related to the bundle layer. There are two types of + administrative records defined: bundle status reports (BSRs) and + custody signals. Administrative records correspond (approximately) + to messages in the ICMP protocol in IP [RFC792]. In ICMP, however, + messages are returned to the source. In DTN, they are instead + directed to the report-to EID for BSRs and the EID of the current + custodian for custody signals, which might differ from the source's + EID. Administrative records are sent as bundles with a source EID + set to one of the EIDs associated with the DTN node generating the + administrative record. In some cases, arrival of a single bundle or + bundle fragment may elicit multiple administrative records (e.g., in + the case where a bundle is replicated for multicast forwarding). + + + + +Cerf, et al. Informational [Page 13] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + The following BSRs are currently defined (also see [BSPEC] for more + details): + + - Bundle Reception - sent when a bundle arrives at a DTN node. + Generation of this message may be limited by local policy. + + - Custody Acceptance - sent when a node has accepted custody of a + bundle with the Custody Transfer Requested option set. Generation + of this message may be limited by local policy. + + - Bundle Forwarded - sent when a bundle containing a Report When + Bundle Forwarded option departs from a DTN node after having been + forwarded. Generation of this message may be limited by local + policy. + + - Bundle Deletion - sent from a DTN node when a bundle containing a + Report When Bundle Deleted option is discarded. This can happen + for several reasons, such as expiration. Generation of this + message may be limited by local policy but is required in cases + where the deletion is performed by a bundle's current custodian. + + - Bundle Delivery - sent from a final recipient's (destination) node + when a complete ADU comprising sent bundles containing Report When + Bundle Delivered options is consumed by an application. + + - Acknowledged by application - sent from a final recipient's + (destination) node when a complete ADU comprising sent bundles + containing Application Acknowledgment options has been processed by + an application. This generally involves specific action on the + receiving application's part. + + In addition to the status reports, the custody signal is currently + defined to indicate the status of a custody transfer. These are sent + to the current-custodian EID contained in an arriving bundle: + + - Custody Signal - indicates that custody has been successfully + transferred. This signal appears as a Boolean indicator, and may + therefore indicate either a successful or a failed custody transfer + attempt. + + Administrative records must reference a received bundle. This is + accomplished by a method for uniquely identifying bundles based on a + transmission timestamp and sequence number discussed in Section 3.12. + + + + + + + + +Cerf, et al. Informational [Page 14] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + +3.7. Primary Bundle Fields + + The bundles carried between and among DTN nodes obey a standard + bundle protocol specified in [BSPEC]. Here we provide an overview of + most of the fields carried with every bundle. The protocol is + designed with a mandatory primary block, an optional payload block + (which contains the ADU data itself), and a set of optional extension + blocks. Blocks may be cascaded in a way similar to extension headers + in IPv6. The following selected fields are all present in the + primary block, and therefore are present for every bundle and + fragment: + + - Creation Timestamp - a concatenation of the bundle's creation time + and a monotonically increasing sequence number such that the + creation timestamp is guaranteed to be unique for each ADU + originating from the same source. The creation timestamp is based + on the time-of-day an application requested an ADU to be sent (not + when the corresponding bundle(s) are sent into the network). DTN + nodes are assumed to have a basic time synchronization capability + (see Section 3.12). + + - Lifespan - the time-of-day at which the message is no longer + useful. If a bundle is stored in the network (including the + source's DTN node) when its lifespan is reached, it may be + discarded. The lifespan of a bundle is expressed as an offset + relative to its creation time. + + - Class of Service Flags - indicates the delivery options and + priority class for the bundle. Priority classes may be one of + bulk, normal, or expedited. See Section 3.6.1. + + - Source EID - EID of the source (the first sender). + + - Destination EID - EID of the destination (the final intended + recipient(s)). + + - Report-To Endpoint ID - an EID identifying where reports (return- + receipt, route-tracing functions) should be sent. This may or may + not identify the same endpoint as the Source EID. + + - Custodian EID - EID of the current custodian of a bundle (if any). + + The payload block indicates information about the contained payload + (e.g., its length) and the payload itself. In addition to the fields + found in the primary and payload blocks, each bundle may have fields + in additional blocks carried with each bundle. See [BSPEC] for + additional details. + + + + +Cerf, et al. Informational [Page 15] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + +3.8. Routing and Forwarding + + The DTN architecture provides a framework for routing and forwarding + at the bundle layer for unicast, anycast, and multicast messages. + Because nodes in a DTN network might be interconnected using more + than one type of underlying network technology, a DTN network is best + described abstractly using a *multigraph* (a graph where vertices may + be interconnected with more than one edge). Edges in this graph are, + in general, time-varying with respect to their delay and capacity and + directional because of the possibility of one-way connectivity. When + an edge has zero capacity, it is considered to not be connected. + + Because edges in a DTN graph may have significant delay, it is + important to distinguish where time is measured when expressing an + edge's capacity or delay. We adopt the convention of expressing + capacity and delay as functions of time where time is measured at the + point where data is inserted into a network edge. For example, + consider an edge having capacity C(t) and delay D(t) at time t. If B + bits are placed in this edge at time t, they completely arrive by + time t + D(t) + (1/C(t))*B. We assume C(t) and D(t) do not change + significantly during the interval [t, t+D(t)+(1/C(t))*B]. + + Because edges may vary between positive and zero capacity, it is + possible to describe a period of time (interval) during which the + capacity is strictly positive, and the delay and capacity can be + considered to be constant [AF03]. This period of time is called a + "contact". In addition, the product of the capacity and the interval + is known as a contact's "volume". If contacts and their volumes are + known ahead of time, intelligent routing and forwarding decisions can + be made (optimally for small networks) [JFP04]. Optimally using a + contact's volume, however, requires the ability to divide large ADUs + and bundles into smaller routable units. This is provided by DTN + fragmentation (see Section 3.9). + + When delivery paths through a DTN graph are lossy or contact + intervals and volumes are not known precisely ahead of time, routing + computations become especially challenging. How to handle these + situations is an active area of work in the (emerging) research area + of delay tolerant networking. + +3.8.1. Types of Contacts + + Contacts typically fall into one of several categories, based largely + on the predictability of their performance characteristics and + whether some action is required to bring them into existence. To + date, the following major types of contacts have been defined: + + + + + +Cerf, et al. Informational [Page 16] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + Persistent Contacts + + Persistent contacts are always available (i.e., no connection- + initiation action is required to instantiate a persistent + contact). An 'always-on' Internet connection such as a DSL or + Cable Modem connection would be a representative of this class. + + On-Demand Contacts + + On-Demand contacts require some action in order to instantiate, + but then function as persistent contacts until terminated. A + dial-up connection is an example of an On-Demand contact (at + least, from the viewpoint of the dialer; it may be viewed as an + Opportunistic Contact, below, from the viewpoint of the dial-up + service provider). + + Intermittent - Scheduled Contacts + + A scheduled contact is an agreement to establish a contact at a + particular time, for a particular duration. An example of a + scheduled contact is a link with a low-earth orbiting satellite. + A node's list of contacts with the satellite can be constructed + from the satellite's schedule of view times, capacities, and + latencies. Note that for networks with substantial delays, the + notion of the "particular time" is delay-dependent. For example, + a single scheduled contact between Earth and Mars would not be at + the same instant in each location, but would instead be offset by + the (non-negligible) propagation delay. + + Intermittent - Opportunistic Contacts + + Opportunistic contacts are not scheduled, but rather present + themselves unexpectedly. For example, an unscheduled aircraft + flying overhead and beaconing, advertising its availability for + communication, would present an opportunistic contact. Another + type of opportunistic contact might be via an infrared or + Bluetooth communication link between a personal digital assistant + (PDA) and a kiosk in an airport concourse. The opportunistic + contact begins as the PDA is brought near the kiosk, lasting an + undetermined amount of time (i.e., until the link is lost or + terminated). + + Intermittent - Predicted Contacts + + Predicted contacts are based on no fixed schedule, but rather are + predictions of likely contact times and durations based on a + history of previously observed contacts or some other information. + Given a great enough confidence in a predicted contact, routes may + + + +Cerf, et al. Informational [Page 17] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + be chosen based on this information. This is an active research + area, and a few approaches having been proposed [LFC05]. + +3.9. Fragmentation and Reassembly + + DTN fragmentation and reassembly are designed to improve the + efficiency of bundle transfers by ensuring that contact volumes are + fully utilized and by avoiding retransmission of partially-forwarded + bundles. There are two forms of DTN fragmentation/reassembly: + + Proactive Fragmentation + + A DTN node may divide a block of application data into multiple + smaller blocks and transmit each such block as an independent + bundle. In this case, the *final destination(s)* are responsible + for extracting the smaller blocks from incoming bundles and + reassembling them into the original larger bundle and, ultimately, + ADU. This approach is called proactive fragmentation because it + is used primarily when contact volumes are known (or predicted) in + advance. + + Reactive Fragmentation + + DTN nodes sharing an edge in the DTN graph may fragment a bundle + cooperatively when a bundle is only partially transferred. In + this case, the receiving bundle layer modifies the incoming bundle + to indicate it is a fragment, and forwards it normally. The + previous- hop sender may learn (via convergence-layer protocols, + see Section 6) that only a portion of the bundle was delivered to + the next hop, and send the remaining portion(s) when subsequent + contacts become available (possibly to different next-hops if + routing changes). This is called reactive fragmentation because + the fragmentation process occurs after an attempted transmission + has taken place. + + As an example, consider a ground station G, and two store-and- + forward satellites S1 and S2, in opposite low-earth orbit. While + G is transmitting a large bundle to S1, a reliable transport layer + protocol below the bundle layer at each indicates the transmission + has terminated, but that half the transfer has completed + successfully. In this case, G can form a smaller bundle fragment + consisting of the second half of the original bundle and forward + it to S2 when available. In addition, S1 (now out of range of G) + can form a new bundle consisting of the first half of the original + bundle and forward it to whatever next hop(s) it deems + appropriate. + + + + + +Cerf, et al. Informational [Page 18] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + The reactive fragmentation capability is not required to be available + in every DTN implementation, as it requires a certain level of + support from underlying protocols that may not be present, and + presents significant challenges with respect to handling digital + signatures and authentication codes on messages. When a signed + message is only partially received, most message authentication codes + will fail. When DTN security is present and enabled, it may + therefore be necessary to proactively fragment large bundles into + smaller units that are more convenient for digital signatures. + + Even if reactive fragmentation is not present in an implementation, + the ability to reassemble fragments at a destination is required in + order to support DTN fragmentation. Furthermore, for contacts with + volumes that are small compared to typical bundle sizes, some + incremental delivery approach must be used (e.g., checkpoint/restart) + to prevent data delivery livelock. Reactive fragmentation is one + such approach, but other protocol layers could potentially handle + this issue as well. + +3.10. Reliability and Custody Transfer + + The most basic service provided by the bundle layer is + unacknowledged, prioritized (but not guaranteed) unicast message + delivery. It also provides two options for enhancing delivery + reliability: end-to-end acknowledgments and custody transfer. + Applications wishing to implement their own end-to-end message + reliability mechanisms are free to utilize the acknowledgment. The + custody transfer feature of the DTN architecture only specifies a + coarse-grained retransmission capability, described next. + + Transmission of bundles with the Custody Transfer Requested option + specified generally involves moving the responsibility for reliable + delivery of an ADU's bundles among different DTN nodes in the + network. For unicast delivery, this will typically involve moving + bundles "closer" (in terms of some routing metric) to their ultimate + destination(s), and retransmitting when necessary. The nodes + receiving these bundles along the way (and agreeing to accept the + reliable delivery responsibility) are called "custodians". The + movement of a bundle (and its delivery responsibility) from one node + to another is called a "custody transfer". It is analogous to a + database commit transaction [FHM03]. The exact meaning and design of + custody transfer for multicast and anycast delivery remains to be + fully explored. + + Custody transfer allows the source to delegate retransmission + responsibility and recover its retransmission-related resources + relatively soon after sending a bundle (on the order of the minimum + round-trip time to the first bundle hop(s)). Not all nodes in a DTN + + + +Cerf, et al. Informational [Page 19] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + are required by the DTN architecture to accept custody transfers, so + it is not a true 'hop-by-hop' mechanism. For example, some nodes may + have sufficient storage resources to sometimes act as custodians, but + may elect to not offer such services when congested or running low on + power. + + The existence of custodians can alter the way DTN routing is + performed. In some circumstances, it may be beneficial to move a + bundle to a custodian as quickly as possible even if the custodian is + further away (in terms of distance, time or some routing metric) from + the bundle's final destination(s) than some other reachable node. + Designing a system with this capability involves constructing more + than one routing graph, and is an area of continued research. + + Custody transfer in DTN not only provides a method for tracking + bundles that require special handling and identifying DTN nodes that + participate in custody transfer, it also provides a (weak) mechanism + for enhancing the reliability of message delivery. Generally + speaking, custody transfer relies on underlying reliable delivery + protocols of the networks that it operates over to provide the + primary means of reliable transfer from one bundle node to the next + (set). However, when custody transfer is requested, the bundle layer + provides an additional coarse-grained timeout and retransmission + mechanism and an accompanying (bundle-layer) custodian-to-custodian + acknowledgment signaling mechanism. When an application does *not* + request custody transfer, this bundle layer timeout and + retransmission mechanism is typically not employed, and successful + bundle layer delivery depends solely on the reliability mechanisms of + the underlying protocols. + + When a node accepts custody for a bundle that contains the Custody + Transfer Requested option, a Custody Transfer Accepted Signal is sent + by the bundle layer to the Current Custodian EID contained in the + primary bundle block. In addition, the Current Custodian EID is + updated to contain one of the forwarding node's (unicast) EIDs before + the bundle is forwarded. + + When an application requests an ADU to be delivered with custody + transfer, the request is advisory. In some circumstances, a source + of a bundle for which custody transfer has been requested may not be + able to provide this service. In such circumstances, the subject + bundle may traverse multiple DTN nodes before it obtains a custodian. + Bundles in this condition are specially marked with their Current + Custodian EID field set to a null endpoint. In cases where + applications wish to require the source to take custody of the + bundle, they may supply the Source Node Custody Acceptance Required + + + + + +Cerf, et al. Informational [Page 20] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + delivery option. This may be useful to applications that desire a + continuous "chain" of custody or that wish to exit after being + ensured their data is safely held in a custodian. + + In a DTN network where one or more custodian-to-custodian hops are + strictly one directional (and cannot be reversed), the DTN custody + transfer mechanism will be affected over such hops due to the lack of + any way to receive a custody signal (or any other information) back + across the path, resulting in the expiration of the bundle at the + ingress to the one-way hop. This situation does not necessarily mean + the bundle has been lost; nodes on the other side of the hop may + continue to transfer custody, and the bundle may be delivered + successfully to its destination(s). However, in this circumstance a + source that has requested to receive expiration BSRs for this bundle + will receive an expiration report for the bundle, and possibly + conclude (incorrectly) that the bundle has been discarded and not + delivered. Although this problem cannot be fully solved in this + situation, a mechanism is provided to help ameliorate the seemingly + incorrect information that may be reported when the bundle expires + after having been transferred over a one-way hop. This is + accomplished by the node at the ingress to the one-way hop reporting + the existence of a known one-way path using a variant of a bundle + status report. These types of reports are provided if the subject + bundle requests the report using the 'Report When Bundle Forwarded' + delivery option. + +3.11. DTN Support for Proxies and Application Layer Gateways + + One of the aims of DTN is to provide a common method for + interconnecting application layer gateways and proxies. In cases + where existing Internet applications can be made to tolerate delays, + local proxies can be constructed to benefit from the existing + communication capabilities provided by DTN [S05, T02]. Making such + proxies compatible with DTN reduces the burden on the proxy author + from being concerned with how to implement routing and reliability + management and allows existing TCP/IP-based applications to operate + unmodified over a DTN-based network. + + When DTN is used to provide a form of tunnel encapsulation for other + protocols, it can be used in constructing overlay networks comprised + of application layer gateways. The application acknowledgment + capability is designed for such circumstances. This provides a + common way for remote application layer gateways to signal the + success or failure of non-DTN protocol operations initiated as a + result of receiving DTN ADUs. Without this capability, such + indicators would have to be implemented by applications themselves in + non-standard ways. + + + + +Cerf, et al. Informational [Page 21] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + +3.12. Timestamps and Time Synchronization + + The DTN architecture depends on time synchronization among DTN nodes + (supported by external, non-DTN protocols) for four primary purposes: + bundle and fragment identification, routing with scheduled or + predicted contacts, bundle expiration time computations, and + application registration expiration. + + Bundle identification and expiration are supported by placing a + creation timestamp and an explicit expiration field (expressed in + seconds after the source timestamp) in each bundle. The origination + timestamps on arriving bundles are made available to consuming + applications in ADUs they receive by some system interface function. + Each set of bundles corresponding to an ADU is required to contain a + timestamp unique to the sender's EID. The EID, timestamp, and data + offset/length information together uniquely identify a bundle. + Unique bundle identification is used for a number of purposes, + including custody transfer and reassembly of bundle fragments. + + Time is also used in conjunction with application registrations. + When an application expresses its desire to receive ADUs destined for + a particular EID, this registration is only maintained for a finite + period of time, and may be specified by the application. For + multicast registrations, an application may also specify a time range + or "interest interval" for its registration. In this case, traffic + sent to the specified EID any time during the specified interval will + eventually be delivered to the application (unless such traffic has + expired due to the expiration time provided by the application at the + source or some other reason prevents such delivery). + +3.13. Congestion and Flow Control at the Bundle Layer + + The subject of congestion control and flow control at the bundle + layer is one on which the authors of this document have not yet + reached complete consensus. We have unresolved concerns about the + efficiency and efficacy of congestion and flow control schemes + implemented across long and/or highly variable delay environments, + especially with the custody transfer mechanism that may require nodes + to retain bundles for long periods of time. + + For the purposes of this document, we define "flow control" as a + means of assuring that the average rate at which a sending node + transmits data to a receiving node does not exceed the average rate + at which the receiving node is prepared to receive data from that + sender. (Note that this is a generalized notion of flow control, + rather than one that applies only to end-to-end communication.) We + define "congestion control" as a means of assuring that the aggregate + rate at which all traffic sources inject data into a network does not + + + +Cerf, et al. Informational [Page 22] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + exceed the maximum aggregate rate at which the network can deliver + data to destination nodes over time. If flow control is propagated + backward from congested nodes toward traffic sources, then the flow + control mechanism can be used as at least a partial solution to the + problem of congestion as well. + + DTN flow control decisions must be made within the bundle layer + itself based on information about resources (in this case, primarily + persistent storage) available within the bundle node. When storage + resources become scarce, a DTN node has only a certain degree of + freedom in handling the situation. It can always discard bundles + which have expired -- an activity DTN nodes should perform regularly + in any case. If it ordinarily is willing to accept custody for + bundles, it can cease doing so. If storage resources are available + elsewhere in the network, it may be able to make use of them in some + way for bundle storage. It can also discard bundles which have not + expired but for which it has not accepted custody. A node must avoid + discarding bundles for which it has accepted custody, and do so only + as a last resort. Determining when a node should engage in or cease + to engage in custody transfers is a resource allocation and + scheduling problem of current research interest. + + In addition to the bundle layer mechanisms described above, a DTN + node may be able to avail itself of support from lower-layer + protocols in affecting its own resource utilization. For example, a + DTN node receiving a bundle using TCP/IP might intentionally slow + down its receiving rate by performing read operations less frequently + in order to reduce its offered load. This is possible because TCP + provides its own flow control, so reducing the application data + consumption rate could effectively implement a form of hop-by-hop + flow control. Unfortunately, it may also lead to head-of-line + blocking issues, depending on the nature of bundle multiplexing + within a TCP connection. A protocol with more relaxed ordering + constraints (e.g. SCTP [RFC2960]) might be preferable in such + circumstances. + + Congestion control is an ongoing research topic. + +3.14. Security + + The possibility of severe resource scarcity in some delay-tolerant + networks dictates that some form of authentication and access control + to the network itself is required in many circumstances. It is not + acceptable for an unauthorized user to flood the network with traffic + easily, possibly denying service to authorized users. In many cases + it is also not acceptable for unauthorized traffic to be forwarded + over certain network links at all. This is especially true for + exotic, mission-critical links. In light of these considerations, + + + +Cerf, et al. Informational [Page 23] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + several goals are established for the security component of the DTN + architecture: + + - Promptly prevent unauthorized applications from having their data + carried through or stored in the DTN. + + - Prevent unauthorized applications from asserting control over the + DTN infrastructure. + + - Prevent otherwise authorized applications from sending bundles at a + rate or class of service for which they lack permission. + + - Promptly discard bundles that are damaged or improperly modified in + transit. + + - Promptly detect and de-authorize compromised entities. + + Many existing authentication and access control protocols designed + for operation in low-delay, connected environments may not perform + well in DTNs. In particular, updating access control lists and + revoking ("blacklisting") credentials may be especially difficult. + Also, approaches that require frequent access to centralized servers + to complete an authentication or authorization transaction are not + attractive. The consequences of these difficulties include delays in + the onset of communication, delays in detecting and recovering from + system compromise, and delays in completing transactions due to + inappropriate access control or authentication settings. + + To help satisfy these security requirements in light of the + challenges, the DTN architecture adopts a standard but optionally + deployed security architecture [DTNSEC] that utilizes hop-by-hop and + end-to-end authentication and integrity mechanisms. The purpose of + using both approaches is to be able to handle access control for data + forwarding and storage separately from application-layer data + integrity. While the end-to-end mechanism provides authentication + for a principal such as a user (of which there may be many), the hop- + by-hop mechanism is intended to authenticate DTN nodes as legitimate + transceivers of bundles to each-other. Note that it is conceivable + to construct a DTN in which only a subset of the nodes participate in + the security mechanisms, resulting in a secure DTN overlay existing + atop an insecure DTN overlay. This idea is relatively new and is + still being explored. + + In accordance with the goals listed above, DTN nodes discard traffic + as early as possible if authentication or access control checks fail. + This approach meets the goals of removing unwanted traffic from being + forwarded over specific high-value links, but also has the associated + benefit of making denial-of-service attacks considerably harder to + + + +Cerf, et al. Informational [Page 24] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + mount more generally, as compared with conventional Internet routers. + However, the obvious cost for this capability is potentially larger + computation and credential storage overhead required at DTN nodes. + + For more detailed information on DTN security provisions, refer to + [DTNSEC] and [DTNSOV]. + +4. State Management Considerations + + An important aspect of any networking architecture is its management + of state. This section describes the state managed at the bundle + layer and discusses how it is established and removed. + +4.1. Application Registration State + + In long/variable delay environments, an asynchronous application + interface seems most appropriate. Such interfaces typically include + methods for applications to register callback actions when certain + triggering events occur (e.g., when ADUs arrive). These + registrations create state information called application + registration state. + + Application registration state is typically created by explicit + request of the application, and is removed by a separate explicit + request, but may also be removed by an application-specified timer + (it is thus "firm" state). In most cases, there must be a provision + for retaining this state across application and operating system + termination/restart conditions because a client/server bundle round- + trip time may exceed the requesting application's execution time (or + hosting system's uptime). In cases where applications are not + automatically restarted but application registration state remains + persistent, a method must be provided to indicate to the system what + action to perform when the triggering event occurs (e.g., restarting + some application, ignoring the event, etc.). + + To initiate a registration and thereby establish application + registration state, an application specifies an Endpoint ID for which + it wishes to receive ADUs, along with an optional time value + indicating how long the registration should remain active. This + operation is somewhat analogous to the bind() operation in the common + sockets API. + + For registrations to groups (i.e., joins), a time interval may also + be specified. The time interval refers to the range of origination + times of ADUs sent to the specified EID. See Section 3.4 above for + more details. + + + + + +Cerf, et al. Informational [Page 25] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + +4.2. Custody Transfer State + + Custody transfer state includes information required to keep account + of bundles for which a node has taken custody, as well as the + protocol state related to transferring custody for one or more of + them. The accounting-related state is created when a bundle is + received. Custody transfer retransmission state is created when a + transfer of custody is initiated by forwarding a bundle with the + custody transfer requested delivery option specified. Retransmission + state and accounting state may be released upon receipt of one or + more Custody Transfer Succeeded signals, indicating custody has been + moved. In addition, the bundle's expiration time (possibly mitigated + by local policy) provides an upper bound on the time when this state + is purged from the system in the event that it is not purged + explicitly due to receipt of a signal. + +4.3. Bundle Routing and Forwarding State + + As with the Internet architecture, we distinguish between routing and + forwarding. Routing refers to the execution of a (possibly + distributed) algorithm for computing routing paths according to some + objective function (see [JFP04], for example). Forwarding refers to + the act of moving a bundle from one DTN node to another. Routing + makes use of routing state (the RIB, or routing information base), + while forwarding makes use of state derived from routing, and is + maintained as forwarding state (the FIB, or forwarding information + base). The structure of the FIB and the rules for maintaining it are + implementation choices. In some DTNs, exchange of information used + to update state in the RIB may take place on network paths distinct + from those where exchange of application data takes place. + + The maintenance of state in the RIB is dependent on the type of + routing algorithm being used. A routing algorithm may consider + requested class of service and the location of potential custodians + (for custody transfer, see section 3.10), and this information will + tend to increase the size of the RIB. The separation between FIB and + RIB is not required by this document, as these are implementation + details to be decided by system implementers. The choice of routing + algorithms is still under study. + + Bundles may occupy queues in nodes for a considerable amount of time. + For unicast or anycast delivery, the amount of time is likely to be + the interval between when a bundle arrives at a node and when it can + be forwarded to its next hop. For multicast delivery of bundles, + this could be significantly longer, up to a bundle's expiration time. + This situation occurs when multicast delivery is utilized in such a + way that nodes joining a group can obtain information previously sent + to the group. In such cases, some nodes may act as "archivers" that + + + +Cerf, et al. Informational [Page 26] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + provide copies of bundles to new participants that have already been + delivered to other participants. + +4.4. Security-Related State + + The DTN security approach described in [DTNSEC], when used, requires + maintenance of state in all DTN nodes that use it. All such nodes + are required to store their own private information (including their + own policy and authentication material) and a block of information + used to verify credentials. Furthermore, in most cases, DTN nodes + will cache some public information (and possibly the credentials) of + their next-hop (bundle) neighbors. All cached information has + expiration times, and nodes are responsible for acquiring and + distributing updates of public information and credentials prior to + the expiration of the old set (in order to avoid a disruption in + network service). + + In addition to basic end-to-end and hop-by-hop authentication, access + control may be used in a DTN by one or more mechanisms such as + capabilities or access control lists (ACLs). ACLs would represent + another block of state present in any node that wishes to enforce + security policy. ACLs are typically initialized at node + configuration time and may be updated dynamically by DTN bundles or + by some out of band technique. Capabilities or credentials may be + revoked, requiring the maintenance of a revocation list ("black + list", another form of state) to check for invalid authentication + material that has already been distributed. + + Some DTNs may implement security boundaries enforced by selected + nodes in the network, where end-to-end credentials may be checked in + addition to checking the hop-by-hop credentials. (Doing so may + require routing to be adjusted to ensure all bundles comprising each + ADU pass through these points.) Public information used to verify + end-to-end authentication will typically be cached at these points. + +4.5. Policy and Configuration State + + DTN nodes will contain some amount of configuration and policy + information. Such information may alter the behavior of bundle + forwarding. Examples of policy state include the types of + cryptographic algorithms and access control procedures to use if DTN + security is employed, whether nodes may become custodians, what types + of convergence layer (see Section 6) and routing protocols are in + use, how bundles of differing priorities should be scheduled, where + and for how long bundles and other data is stored, what status + reports may be generated or at what rate, etc. + + + + + +Cerf, et al. Informational [Page 27] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + +5. Application Structuring Issues + + DTN bundle delivery is intended to operate in a delay-tolerant + fashion over a broad range of network types. This does not mean + there *must* be large delays in the network; it means there *may* be + very significant delays (including extended periods of disconnection + between sender and intended recipient(s)). The DTN protocols are + delay tolerant, so applications using them must also be delay + tolerant in order to operate effectively in environments subject to + significant delay or disruption. + + The communication primitives provided by the DTN architecture are + based on asynchronous, message-oriented communication which differs + from conversational request/response communication. In general, + applications should attempt to include enough information in an ADU + so that it may be treated as an independent unit of work by the + network and receiver(s). The goal is to minimize synchronous + interchanges between applications that are separated by a network + characterized by long and possibly highly variable delays. A single + file transfer request message, for example, might include + authentication information, file location information, and requested + file operation (thus "bundling" this information together). + Comparing this style of operation to a classic FTP transfer, one sees + that the bundled model can complete in one round trip, whereas an FTP + file "put" operation can take as many as eight round trips to get to + a point where file data can flow [DFS02]. + + Delay-tolerant applications must consider additional factors beyond + the conversational implications of long delay paths. For example, an + application may terminate (voluntarily or not) between the time it + sends a message and the time it expects a response. If this + possibility has been anticipated, the application can be "re- + instantiated" with state information saved in persistent storage. + This is an implementation issue, but also an application design + consideration. + + Some consideration of delay-tolerant application design can result in + applications that work reasonably well in low-delay environments, and + that do not suffer extraordinarily in high or highly-variable delay + environments. + +6. Convergence Layer Considerations for Use of Underlying Protocols + + Implementation experience with the DTN architecture has revealed an + important architectural construct and interface for DTN nodes + [DBFJHP04]. Not all underlying protocols in different protocol + families provide the same exact functionality, so some additional + adaptation or augmentation on a per-protocol or per-protocol-family + + + +Cerf, et al. Informational [Page 28] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + basis may be required. This adaptation is accomplished by a set of + convergence layers placed between the bundle layer and underlying + protocols. The convergence layers manage the protocol-specific + details of interfacing with particular underlying protocols and + present a consistent interface to the bundle layer. + + The complexity of one convergence layer may vary substantially from + another, depending on the type of underlying protocol it adapts. For + example, a TCP/IP convergence layer for use in the Internet might + only have to add message boundaries to TCP streams, whereas a + convergence layer for some network where no reliable transport + protocol exists might be considerably more complex (e.g., it might + have to implement reliability, fragmentation, flow-control, etc.) if + reliable delivery is to be offered to the bundle layer. + + As convergence layers implement protocols above and beyond the basic + bundle protocol specified in [BSPEC], they will be defined in their + own documents (in a fashion similar to the way encapsulations for IP + datagrams are specified on a per-underlying-protocol basis, such as + in RFC 894 [RFC894]). + +7. Summary + + The DTN architecture addresses many of the problems of heterogeneous + networks that must operate in environments subject to long delays and + discontinuous end-to-end connectivity. It is based on asynchronous + messaging and uses postal mail as a model of service classes and + delivery semantics. It accommodates many different forms of + connectivity, including scheduled, predicted, and opportunistically + connected delivery paths. It introduces a novel approach to end-to- + end reliability across frequently partitioned and unreliable + networks. It also proposes a model for securing the network + infrastructure against unauthorized access. + + It is our belief that this architecture is applicable to many + different types of challenged environments. + +8. Security Considerations + + Security is an integral concern for the design of the Delay Tolerant + Network Architecture, but its use is optional. Sections 3.6.1, 3.14, + and 4.4 of this document present some factors to consider for + securing the DTN architecture, but separate documents [DTNSOV] and + [DTNSEC] define the security architecture in much more detail. + + + + + + + +Cerf, et al. Informational [Page 29] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + +9. IANA Considerations + + This document specifies the architecture for Delay Tolerant + Networking, which uses Internet-standard URIs for its Endpoint + Identifiers. URIs intended for use with DTN should be compliant with + the guidelines given in [RFC3986]. + +10. Normative References + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. + +11. Informative References + + [IPN01] InterPlaNetary Internet Project, Internet Society IPN + Special Interest Group, http://www.ipnsig.org. + + [SB03] S. Burleigh, et al., "Delay-Tolerant Networking - An + Approach to Interplanetary Internet", IEEE Communications + Magazine, July 2003. + + [FW03] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial + v1.1", Wartham Associates, 2003. Available from + http://www.dtnrg.org. + + [KF03] K. Fall, "A Delay-Tolerant Network Architecture for + Challenged Internets", Proceedings SIGCOMM, Aug 2003. + + [JFP04] S. Jain, K. Fall, R. Patra, "Routing in a Delay Tolerant + Network", Proceedings SIGCOMM, Aug/Sep 2004. + + [DFS02] R. Durst, P. Feighery, K. Scott, "Why not use the + Standard Internet Suite for the Interplanetary + Internet?", MITRE White Paper, 2002. Available from + http://www.ipnsig.org/reports/TCP_IP.pdf. + + [CK74] V. Cerf, R. Kahn, "A Protocol for Packet Network + Intercommunication", IEEE Trans. on Comm., COM-22(5), May + 1974. + + [IGE00] C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed + Diffusion: A Scalable and Robust Communication Paradigm + for Sensor Networks", Proceedings MobiCOM, Aug 2000. + + + + + + + +Cerf, et al. Informational [Page 30] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + [WSBL99] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, J. Lilley, + "The Design and Implementation of an Intentional Naming + System", Proc. 17th ACM SOSP, Kiawah Island, SC, Dec. + 1999. + + [CT90] D. Clark, D. Tennenhouse, "Architectural Considerations + for a New Generation of Protocols", Proceedings SIGCOMM, + 1990. + + [ISCHEMES] IANA, Uniform Resource Identifer (URI) Schemes, + http://www.iana.org/assignments/uri-schemes.html. + + [JDPF05] S. Jain, M. Demmer, R. Patra, K. Fall, "Using Redundancy + to Cope with Failures in a Delay Tolerant Network", + Proceedings SIGCOMM, 2005. + + [WJMF05] Y. Wang, S. Jain, M. Martonosi, K. Fall, "Erasure Coding + Based Routing in Opportunistic Networks", Proceedings + SIGCOMM Workshop on Delay Tolerant Networks, 2005. + + [ZAZ05] W. Zhao, M. Ammar, E. Zegura, "Multicast in Delay + Tolerant Networks", Proceedings SIGCOMM Workshop on Delay + Tolerant Networks, 2005. + + [LFC05] J. Leguay, T. Friedman, V. Conan, "DTN Routing in a + Mobility Pattern Space", Proceedings SIGCOMM Workshop on + Delay Tolerant Networks, 2005. + + [AF03] J. Alonso, K. Fall, "A Linear Programming Formulation of + Flows over Time with Piecewise Constant Capacity and + Transit Times", Intel Research Technical Report IRB-TR- + 03-007, June 2003. + + [FHM03] K. Fall, W. Hong, S. Madden, "Custody Transfer for + Reliable Delivery in Delay Tolerant Networks", Intel + Research Technical Report IRB-TR-03-030, July 2003. + + [BSPEC] K. Scott, S. Burleigh, "Bundle Protocol Specification", + Work in Progress, December 2006. + + [DTNSEC] S. Symington, S. Farrell, H. Weiss, "Bundle Security + Protocol Specification", Work in Progress, October 2006. + + [DTNSOV] S. Farrell, S. Symington, H. Weiss, "Delay-Tolerant + Networking Security Overview", Work in Progress, October + 2006. + + + + + +Cerf, et al. Informational [Page 31] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + [DBFJHP04] M. Demmer, E. Brewer, K. Fall, S. Jain, M. Ho, R. Patra, + "Implementing Delay Tolerant Networking", Intel Research + Technical Report IRB-TR-04-020, Dec. 2004. + + [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, September 1981. + + [RFC894] Hornig, C., "A Standard for the Transmission of IP + Datagrams over Ethernet Networks", STD 41, RFC 894, April + 1 1984. + + [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., + Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., + Zhang, L., and V. Paxson, "Stream Control Transmission + Protocol", RFC 2960, October 2000. + + [RFC4088] Black, D., McCloghrie, K., and J. Schoenwaelder, "Uniform + Resource Identifier (URI) Scheme for the Simple Network + Management Protocol (SNMP)", RFC 4088, June 2005. + + [S05] K. Scott, "Disruption Tolerant Networking Proxies for + On-the-Move Tactical Networks", Proc. MILCOM 2005 + (unclassified track), Oct. 2005. + + [T02] W. Thies, et al., "Searching the World Wide Web in Low- + Connectivity Communities", Proc. WWW Conference (Global + Community track), May 2002. + +12. Acknowledgments + + John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe + Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen + Farrell, Melissa Ho, Ting Liu, Mike Demmer, Jakob Ericsson, Susan + Symington, Andrei Gurtov, Avri Doria, Tom Henderson, Mark Allman, + Michael Welzl, and Craig Partridge all contributed useful thoughts + and criticisms to versions of this document. We are grateful for + their time and participation. + + This work was performed in part under DOD Contract DAA-B07-00-CC201, + DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA + Contract NAS7-1407. + + + + + + + + + + +Cerf, et al. Informational [Page 32] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + +Authors' Addresses + + Dr. Vinton G. Cerf + Google Corporation + Suite 384 + 13800 Coppermine Rd. + Herndon, VA 20171 + Phone: +1 (703) 234-1823 + Fax: +1 (703) 848-0727 + EMail: vint@google.com + + Scott C. Burleigh + Jet Propulsion Laboratory + 4800 Oak Grove Drive + M/S: 179-206 + Pasadena, CA 91109-8099 + Phone: +1 (818) 393-3353 + Fax: +1 (818) 354-1075 + EMail: Scott.Burleigh@jpl.nasa.gov + + Robert C. Durst + The MITRE Corporation + 7515 Colshire Blvd., M/S H440 + McLean, VA 22102 + Phone: +1 (703) 983-7535 + Fax: +1 (703) 983-7142 + EMail: durst@mitre.org + + Dr. Kevin Fall + Intel Research, Berkeley + 2150 Shattuck Ave., #1300 + Berkeley, CA 94704 + Phone: +1 (510) 495-3014 + Fax: +1 (510) 495-3049 + EMail: kfall@intel.com + + Adrian J. Hooke + Jet Propulsion Laboratory + 4800 Oak Grove Drive + M/S: 303-400 + Pasadena, CA 91109-8099 + Phone: +1 (818) 354-3063 + Fax: +1 (818) 393-3575 + EMail: Adrian.Hooke@jpl.nasa.gov + + + + + + + +Cerf, et al. Informational [Page 33] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + + Dr. Keith L. Scott + The MITRE Corporation + 7515 Colshire Blvd., M/S H440 + McLean, VA 22102 + Phone: +1 (703) 983-6547 + Fax: +1 (703) 983-7142 + EMail: kscott@mitre.org + + Leigh Torgerson + Jet Propulsion Laboratory + 4800 Oak Grove Drive + M/S: 238-412 + Pasadena, CA 91109-8099 + Phone: +1 (818) 393-0695 + Fax: +1 (818) 354-6825 + EMail: ltorgerson@jpl.nasa.gov + + Howard S. Weiss + SPARTA, Inc. + 7075 Samuel Morse Drive + Columbia, MD 21046 + Phone: +1 (410) 872-1515 x201 + Fax: +1 (410) 872-8079 + EMail: howard.weiss@sparta.com + + Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay + Tolerant Networking Research Group (DTNRG) web site is located at + http://www.dtnrg.org. + + + + + + + + + + + + + + + + + + + + + + + +Cerf, et al. Informational [Page 34] + +RFC 4838 Delay-Tolerant Networking Architecture April 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Cerf, et al. Informational [Page 35] + |