IPN Research Group V. Cerf INTERNET-DRAFT Worldcom/Jet Propulsion Laboratory
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
Abstract This document describes an architecture for delay-tolerant networks, and is a generalization of the architecture designed for the Interplanetary Internet: a communication system to provide Internet- like services across interplanetary distances in support of deep space exploration. This generalization addresses networks whose operational characteristics conventional networking approaches unworkable or impractical. We define a message-based overlay that exists above the transport layer of the networks on which it is hosted. The document presents an architectural overview followed by discussions of services, topology, routing, security, reliability and state management. The document concludes with a discussion of end- to-end information exchange, including an example.
Cerf, et al. [Page 1] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
Table of Contents Status of this Memo...... 1 Abstract...... 1 Table of Contents...... 2 Copyright Notice...... 3 Acknowledgments...... 4 Foreword...... 5 1 Introduction ...... 6 2 Why an Architecture for Delay-Tolerant Networking? ...... 6 2.1 Constraints Posed by Extreme Environments ...... 6 2.2 Problems with Internet Protocols and Applications ..... 10 2.3 DTN Principles of Design ...... 12 3 DTN Architectural Overview ...... 14 3.1 The DTN is Based on Message Switching ...... 15 3.2 DTN Classes of Service Mimic Postal Mail-like Operation 15 3.3 Regions and Region Identifiers ...... 15 3.4 Tuples ...... 16 3.5 Late Binding ...... 16 3.6 The "Bundle Layer" Terminates Local Transport Protocols and Operates End-to-End ...... 17 3.7 Routing ...... 17 3.8 Bundle Layer Reliability and Custodianship ...... 17 3.9 Security ...... 18 3.10 Time Synchronization ...... 19 4 Service Considerations: Application Instances and Bundles . 19 4.1 Networking Style Issues ...... 19 4.2 Bundle Lifetime ...... 20 4.3 Classes of Service ...... 20 4.4 Delivery Options ...... 21 4.5 Naming and Addressing ...... 22 5 Topological Considerations: Node, Regions, and Gateways ... 22 5.1 Node ...... 22 5.2 Regions ...... 22 5.3 Gateways ...... 23 5.4 Discussion ...... 23 6 Routing considerations ...... 24 6.1 Types of Routes ...... 24 6.2 Store-and-forward operation ...... 25 6.3 Contact-oriented routing ...... 26 6.4 Routing protocols ...... 26 7 Security considerations ...... 27 7.1 User-oriented security services ...... 27 7.2 Infrastructure security services ...... 29 8 Reliability Considerations ...... 34 8.1 Custodial Operation ...... 34 8.2 End-to-end Retransmission ...... 35 8.3 Congestion Control at the Bundle Layer ...... 36 9 State Management Considerations ...... 36 9.1 Application Interface State ...... 36 9.2 Bundle retransmission state ...... 37 9.3 Bundle routing state ...... 38 9.4 Transmission queue state ...... 38 Cerf, et al. Expires October 2002 [Page 2] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
9.5 Receive queue state ...... 39 9.6 Network management state ...... 39 10 Convergence Layer Considerations for Use of Underlying Protocols ...... 39 11 Bundle Header Information ...... 39 12 An Example Bundle Transfer ...... 41 12.1 Rules for forming tuples in the example network ...... 41 12.2 Example Network Topology at the Region Level ...... 42 12.3 DTN Gateway routing ...... 44 12.4 Systems participating in example bundle data transfer . 45 12.5 End-to-end Transfer ...... 47 12.6 Error Conditions at the Bundle Layer ...... 49 13 Summary ...... 52 14 References ...... 52 15 Security Considerations ...... 52 16 Authors' Addresses ...... 54
Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.
Cerf, et al. Expires October 2002 [Page 3] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
Acknowledgments John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, and Craig Partridge all contributed useful thoughts and criticisms to this document. We are grateful for their time and participation. This work was performed 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. Expires October 2002 [Page 4] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
Foreword The term 'sonata' can be applied to a large work in three movements or to the three sections of a single movement: exposition, development, recapitulation. They resonate with the three acts of a movie or play, the three elements of a primal myth or legend (life, death, rebirth), the cycle of days (daylight, night, then daylight again) and of the seasons in temperate climates (nice weather, then winter, then it gets nice again), the Star Wars trilogy, etc. Basically, in any human experience we start off brightly, full of energy and hope; then we experience reality and become thoughtful and reflective, darker and slower; then Something Happens and hope is reborn, our energy returns, and we reach that happy synthesis of Innocence and Experience that is maturity. Allegro, andante, rondo..." -- Scott Burleigh Release Notes draft-irtf-ipnrg-arch-00.txt, May 2001: Allegro.
Original Issue. draft-irtf-ipnrg-arch-01.txt, April 2002: Andante. Restructured document to distinguish between architecture for delay- tolerant networking and the *application* of that architecture to a number of different environments, potentially including interplanetary internetworking, military tactical networking, and sensor internetworking.
Refined DTN classes of service and delivery options. Introduced a "reply-to" address to have information directed to a third party rather than the source.
Further defined the topological elements of delay tolerant networks. Elaborated routing and reliability considerations.
Significant work in defining the model for securing the delay tolerant network infrastructure, based on signed admission control credentials.
Added section discussing state information.
Updated bundle header information and end-to-end data transfer example.
Cerf, et al. Expires October 2002 [Page 5] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
1 Introduction This document describes an architecture for delay-tolerant networks. We present this as a generalization and extension of our ongoing work on the Interplanetary Internet (http://www.ipnsig.org). We have come to the realization that there are a number of different environments that share essential characteristics for which the architecture presented herein is appropriate. The particular approach we employ is that of a message-based overlay that exists above the transport layers of the networks on which it is hosted.
2 Why an Architecture for Delay-Tolerant Networking? The existing TCP/IP-based internet, while fabulously successful in many environments, does not suit all environments. The ability of the "TCP/IP suite" to provide service depends on a number of important assumptions: − that an end-to-end path between source and destination exists for the duration of the communication session; − (for reliable communication) that the maximum round-trip time over that path is not excessive and not highly variable from packet to packet; and − that the end-to-end loss is relatively small. A class of "challenged networks," which may violate one or more of these assumptions, is becoming important and may not be well served by the current end-to-end TCP/IP model. These networks typically serve environments in which it is either impractical or impossible to configure a communication environment that supports the assumptions on which the TCP/IP suite depends. This section examines some of the constraints posed by extreme environments that may result in "challenged networks," and considers the problems that these environments might cause for common Internet protocols and applications. Finally, we derive some "principles of design" for the DTN.
2.1 Constraints Posed by Extreme Environments The kinds of extreme environments that this DTN architecture addresses constrain both the communication system and the applications using that communication system. This section describes some of the characteristics that make environments "extreme." Clearly, not all environments that would be considered "extreme" exhibit each of these characteristics.
2.1.1 Long and/or Variable Delays Delay affects networks in at least two different ways. First, interactivity is directly affected by delay. For example, telephone conversations over a terrestrial telephone line are markedly Cerf, et al. Expires October 2002 [Page 6] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
different than telephone conversations that are routed over a geostationary satellite hop. Second, variability in delay can affect applications and protocols. Consider a stream of packets carrying voice data over a network. If the delay in the network varies greatly from one packet to the next, a buffer is required to avoid the perception of pauses in the reconstructed voice track. If the application is hosted on a network with greater delay variability than the application was designed for, the stream will again have pauses, possibly of significant magnitude to make the voice data unintelligible. Delays are comprised primarily of three components: propagation delay through the medium; queuing delay within relay points, source, and destination; and clocking delays associated with transmitting an atomic unit of data onto the medium. Propagation delays can be long due to speed-of-light delays to cross long distances (e.g., deep space). Alternatively, propagation delays could be long due to the propagation medium (e.g., acoustic/underwater). How long is long? Round trip delays to Mars range between about 16 and 40 minutes at the speed of light. Queuing delays are affected by traffic and service rate. In extreme environments, the service rate of a node may be low due to power limitations requiring a slow processor or a long wait while the unit is quiescent. Arrival distributions may cause significant variability in delays, particularly for heavy-tailed distributions.
Clocking delays accrue each time a packet is transmitted if the packet was fully received prior to transmission. ("Cut-through" routing, in which the first bits/bytes of a data unit are operated upon before the last bits/bytes have been received, is a fairly rare operation). For many types of data, the latency advantages of cut- through routing are more than offset by the reluctance of network designers to forward corrupt data. (Although some types of data are useful even if partially corrupted.) For data that are not forwarded before being fully received (and error checked), clocking delays accumulate at each hop in the network. For relatively slow, multi- hop networks, this can result in high per-packet delays, particularly if packet sizes are large. (Which can, of course, increase queuing delays for other packets, increasing both the round trip times and the variability of delay.)
We assume that processing delay, another contributor to overall delay, is comparatively low, and is therefore not discussed here.
Variability of delay can have a significant effect on communication in addition to absolute delay. Many protocols attempt to provide reliability through retransmission (ARQ) mechanisms. Timers are a critical element of most retransmission mechanisms, and establishing a retransmission time out value is an important aspect of the mechanism. Some protocols, particularly those at the link layer, Cerf, et al. Expires October 2002 [Page 7] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
have the ability to eliminate all components of round trip time other than propagation and clocking delays from their timings, and are able to produce retransmission time out estimates that are quite close to the actual round trip time. When queuing delay must be considered and the timing does not have direct knowledge of the delays at all of the queues, estimating a reasonable (not too high, not too low) retransmission time out value becomes more complex. A reasonable retransmission time out value is necessary to prevent unnecessarily retransmitting data (in the case of a timer that is set too low), and to prevent excessive delays in retransmitting lost data (in the case of a timer that is set too high).
2.1.2 Frequent Partitioning Network partitioning typically adds to data loss. If losses become too severe, applications typically fail. In addition to contributing to loss, network partitioning adds significantly to overall delay if nodes are configured to store data until the outbound link is restored. This behavior can also contribute to misordered data arriving at the destination, which can cause poor performance in some protocols.
2.1.3 Data rate asymmetry Data rate asymmetry measures the ratio of forward-path minimum capacity versus reverse-path minimum capacity. Data rate asymmetry adversely affects protocols using ARQ for reliable delivery by altering the ACK or NACK return path. This effect has been studied extensively with TCP, and is discussed below. At a higher layer, request/response applications that have not been appropriately tuned to balance the amount of request versus response traffic can time out waiting for data to travel across the lower-capacity link. In the most extreme case of bandwidth data rate, the asymmetry is infinite (as is the case with communications to submarines, for example) and the entire method of using ARQs for reliable delivery is not possible. In these cases, forward error correction and periodic retransmission are typically used. See [BLMR98] as an example of how such techniques are used in the Internet.
Data rate asymmetry can arise due to routing path asymmetry, different forward/reverse path link technologies, or intentional engineering tradeoffs. Moderate asymmetries in the wired Internet are found most commonly in asymmetric access technologies such as in CATV or ADSL-based subscriber lines. The largest asymmetries for wireless Internet access appear to be prevalent in in-flight Internet access systems. The AirTV system, for example, being proposed for 2004 and beyond, could provide a ground-to-air speed of up to 45Mb/s using DVB satellite technology with a comparatively anemic air-to- ground bandwidth of a 128kb/s or less using INMARSAT [ARINC]. In the case of deep space communications, downlink data rate is intentionally engineered to be much greater than uplink data rate. This tradeoff is not surprising given the goal of most science Cerf, et al. Expires October 2002 [Page 8] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
missions: the capacity demands of downlinking high-resolution images and telemetry from a spacecraft dwarf the capacity required to uplink short commands to that spacecraft.
2.1.4 Packet Loss and Errors Consider the following probability of success metric: Pr = [(1-pe)^(i*(8*m)) This metric is the probability of successful end-to-end delivery of a particular message of size m bytes across i links assuming an identical, independently distributed (IID) stationary loss process with constant bit error rate pe across all intervening forwarders. (In this equation, the carat -- ^ -- indicates exponentiation.) This metric, as expressed, does not account for congestive loss but does account for message size and number of cascaded links given a fixed BER. For packet networks, most links employ some form of error detection, implying that any bit loss creates an end-to-end packet loss. As can be clearly seen from the formula, the end-to-end probability of successful delivery decays exponentially with path hop count. Any congestive loss would only worsen the performance, but some of these networks are engineered with admission control to effectively eliminate in-network congestion. For reliable transfer, excessive errors require repair using either error correction or retransmission. In the case of end- to-end retransmission, the path can be so lossy as to effectively cause end- to-end retransmission to be useless. Consider the probability of packet loss pp=1–Prforsome fixed m. Given the assumptions listed above, the expected number of retransmissions required before successful delivery is given by: (1-(1-pp)^i)/(1-pp)^i. Considering a packet error probability of 0.3. In this case, 4 hops requires 3 retransmissions, 10 hops requires 34, and 20 hops requires about 1200 retransmissions. If a hop-by-hop retransmission scheme were used instead, the total number (network wide) number of retransmissions is given by i*pp/(1-pp). For the same error probability of 0.3, the number of retransmissions for 4, 10, and 20 hops would be 2, 5, and 9, respectively. Thus, for very lossy environments, an end to end retransmission strategy will not provide satisfactory performance.
2.1.5 Interoperating Among Differently-Challenged Networks A complicating factor in building internetworks comprised of networks operating in multiple different extreme environments is that there is no guarantee of support for any common communication technology. In many instances, at the time of deployment, only the barest minimum of capabilities can be fielded to support the given mission. If these networks are successful, they evolve. In many cases, this evolution leads to an expansion of scope and span for the network. Often this can result in a requirement to interoperate with another network in an environment that presents different challenges that have been Cerf, et al. Expires October 2002 [Page 9] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
addressed by dramatically different solutions. The ability to operate over many different types of networks that have been fielded to support extreme environments is both a challenge and a constraint for this Delay Tolerant Networking Architecture.
2.1.6 Examples of some extreme environments Several types of extreme environments currently exist, with more appearing almost daily. If one considers the wired Internet, with multi-gigabit backbones, almost no corruption-related data losses and relatively short round trip times, then many different types of environments seem extreme. This architecture was originally conceived to support the Interplanetary Internet, which exhibits round trip delays on the order of tens of minutes and intermittent connectivity that can result in disconnection for weeks. Military tactical networks, in which data rates are low, error rates are high, and link interruptions are frequent, can likely derive great benefit from application of this architecture.
Similarly, sensor networks deployed in oceanic environments exhibit long delays, significant data loss, and the potential for long link outages.
An individual seeking a networking solution for a particularly intriguing and challenging environment has recently approached us to determine if the DTN architecture was right for the following environment. A group of widely dispersed communities of people in remote areas is not well served by either wired, fixed wireless, or satellite internet service. They do, however, frequently travel on snowmobiles from community to community, and congregate at work sites and larger towns. To effectively serve this environment, an architecture is required that can embrace intermittent, probabilistic connectivity, store and forward operation, and high and variable delays. (The architecture described in this document meets these needs and more.)
2.2 Problems with Internet Protocols and Applications This section discusses some of the issues associated with attempting to serve challenged networks with the Internet suite of protocols.
2.2.1 Internet "Core" Protocols The performance characteristics of challenged networks contribute to confound the efficient operation of the core Internet protocols. By the ‘core’ Internet protocols we mean IP, TCP, UDP, BGP, common IGPs (RIP, OSPF, or EIGRP) and DNS. These protocols span the services of end-to-end datagram delivery, reliable two-party stream delivery, Cerf, et al. Expires October 2002 [Page 10] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
regional (aggregated) routing path discovery with policy, intra- domain path selection and distributed support for name resolution. Although some of these protocols are technically “application” protocols from a layering point of view, we treat them here together as core protocols for the purposes of discussion. Excessive latency affects TCP directly by severely limiting its throughput performance or interfering with connection establishment [DMT96]. Any application-layer protocol using TCP as its underlying transport is therefore affected (BGP and DNS zone transfers). Excessive latency also adversely affects the proper operation of conventional routing protocols as links will be incorrectly discovered to be non-operating when soft-state refreshes are delayed too long (RIP), or a lack of response to link state “hello” messages (OSPF, EIGRP) is observed. UDP is not sensitive to excessive latency because it does not contain timers that affect its operation. However, core application protocols that require it (DNS queries/responses plus SNMP if used) will take too long to complete when faced with excessive delay, triggering early application failure (or the lack of ability to use DNS name/address mappings in the case of address-to-name queries). Data rate asymmetry adversely affects TCP by altering the smooth flow of acknowledgments. Extensive studies have been conducted on TCP using the normalized asymmetry ratio, which takes into account the asymmetric message sizes between data packets and returning ACKS [MLS00]. Results indicate that bandwidth asymmetry can lead to poor performance of unidirectional transfers due to alterations in the time series of the ACK channel. In particular, if ACKs are queued, their spacing in time causes the TCP sender to clock out subsequent packets less frequently. If ACKs are lost, burstiness, slow congestion window growth, or defeating of the fast retransmit/recovery algorithms can occur. (See [PILC-ASYM] characterization of this problem and some possible approaches to ameliorate it). Any application layer protocols attempting to use TCP over asymmetric links are therefore affected as well.
Significant path loss affects the TCP transport most strongly, causing it a number of problems. After multiple loss events it will continue retrying with a backed-off retransmission timer until it gives up on retransmitting altogether and closes the connection. Somewhat more moderate losses will contribute to problems invoking the fast retransmit and recovery algorithms, even in the presence of SACK. IP performance can be affected by path loss if fragmentation is required. IP provides no mechanism for fragment retransmission, thereby causing the overall probability of successful datagram delivery to be further reduced if datagrams are fragmented [M95].
Node longevity affects the probability of end-to-end delivery, as round-trip or even one-way delivery time of a particular message may exceed the sender’s lifetime. Clearly, in such cases it is useless to arrange for immediate acknowledgements to be returned. In such Cerf, et al. Expires October 2002 [Page 11] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
cases, any notification of successful or unsuccessful delivery needs to be directed to some alternative node that remains functional.
2.2.2 Common Internet Applications and Supporting Protocols The most common user services within the Internet today are the web, e-mail, and perhaps FTP. These services employ a number of different application protocols, including HTTP, SMTP, POP, IMAP, Microsoft’s Exchange Protocol and FTP. These protocols, or in some cases the applications that implement them, are either severely degraded or fail to operate entirely under challenging conditions. Two primary reasons are application-level timeouts mismatched to the actual network latency, and an excessive number of round-trip request/response message exchanges required in order to accomplish a protocol transaction. For example, web browsers and mail clients will often time out during connection establishment after a minute or two. The SMTP protocol requires each peer to mutually identify itself prior to actually exchanging the mail payload, even though this early name exchange is not fundamental to the process of delivering e-mail. Such protocols have been called “chatty” due to their excessive number of round-trip times required to accomplish a simple task. FTP has a similarly chatty interaction during its initial association as it exchanges user login and authentication information.
2.2.3 Discussion When considering the use of existing Internet protocols as a basis for interconnecting challenged networks, certain properties of the operational environment seem insurmountable. The possibility that only a one-directional path is available at any given time appears to preclude the use of conventional TCP-like protocols based on ARQ for reliability because an ACK channel may not be available. With exponentially decaying probability of successful end-to-end delivery as path length grows, end-to-end reliability should be avoided in favor of hop-by-hop retransmission in lossy environments. Given the possibility of very high round-trip times, any expectation of timely response in request/ response protocols must also be avoided. Finally, the regular Internet routing protocols assume the immediate existence of an end-to-end path and do not accommodate the notion of future (scheduled) routing opportunities that are needed for operation in frequently disconnected environments.
2.3 DTN Principles of Design After examining the environmental conditions cited above and seeing the problems that the Internet protocols have with these conditions, we derived the following principles of design to guide the definition of a Delay Tolerant Networking Architecture.
Cerf, et al. Expires October 2002 [Page 12] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
2.3.1 Use transport and network layer technologies appropriate to the local environment Where Internet protocols work well, there is a distinct advantage to using them. However, in other environments, such as sensor networks or certain radio networks, the internet suite may not be the best fit for the task at hand. Some sensor networks, for example, use very different routing and node naming concepts. The DTN architecture should not restrict designers in building networks using transport, network, link, and physical layer technologies that are best suited for their environments. Rather, the DTN architecture should provide the means for dissimilar networks to interoperate. Whereas IP provides the common substrate for the Internet above dissimilar link layers, the dissimilarity of the extreme environments discussed precludes the use of a single end-to-end transport protocol. Instead, end-to-end operations require us to provide a common substrate above the *transport* layers of the constituent networks. Thus, the DTN architecture creates a "network of Internets" by providing an end-to-end layer above the transport layer. We call this the "bundle layer."
2.3.2 Employ a "non-chatty" communication model Because delays may be long and network partitioning may be frequent, we suggest that highly interactive styles of communication be avoided in the kinds of extreme environments described above. Rather, entire application-layer messages, which we call "bundles," move through the network as units. These bundles are intended to have all of the primary data and meta data necessary for their use at the destination. Although this *may* mean that bundles are large (relative to packets in a TCP/IP network), it does not require it. The intent is to not have multiple exchanges between source and destination (e.g. "user:", response, "password:", response, etc.) when such exchanges can be "bundled" together into a single communication.
2.3.3 Base transfers between nodes on store-and-forward techniques The Internet protocol IP is based on store and forward transmission. However, in IP routers, the "store" portion of the operation is typically only long enough to determine the next hop destination and to wait for any packets to be transmitted that are ahead of the current one. If no route to the destination exists at the point in time that the routing engine examines the packet, that packet is typically discarded.
In a Delay-Tolerant Network, it is considered *normal* for there to be no path to the destination at the time a bundle is received. Bundles are routed based on the expectation of connectivity, either as a result of a firm schedule or previous experience. If an episode of connectivity doesn't materialize, bundles are rerouted accordingly. This approach assumes that there is a considerable Cerf, et al. Expires October 2002 [Page 13] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
amount of storage available within the network, which is a fundamental assumption for these types of delay-tolerant networks. The result of this interpretation of store-and-forward operation is that bundles of data can still make forward progress toward their destination even if a contemporaneous end-to-end path *never* exists.
2.3.4 Use custody transfer to advance the point of retransmission toward the destination Upon receipt of a bundle, a node may *take custody* of it. This is a commitment made by the accepting-node that it will shoulder the burden of retransmission to insure that the bundle reaches its destination. This allows the source (or previous custodian) to release the resources necessary to ensure delivery and moves the point of retransmission closer to the destination. The notion is that by moving the point of retransmission forward, retransmissions will be faster and will consume fewer network resources than if they had to come from the information source. There is an obvious benefit to this approach if the point of retransmission progresses across a *very* long delay hop (such as one that spans interplanetary distance). However, in a network composed of a series of lossy links (such as a congested multi-hop wireless network), there is similar benefit, as discussed in section 2.1.4.
2.3.5 Provide security services to secure both the infrastructure and the information Networks in extreme environments may range from being completely disposable to irreplaceably precious. Those that are disposable are typically so resource starved that difficult tradeoffs must be made regarding provision of service versus protection of infrastructure. These tradeoffs must be made by those who instantiate the architecture, and the architecture must provide for a range of decisions.
Minimally, we have concluded that the architecture must provide for infrastructure protection, up to and including mutual suspicion among DTN routers. However, this must be optional at the discretion of those who actually instantiate a particular delay tolerant network. Security services offered to users should include key management, authentication, integrity, and confidentiality, but availability and use of those services may vary from DTN to DTN.
3 DTN Architectural Overview The previous section presented the design principles that guide the definition of the DTN architecture. This section presents an overview of the decisions that result from those design principles.
Cerf, et al. Expires October 2002 [Page 14] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
3.1 The DTN is Based on Message Switching We note in the design principles that unnecessary interaction between the source and destination should be avoided, and that a combination of user data and meta data be transmitted in a bundle. This is the "message" on which the DTN architecture is based. In general, message switching provides some advantages -- a message- switched architecture provides the network 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 prior to transmission over an outbound route (as is the case in the DTN version of store-and-forward) the advantage provided by this information provided is significant. In an environment that frequently experiences network partitioning, messages are efficient units for queuing while awaiting network reconnection.
3.2 DTN Classes of Service Mimic Postal Mail-like Operation The U.S. Postal Service provides a strong metaphor for the services that a Delay-Tolerant Network offers. Traffic is generally not interactive. It may be one-way in nature. There are generally no strong guarantees of delivery delay.
The DTN Architecture, like the Postal Service, offers *relative* measures of priority (low, medium, high). It may offer basic notifications, for example: "the intended recipient has accepted delivery of the message," "the route taken by this message is as follows..." and "the message has been transmitted."
An essential element of Postal Service operation is that mail has a place to wait in queue until an outbound hop is available. This highlights the previously stated assumptions:
1. That there is storage available in the network, 2. that storage is well-distributed throughout the network, 3. that it sufficiently persistent to store bundles until custody transfer can occur, and 4. (implicitly) that this ‘store-and-forward’ model is a better trade-off than using resources to attempt to effect continuous connectivity or other alternatives.
For a network to effectively support the DTN architecture, these assumptions must be considered and must be decided upon affirmatively.
3.3 Regions and Region Identifiers The DTN architecture defines a "network of Internets." Each of these Internets is called a "DTN region." Regions may be delimited by differences in network protocol, transport protocol, or addressing mechanism. Regions may also be delimited by other criteria, such as Cerf, et al. Expires October 2002 [Page 15] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
trust boundaries [NEWARCH]. Each DTN region has a unique identifier that is known (or knowable) among all regions of the DTN. All inter-region communication takes place via DTN *gateways*, which provide the interconnection points between regions. These correspond to "waypoints" in [META], and to the gateways described in the original ARPANET design [CK74]. DTN gateways differ from ARPANET gateways because they operate above the transport layer, and are focused on message switching rather than packet switching. However, both DTN gateways and ARPANET gateways provide for the conversion between the protocols specific to one region and the protocols specific to another. Region definition and region identification are key concepts in the DTN architecture. DTN bundles that originate outside the destination region are first transmitted to one of the DTN gateways that connect the destination region with one or more other regions. Routing outside the destination region is done based on the destination region's identification, meaning that there is a single region identifier space that is common across the end-to-end DTN.
3.4 Tuples The region identifier described above is sufficient to get a bundle of data to its destination region, but not to deliver it to the specific entity for which it is intended. The DTN architecture uses a tuple of the region identifier and a region-specific entity identifier to identify a particular entity in a region. In the DTN, the tuple of {region ID, entity ID, instance ID} fully identifies an application instance. The tuple allows us to segregate data into that which is necessary for routing *across* regions and that which is necessary for delivery within a region and within a node. As a result of this, the entity ID and instance ID are *opaque* outside their region of definition. The referenced entity might be a host, a protocol, an object, or something else. Further, the entity identifier might be a name, an address, or a descriptor such as a URL. This is a local issue within the entity's region. (If the entity ID is a name, there is an assumption that a name-to-address binding function exists within the region to support eventual routing of the bundle to the destination entity.) The instance ID accommodates the situation in which a particular *instance* of that entity is targeted, such as with a reply to a query.
3.5 Late Binding The opacity of entity IDs outside their local region enforces another key concept in the DTN Architecture: that of late binding. Late binding refers to the fact that the entity ID of a tuple is not interpreted (e.g., bound to an address) outside its local region. This avoids having a universal name-to-address binding space (and its Cerf, et al. Expires October 2002 [Page 16] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
associated database and synchronization issues). This approach preserves a significant amount of autonomy within each region. The entity IDs used in bundles might be built on DNS names, or URLs, but they might also be "expressions of interest" as in a directed diffusion-routed network [ref. Estrin]. Additionally, late binding avoids the delay-related issue that the binding information might be highly ephemeral relative to the transit time of a bundle. We assume that the internal details of a destination network will be sufficiently stable for the duration of a transmission of a message within that region, or that delay-tolerant mechanisms will be employed *within* the region to compensate. (This is, by definition, a local issue within the region and may be accommodated in whatever manner is most practical for that region.)
3.6 The "Bundle Layer" Terminates Local Transport Protocols and Operates End-to-End The bundle layer is an end-to-end protocol that employs custody transfers for in-network retransmission (although not necessarily bundle-hop-by-bundle-hop retransmission). The bundle layer makes use of the reliability mechanisms available from the underlying transport layers of each region, and a single bundle hop *may* span an entire region.
3.7 Routing The bundle layer provides routing among DTN-capable nodes, including DTN gateways. There may be many DTN gateways that interconnect adjacent regions, and there may be multiple bundle routing "hops" within a region (particularly if intra-regional connectivity is intermittent).
Routing exchange mechanisms may differ from one instantiation of the Delay Tolerant Network Architecture to another, reflecting different needs and constraints of the extreme environments. Different routing protocols may be employed for intra-region routing and for inter- region routing. We do not require that the *same* inter-region routing protocol run among all (inter-region) DTN gateways in a Delay Tolerant Network. (It is required that necessary routing information be able to be propagated throughout the DTN, but the mechanisms for doing that are neither defined nor constrained by this document.)
3.8 Bundle Layer Reliability and Custodianship The bundle layer provides three types of reliability services: end- to-end acknowledgment of a bundle (and accompanying retransmission), custodial transmission (with in-network retransmission if required), and unacknowledged bundle transmission. End-to-end acknowledgment and custodial transfers may be combined for additional reliability.
Cerf, et al. Expires October 2002 [Page 17] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
Reliability services at the bundle layer are relatively simple because the bundle layer depends upon the reliability mechanisms in each of the underlying internets. Bundles are delivered atomically and are, generally, independent of other bundles. As a result, positive acknowledgment is possible, but partial or negative acknowledgment is not. Since delays may be long and/or highly variable, retransmission timers must, in general, be coarse and may be strongly affected by local policy. Custody transfer, introduced in section 2.3.4, above, allows the source to delegate retransmission responsibility and recover its retransmission-related resources relatively soon after sending the bundle. While not every node in a DTN must be capable of providing custodial services, all DTN gateways (that span two or more DTN regions) are expected to be able to be custodians. This introduces a requirement to be able to discover prospective custodians, select one, and direct a bundle toward it.
3.9 Security Resource scarcity in delay-tolerant networks dictates that some form of access control is required. It is not acceptable for an unauthorized user to be able to flood the network with high-priority traffic, possibly preventing the network's mission from being accomplished. Implicit in this statement is a requirement for some form of admission control and/or in-network authentication that is sensitive to the class of service that a user has requested, and the means to verify that the user is authorized to make that request. In a low delay environment, this would simply be tedious. In a high/variable delay, low data rate environment, it is potentially much worse: access control lists are difficult to update, re-keying presents hard problems, and routers or end nodes might be compromised.
Key management presents a number of dilemmas. Keys will almost certainly require replacement in all but the most disposable of networks. Re-keying and related operations on highly remote nodes is challenging, and proper approaches to key distribution in this environment remain active areas for research.
The DTN must be able to support end-to-end user services that include verification of a message's integrity and the ability to provide confidentiality of a user's message. It must do this in a way that does not require a great deal of interaction across long-delay (or resource-constrained) data links. "Support" for these services may involve provision of a key management service to support user-level confidentiality and integrity, or it may involve providing these services as part of the bundle layer. This is an area still under consideration.
Cerf, et al. Expires October 2002 [Page 18] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
3.10 Time Synchronization The DTN architecture depends on time synchronization for two primary purposes: routing, and "time to live" computations. Routing that is based on schedules and dependent upon coordination of shared assets (such as directional antennas) creates a requirement for time synchronization. As with many requirements, just how *much* time synchronization is required is an economic trade-off. The cost to achieve a particular degree of time synchronization must be weighed against the cost of not having it. The costs of not having time synchronization include reduced overall efficiency of a communication asset, potential loss of user data, power inefficiency, and many others. For some communication assets, such as NASA's Deep Space Network, the operational cost is many thousands of dollars per hour, and the cost to achieve a modest level of time synchronization between peers is quite justifiable. There is a study currently underway [ref Mills] to examine the time synchronization issues across NASA's Deep Space Network and to determine a particular time synchronization scheme suited to that network. Given that DTN routing depends to some degree on time synchronization, the DTN architects have made the decision to exploit its availability. In particular, time to live computations may be done by including a source time stamp and an explicit time to live field (in time units after the time in the source time stamp). This requires some level of time synchronization, but since its sole use is for purging data from the network, the synchronization requirements are not strict. This approach allows a source time stamp to be used for a number of purposes, such as to prevent replay protection and to identify individual messages.
4 Service Considerations: Application Instances and Bundles This section describes the basic services available to applications using the DTN Architecture's Bundle Service. The Bundle Service is the message-oriented communication service provided by the "Bundle Layer" described in section 3.6.
4.1 Networking Style Issues Before discussing specific Bundle Services, a note about application interaction style is in order. This service is intended to operate in *delay-tolerant* networks. That does not mean that there *must* be delays in the network, or that there *will* be delays, but that there *may* be delays. The protocols providing the services exposed by the bundle layer are delay tolerant. Applications using those services should be, too.
Message-oriented communication differs from conversational communication. In general, applications should attempt to include enough information in a bundle so that it may be treated as an Cerf, et al. Expires October 2002 [Page 19] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
independent unit of work by the remote entity (a "transaction", although transactions carry connotations of multi-phase commitment that we do not intend here). The goal is to minimize conversation between application entities that are separated by a network that presents long and possibly highly variable delays, and to constrain any conversation that does occur to be asynchronous in nature. A file transfer application, for example, should incorporate account information, file location information, file operation information, and file content within a bundle, allowing atomic operation on that bundle. Comparing this style of operation to a classic FTP transfer, one sees that the bundled model can complete in one round trip time, whereas an FTP file "put" operation can take as many as eight round trips to get to a point where file data can flow. [ref. WhynotTCP]. Delay-tolerant applications must consider additional factors beyond the conversational implications of long delay paths. Application instances may terminate (voluntarily or not) between the time that a bundle is sent and the time its response is received. If an application has anticipated this possibility, it is possible to reinstantiate the application instance based on state information saved in persistent storage. This is an implementation issue, but also an application design consideration. Similarly, either host or application mobility may result in the application's address having changed by the time a response is received. If applications embed physical addresses into their data, they will defeat the potential benefits that late binding provides. Some consideration of delay-tolerant application design can result in applications that work well in low-delay environments, and that do not suffer extraordinarily in high or highly-variable delay environments.
4.2 Bundle Lifetime Applications are requested to provide an expiration time (actually, a time to live in seconds) for a bundle if the value of the data has a finite duration. If not supplied, or if the user-supplied value is larger than local policy permits, the bundle layer will provide a value. Note that this value is treated as an actual "time to live" - - it is added to the time that a bundle was submitted by the application to determine the time at which the bundle will be purged from the network. Appropriate values depend on the network and the data, and may range from seconds to weeks.
4.3 Classes of Service The DTN architecture provides for a range of classes of service. These classes of service are requests to the bundle layer to provide *relative* distinctions in the immediacy with which bundles are transmitted.
We have currently defined three classes of service in the DTN Cerf, et al. Expires October 2002 [Page 20] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
architecture:
− Bulk - In bulk class, bundles are shipped on an "as possible" basis. No bulk class bundle will be shipped until all bundles of other classes bound for the same next hop destination have been shipped. − Normal - Normal class bundles that are in queue and bound for the same next hop destination are shipped prior to any bulk class that are in queue. − Expedited - Expedited bundles, in general, are shipped prior to bundles of other classes. However, the bundle layer *may* implement a queue service discipline that prevents starvation of the normal class, which may result in some normal bundles being shipped before expedited bundles bound for the same next hop destination as the normal class bundles.
4.4 Delivery Options The bundle layer offers a number of delivery options to users. First and foremost is the option of custodial delivery. Custodial delivery means that a bundle will be reliably transmitted by the bundle layer, and that the point of retransmission will advance through the network from one custodian to another until the bundle reaches its destination. The bundle layer depends on the underlying transport protocols of the networks that it operates over to provide the primary means of reliable transfer from one bundle layer entity to the next. However, when custodial delivery is requested, the bundle layer additionally provides a coarse-grained timeout and retransmission mechanism and an accompanying acknowledgment mechanism. When a bundle application does *not* request custodial delivery, this bundle layer timeout and retransmission mechanism is not employed, and the bundle depends solely on the reliability mechanisms of the underlying transport layers.
A second delivery option is the option of a return receipt. An application may request a return receipt for a bundle that is being transmitted. When the subject bundle is received *by the destination application* (not simply the destination bundle layer), a return receipt is generated by the bundle layer and returned to the source or the source's designated alternate (reply-to) application, which would typically be located on a different host. The return receipt uses the same custodial delivery option used in the bundle that caused the return receipt to be sent. (Return receipts are never issued with the return receipt delivery option requested.)
The third and fourth delivery options are used for diagnostic purposes, and may not be available to all users, subject to local policy. These two delivery options result in notifications being sent to the reply-to application. The first causes a notification to be sent every time a bundle is forwarded. The second option causes a notification to be sent every time a custody transfer occurs.
Cerf, et al. Expires October 2002 [Page 21] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
4.5 Naming and Addressing As described in section 3.4, bundle applications refer to one another using tuples. The tuple consists of three parts: a region identifier an entity identifier, and an instance identifier. DTN regions will be discussed in more detail in section 5.2, but they are named by applications using syntax identical to that used in the domain name system (DNS). (That is, hierarchical tree structure, dot-separated text node names, left to right progresses from leaf to root, sibling nodes must have different names.) When a region is served by the Internet's Domain Name System distributed database, DTN region names may or may not be stored in that database. The bundle layer may translate region names to a bundle-layer-specific region address for transmission. The scope of the region name space and region address space spans an entire DTN, and name-to-address translations of DTN regions must be consistent and reversible throughout the DTN. The second and third parts of a tuple (the entity and instance identifiers) are opaque outside the region specified by the tuple's region identifier (the "home region" for the entity). In internet- served regions, these may be a hostname and port or combined into a URL (depending on the region's internal rules). In diffusion-routed regions, they may be an expression of interest [estrin]. In any case, no attempt shall be made by the bundle layer to bind the entity ID to an address from any location outside the entity’s home region. Discovery of valid DTN region names, entity names, and instance identifiers is out of the scope of this document.
5 Topological Considerations: Nodes, Regions, and Gateways This section describes the three key topological elements in the DTN architecture and how they are related: DTN nodes, DTN regions, and DTN gateways.
5.1 Nodes A DTN node (or "node" in this document) is an engine for sending and receiving DTN messages (bundles). DTN nodes may act as sources, destinations, or forwarders of bundles. Nodes are identified by a tuple containing their region identifier and their entity identifier.
The identifier for a DTN node, meaning the bundle sending and receiving engine itself as opposed to an application *using* that engine, is accomplished in a region-specific manner using the entity identifier and instance identifier.
5.2 Regions
The following list identifies the requirements for DTN regions:
Cerf, et al. Expires October 2002 [Page 22] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
− Each DTN region shall have an identifier space that is shared by all DTN nodes within the region. A region must specify the naming conventions to be employed within that region for entity identification.
− Each node that is a member of the region shall have a unique identifier drawn from that identifier space.
− To be considered a member of a region, each prospective member of the region shall have the ability to reach every other member of the region without depending on any DTN nodes outside the region. (Although a DTN node may not necessarily be *directly* reachable. This may require forwarding and/or store-and-forward operation across one or more connectivity changes.)
A DTN region is a generalization of the notion of a "network" that relaxes the assumption of real-time end-to-end connectivity within a region.
DTN regions may be created for a number of reasons. Accommodation of tailored support for a particularly challenging networking environment is one reason for defining a DTN region. Delimiting a particular security boundary may be another reason for defining a DTN region boundary.
5.3 Gateways A gateway is an entity that has membership in two or more DTN regions and relays messages between regions.
Entities that reside (only) in one region can only send messages to entities in other regions with the assistance of one or more DTN gateways.
5.4 Discussion DTN nodes may act as "hosts," meaning entities that send and receive bundles, but do not forward them. DTN nodes may also act as "routers", meaning they perform the functions of a host, but also forward bundles within a single region. Finally, DTN nodes may act as gateways, forwarding bundles across region boundaries. A single DTN node may act in any of these roles simultaneously.
As members in a store-and-forward chain, DTN nodes have the responsibility for resource allocation to support bundle transfers. These resources include, among other things, buffer space and transmission capacity.
Additionally, DTN nodes have the responsibility of actually executing the bundle transfer. Reliability requirements for bundle transfers
Cerf, et al. Expires October 2002 [Page 23] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
are specified by the using application, and include both reliable and unreliable transfers. The DTN nodes are responsible for using whatever reliability mechanisms exist in the underlying (transport- and-below) layers, and augmenting those mechanisms with bundle-layer mechanisms to effect the required reliability. We require that each DTN region have a unique identifier that is known among all regions in the DTN. The entity identification rules for a particular DTN region have scope only within that region, and are opaque outside that region. However, all DTN nodes within a region must know and conform to the entity identification rules in order to successfully communicate.
6 Routing considerations Communication within a DTN can be either intra-regional or inter- regional. While this architecture does not prescribe specific methods for the exchange of routing data, it acknowledges the fact that mechanisms for the exchange of intra-regional bundle routing data may well be quite different from the mechanisms to exchange inter-regional routing information. Further, the architecture recognizes that mechanisms for inter-regional transfer in one portion of a DTN may be inappropriate for use in other portions of that DTN, and does not require homogeneity of inter-region routing protocol throughout the DTN.
6.1 Types of Routes DTNs may be required to function in the presence of any or all of the following types of routes. These are presented as information rather than as requirements for all DTNs, although any of these may be required for a *particular* DTN.
6.1.1 Persistent Contacts Persistent contacts are sessions with a neighboring DTN node that are always available or that can be made available on demand. In the IP world, Digital Subscriber Line (DSL) connections are an example of the former, while dial-up connections are an example of the latter.
6.1.2 Intermittent - Scheduled Contacts Scheduled routes are those where there is an agreement to establish a link between two points at a particular time, for a particular duration. Attributes of that link, such as its data rate, probability of loss, and the routing metrics to destinations via that link, are routing protocol-specific.
An example of a scheduled route is a link that uses a low-earth orbiting satellite. A schedule of view times and durations can be constructed when next-hop neighbors are accessible via the satellite. Cerf, et al. Expires October 2002 [Page 24] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
6.1.3 Intermittent - Opportunistic Contacts Opportunistic contacts are those that are not scheduled, but rather present themselves unexpectedly. Such contacts could be with an aircraft flying overhead and beaconing, advertising its availability for communication. Other types of contacts might be via infrared communication link between a personal digital assistant (PDA) and a kiosk in an airport concourse offering bundle service as the PDA's owner walks by. If the PDA's owner authorizes it, the PDA could communicate the owner's planned path and a desire for contacts with subsequent kiosks in the concourse, resulting in a set of probable contacts for which bundle transfers can be scheduled.
6.1.4 Intermittent - Predicted Contacts Predicted contacts are those that are based on no fixed schedule, but a history of opportunistic contacts that suggests that contact with an intermittently-connected neighbor will probably occur within a certain period of time and will probably last for a certain duration. Given a great enough certainty that the contact will occur, a DTN node may allocate bundles to that predicted contact period that would be allocated to different contacts otherwise. In the previous example, the probable contacts in the airport concourse would result in the establishment of a set of predicted contacts of a given duration (perhaps based on the PDA owner's walking speed and the kiosk's coverage area). The PDA could decide how to use those contacts for transmitting waiting bundles, as well as perhaps to request bundles that were awaiting delivery at any of a number of store-and-forward points to which the user had access. The algorithms for establishing the predicted time and duration of a contact, the degree of uncertainty in those estimates, the time at which to abandon the wait for a predicted contact, and the guidelines for allocating bundles to such contacts are all open research areas.
6.2 Store-and-forward operation While IP networks are based on "store-and-forward" operation, there is an assumption that the "storing" will not be for more than a modest amount of queuing and transmission delay. In contrast, the DTN architecture does not expect that an outbound link will be available when a bundle is received, and expects to store that bundle for some time until a link does become available. We anticipate that most DTN nodes will use some form of persistent storage for this -- disk, flash memory, etc.
All DTN forwarding nodes ("DTN routers"), even those that do not provide custodial operations as described in section 3.8, must be able to queue bundles until outbound contacts are available. DTN forwarding nodes and DTN gateways that also provide custody transfer Cerf, et al. Expires October 2002 [Page 25] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
operations must provide for longer-term storage of bundles, committing to store bundles for which it takes custody for the entire remainder of their lifetime, if necessary. It is entirely possible that a custodian will need to "take a break" from further custodianship while it completes pending custodial operations and recovers persistent storage. Two mechanisms support this: First, the node can simply forward incoming bundles without taking custody. The fact that a node is potential custodian is no guarantee that it will take custody of any given bundle that is routed to it. Second, the node can revise its advertisement of custodial capability in routing updates (see section 6.4). This is a longer-term solution, but has the attractive property that DTN nodes searching for a custodian do not route a bundle out of its way vainly in search of custodianship at the node in question.
6.3 Contact-oriented routing Making routing decisions to allocate bundles to future contacts requires a DTN forwarding node to probabilistically estimate what the connectivity to other points in the network will be via that contact. We do not yet have a significant body of experience with this, but suspect that maintaining a weighted average of previous routing metrics and developing an uncertainty metric will be useful. Based on the expected connectivity to the remainder of the network from each of these intermittent contacts, and similar characterizations of connectivity for persistently connected neighbors, a DTN forwarding node can make decisions about how to allocate bundles to contacts.
One could think of this allocation of bundles to contacts as being made by creating an ordered list of references to the bundles in persistent storage and providing that list to the lower layer protocol (or to the convergence layer) for transmission at the start of a contact. (We refer to such a list of bundles as a "contact list.") Bundles not transmitted during the contact could be returned on the list for allocation to subsequent contacts. With such an approach, the bundle layer is certainly free to adjust the allocation of bundles to future contacts, based on the receipt of new, possibly high priority bundles. It is also possible that the bundle layer could make changes to a contact list during the course of a contact, if the implementation permitted.
6.4 Routing protocols We have not yet developed routing protocols for this architecture, but envision the need for at least two: one to support inter-region routing, and at least one to support intra-region routing. Realistically, there will probably be more than two. It is likely that an inter-region routing protocol for a network having one or more links with 40-minute one way delays and two-week link outages (such as might be encountered in a deep-space mission) would be Cerf, et al. Expires October 2002 [Page 26] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
wholly different than an inter-region routing protocol to support a sensor network connected to the Internet via a low-earth orbiting satellite. Our current thinking in routing protocols to support intermittent connectivity is to maintain one-hop link state information and a distance-vector type of aggregation beyond one hop. We feel that attempting to maintain an "accurate" picture of network connectivity beyond one hop when routes are composed of scheduled or probabilistic connections of uncertain capacity will be futile. However, we believe that a probabilistic view of connectivity can be built and advertised in a scalable way that permits effective use of these intermittent contacts. The fact that there is no expectation of a contemporaneous end-to-end path makes the overall job seem more feasible. As previously mentioned, this area is teeming with interesting research topics. We intend to address some of these in coming months, but certainly solicit the participation of interested researchers.
7 Security considerations While the particular security problems presented by delay-tolerant networks do not necessarily differ from those presented by other networks, the environment has a significant effect on the available solution space.
In addition to typical end user-oriented security, providing writer- to-reader services such as message confidentiality or end-to-end user authentication, protection of the network infrastructure and controlling access to that infrastructure tend to be important in delay-tolerant networks, which are typically resource-challenged and critical components to mission success. Along with high round-trip times and frequent partitioning, delay-tolerant networks often have low data rate links, making efficiency a necessary consideration in any solution. It is not unusual for delay-tolerant networks to be deployed in places where a portion of the network might become compromised. Such compromise, should it occur, must be limited in scope and the effect finite in duration.
7.1 User-oriented security services We have not received explicit user requirements for the following security services, but anticipate their need. We are as yet undecided whether to provide confidentiality and user authentication as explicit bundle-layer services (a la IPSEC) or to simply make the key management and distribution mechanisms we require available to user applications for them to provide their own confidentiality and authentication (a la PGP, SSL, etc.). Current discussions have focused on using public key cryptographic methods for the bulk of the security services. Cerf, et al. Expires October 2002 [Page 27] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
7.1.1 Confidentiality The confidentiality service attempts to insure that the information content of a bundle is not disclosed to anyone except the intended recipient. If the bundle layer provides the confidentiality service, the intended recipient will be the bundle layer entity at the destination (rather than any specific application). In a public key based system, this requires a high confidence that the sender has the public key of the intended recipient and that said key is unique. The confidentiality service will render all affected portions of the bundle unreadable, so it cannot be applied to fields in the bundle header that are needed for delivery. In general, the bundle user data is covered by the confidentiality service but none of the rest of the bundle header is covered.
7.1.2 User Authentication User authentication is a capability to prove that the bundle has been sent by the entity that claims to have sent it. Typically, an authentication service ensures that the content of the bundle is unaltered as a means to prevent replay attacks. Authentication is accomplished in a public key system by computing a hash of the data to be covered by the authentication, and then encrypting that information with the private key of the sender. If the sender's public/private key pair is uncompromised and the cryptographic algorithm is sufficiently strong, the recipient can apply the purported sender's public key to the encrypted data, recover the hash, and compare it to a hash of the corresponding in formation in the bundle. This allows the recipient to determine if the sender's key is correct (authenticating the sender's identity), and if the data received is identical to the data that was sent (verifying the integrity of the data). Note that this service is required to support the infrastructure security model described in section 7.2, and hence could be made available to end-users to authenticate them to the remote bundle entity at relatively low cost. However, the remote bundle entity will have to request a trusted copy of the purported sender's public key, potentially adding considerable delay to the receipt of the first bundles until a signed copy of the sources public key is received, verified, and cached.
7.1.3 Key Management and Distribution In the public-key-based system under discussion, certification authorities sign keys and may securely place them in an otherwise- read-only distribution facility. Such a distribution facility provides some added assurance that a signed public key obtained from that facility has not been tampered with.
The system in section 7.2 makes use of public keys signed by a trusted authority. It does not explicitly require the availability of a distribution facility to improve the assurance that keys have Cerf, et al. Expires October 2002 [Page 28] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
not been tampered with, but such a facility could be provided. Before deciding to require that (or even strongly suggest that) message recipients acquire signed certificates from a sanctioned distribution facility rather than obtaining the same signed certificate from the owner of the private key, we must carefully examine the costs of providing such a distribution facility in extreme environments. These costs (including the communication costs of maintaining such a facility, the risks of its compromise, and the potential delays associated with accessing it via an extreme network) must be weighed against the benefit of the incremental security that such facilities provide. The results of such a cost-benefit study will likely vary widely from one DTN environment to another.
7.2 Infrastructure security services The following model describes an approach to secure the infrastructure of delay tolerant networks to a modest degree. It is sensitive to the effects of delay and constrained data rates on the ability to provide effective security services and of the effects of the resource requirements of those security services on the ability of the network to support user traffic. This model is preliminary, and like the rest of this document, is still very much a work in progress.
7.2.1 System elements and operation
The candidate system is based on public key technology. Essentially, a prospective user (node, process, whatever) wishing to use the services of the DTN must register its public key with a certificate authority, and receive a copy of that public key signed by that certificate authority and a copy of its infrastructure credentials signed by the certificate authority. Note that this single sentence combines elements of Pretty Good Privacy (PGP) systems, Public Key Infrastructure (PKI) systems, and Kerberos systems. The user generates his own public/private key pairs, as in PGP. The certificate authority (or registration authority) verifies the identity of the prospective user and signs public keys, as in PKI. Additionally, the certificate authority either assigns or acquires in a secure manner and signs a set of infrastructure credentials.
The infrastructure credentials authorize the user to request some DTN classes of service, but possibly not others. The infrastructure credentials also have an expiration time. The user must obtain a new set of infrastructure credentials before the current set expires or else there will be a lapse in the user's access rights to the network.
There may (and probably should) be more than one certificate authority in the network. The effects of a (detected) compromise of
Cerf, et al. Expires October 2002 [Page 29] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
a certificate authority will be discussed in a subsequent paragraph.
This model is described in terms of four types of elements: a user, a DTN router, a DTN interregional gateway (DTN gateway for short), and a DTN certificate authority. We consider the following hierarchy: DTN users and DTN certificate authorities are attached to DTN routers. DTN users are subordinate to DTN routers. For purposes of data transfer, certificate authorities are subordinate to DTN routers, but special authentication rules may apply. A single DTN user may attach to and be supported by multiple DTN routers. (DTN routers support more than one DTN user.) DTN routers are attached to other DTN routers as peers, and are subordinate to DTN gateways. DTN gateways are peers of other DTN gateways. (There may be more structure among the DTN routers within a region, but that is not discussed in this model. The level of organization offered here is adequate to describe the concepts in this security model.) Prior to accessing the network, a prospective user of the DTN must present to a DTN certificate authority its public key (and possibly a large bag of unmarked bills). It obtains from the DTN certificate authority a signed copy of that public key and a signed set of credentials that authorize the user to source data using some subset of the various classes of service offered by the DTN. This set of credentials includes a timestamp that identifies when the credentials expire. A provision is made for a DTN router or DTN gateway to request an initial signed public key and set of credentials on behalf of a remote user. The expiration time on the credentials provides a coarse mechanism to deal with system compromise. Rather than attempt to revoke a set of credentials, they are just not renewed. The expiration time must be large enough that the delays involved in propagating the renewal and response do not result in inadvertent revocation of credentials, and large enough that the network isn't continually flooded with renewal requests. This must be balanced with the effect on the network if a system is compromised and is allowed to continue to consume network resources until the credentials expire. If expiration times are very long, a localized revocation scheme might need to be employed. This scheme would restrict credentials to a single DTN region, and upon a detection of system compromise, issue an explicit revocation of credentials within that region that remains in effect until the expiration time of the revoked credentials.
When a DTN user wishes to send a bundle via a DTN router, it must first present to the router its signed public key and its signed credentials. The router verifies the signatures and stores the public key and credentials in a cache. The cached entry has an expiration time that is the same as the expiration time of the credentials. Prior to the expiration time, the DTN user must present an updated set of credentials to the router in order to continue receiving service. If a DTN user does not have a signed public key Cerf, et al. Expires October 2002 [Page 30] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
and credentials, it may present its public key and some other TBD identifying material to the DTN router and request that the router obtain a signed version of the key and an appropriate set of credentials. The DTN router will pass this material along to a certificate authority requesting that the identification material be verified and credentials be issued. The DTN router will neither route nor enqueue data on behalf of the user until the certificate authority has issued a signed key and appropriate credentials. Once a DTN user has registered with one *or more* local DTN routers, it may source data into the network. The user includes as part of the message header a field that contains a hash of the message content, including timestamp, encrypted in the user's private key. We refer to this information as the signature block. [NOTE: It may not be necessary to compute a hash over the entire message in order to prevent application of these credentials to other messages. Alternatively, one might randomly select an offset and length in the message and compute the hash of that range, and encrypt the offset, length, and hash. This might be beneficial to some computationally challenged nodes for messages larger than some given size.] Upon receipt by the first hop DTN router, the router decrypts the signature block using the sender's public key, and then verifies that the message content matches the hash. This ensures that the sender is who he purports to be. [NOTE: An alternative reality might be that his private key has been compromised. This document does not provide guidance on how to determine if a user's key has been compromised, only what to do once that compromise has been detected.] The DTN router compares the requested class of service against the cached credentials for this user, and decides whether or not to forward the message. If the router decides to forward the message, it generates a new signature block encrypted with its *own* private key, and the requested capabilities are the intersection of the user's request and the router's own capabilities. Depending on what the user has requested during registration with the router, the router-generated signature block either replaces the user's signature block, or is chained to it. [NOTE: The simplest approach is to have the DTN router replace the user's signature block with its own. However, this precludes the establishment of user-specific security boundaries elsewhere in the network. Consider that the DTN model catches on and it becomes broadly adopted throughout the Internet. The decision by a DTN router on, say, a university campus should NOT affect whether that bundle is radiated to a spacecraft in Mars orbit. Rather, a separate security boundary should be established within JPL. The original, source-specific signature block should be used for access control into this area, and therefore must be retained. Regardless of whether the user's signature block is retained, the DTN router's signature block is replaced at each hop. Therefore, the maximum header bloat is one signature block.] In this manner, the DTN router assumes custody of the message from an infrastructure protection standpoint. DTN routers perform the same kind of public key and credentials exchange during router discovery that user nodes
Cerf, et al. Expires October 2002 [Page 31] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
perform with DTN routers. Additionally, a DTN router cannot forward a user message requesting a class of service higher than that which the router is authorized to provide. (It is not clear that restricting a router's authorized capabilities provides distinct advantage. However, if a router cannot provide the full set of capabilities authorized to a particular DTN user, the router should flag that condition during the user's registration.) This model provides the advantage that for the purposes of infrastructure protection, an individual user's public key and signed set of authorized capabilities do not have to be placed throughout the network. Rather, only the DTN routers that are one hop away are required to maintain this material unless there are special security boundaries in the network that cause the user to explicitly request retention of the user signature block. In that case, only the first hop neighbors and the special security boundaries are required to maintain user-specific public key and capabilities material. Each DTN router has a unique public/private key pair and a capabilities-list that are signed by a certificate authority in the same manner that a DTN user's is. The capabilities list has an expiration time (although it may be longer than that issued to DTN users), must be refreshed, and must be exchanged with next-hop DTN routers and DTN gateways. As with DTN users, DTN router public key information need not propagate more than one hop in the network. The preceding DTN router's signature block is *always* replaced after validation.
7.2.2 Discussion In considering the merits of such an approach, some evaluation criteria are beneficial. The criteria on which this approach should be judged are these:
1. How can the system be compromised? 2. What are the effects of compromise, and what is the duration of those effects? 3. Where is state maintained? How is it established? How is it removed? How does it scale compared to the number of users in the system? To the number of infrastructure elements? To the number of trusted authorities? 4. What delays does the system impose on message transmission? 5. What message-size impacts does the system impose? 6. What are the effects of change in various infrastructure elements on users of the system?
This system can be compromised with increasing impact by obtaining the private key of a DTN user, a DTN router, a DTN gateway, or a certificate authority. In the event of compromise, an unauthorized DTN user, router, or gateway will be able to use the resources of the network until the compromise is discovered and the capabilities-
Cerf, et al. Expires October 2002 [Page 32] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
authorization has expired (or an explicit revocation has been issued to its one-hop neighbors for the remaining duration of its capabilities-authorization). It is possible to use a voting scheme to deal with compromise of a certificate authority. (For example, the role of certificate authority may be considered a network capability, and entities claiming to provide that capability may require that their public keys be signed by at least two other certificate authorities. This is notional, and requires significantly more thought.) A DTN router may be flooded by requests from a next hop neighbor, but until that prospective user's signed public key and capabilities list are received from a certificate authority, no router resources will be dedicated to servicing that user beyond those required to identify and discard the traffic. In general, the DTN routers and gateways that are adjacent to a subject entity (DTN user, router, or gateway) maintain state information is maintained about that entity. That state is established through user interaction with a trusted certificate authority and registration with next-hop routing neighbors (DTN routers and gateways). Credentials are accompanied with an expiration time, and state is removed when that time has passed. Additionally, in the event of a discovered compromise, explicit revocation actions may be taken to limit the impact of that compromise. Those revocation actions introduce state into DTN routing entities adjacent to the compromised entity. That state is removed when the expiration time of compromised entity's credentials has passed. The information management requirements for a DTN routing entity scale with the number of next-hop neighbors. Additionally, DTN routing entities must know about at least one certificate authority, but would preferably be aware of several or all, particularly in the case of the previously-mentioned voting scheme among certificate authorities.
This system can impose a registration delay of one round trip between the DTN routing entity and the certificate authority if a prospective DTN user does not have a signed public key and capabilities list. On a per-message basis, the system imposes the delay required to decrypt the signature block, verify the message hash, and either replace or append a second signature block.
The signature block includes the following fields of clear text: 8 bytes of sending timestamp, TBD bytes message hash (and, optionally, 4 bytes offset and 4 bytes length if a hash is computed only over a random subset of the message). The sending timestamp is included to prevent replay attacks. There can be, at most, two signature blocks in a message, and then only when explicitly requested by the DTN user. The sending timestamp is included in the clear text of the signature block as a premature optimization that assumes that computing a hash over the immutable part of the bundle header and a second hash over the payload will be larger than just including 8 Cerf, et al. Expires October 2002 [Page 33] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
more bytes. A further assumption is that the hassle of physically coalescing this information in order to compute a single hash is not worth it. The encrypted size of the signature block is algorithm and data specific. If infrastructure elements (DTN routers, gateways) change during the course of operation, registration by next-hop neighbors of these new elements will be required, but may use existing signed public keys and capabilities lists.
8 Reliability Considerations The bundle layer depends on underlying transport services to provide hop-by-hop reliability. In this context, "hop-by-hop" means from one DTN node to the next. Those nodes may be separated by *many* hops in an underlying network, and the DTN architecture intends to exploit the reliability, flow control, and congestion control capabilities of those underlying networks. However, some significant reliability issues remain at the bundle layer. This section discusses the issues that we have currently identified.
8.1 Custodial Operation One of the fundamental tenets of the DTN architecture is that we must be able to provide reliable end-to-end message transfer via an infrastructure that may *never* be connected end-to-end contemporaneously.
Because no single transport-layer protocol operates end-to-end across the IPN, end-to-end reliability can only be assured at the bundle layer. At each node along an end-to-end route, the bundle-layer protocol entity passes bundle data to the Transport layer for transmission. Each bundle layer entity is highly confident that the transport layer will successfully convey the data entrusted to it to the next bundle-layer protocol entity (which may "take custody" of the data or merely relay it; a single hop). But failures are possible (e.g., a host computer does an unplanned reboot).
A bundle custodian makes a commitment to store the subject bundle until one of two events occurs: another DTN node accepts custody of the bundle, or its time to live expires. The bundle layer attempts to deal with bundles atomically and independently of other bundles. In this model, positive acknowledgement of a bundle is possible, but negative acknowledgment is not. We consider the opportunity to *not* deal with partial bundles a significant plus. Since the underlying transport protocols are working on our behalf, we do not consider the lack of a negative acknowledgment capability a significant minus. (Note that there actually *is* a circumstance in which a negative acknowledgment can be sent -- when the time to live for a bundle expires. However, at that point, *all* copies of the bundle, including those stored at a custodian, are purged from the network. A "timed-out" error can be sent to the source, which *might* be able Cerf, et al. Expires October 2002 [Page 34] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
to cause either an application layer retransmission or a bundle-layer retransmission (see section 8.2, below). Without a negative acknowledgment mechanism, retransmission must be accomplished solely via timer expiration. The bundle layer’s confidence in the effectiveness of the underlying transport-layer protocols is reflected in the design of the timers for bundle-layer reliability. These timers are highly optimistic – that is, they expire as late as possible – in order to give the transport protocols every opportunity to complete reliable transmission. The effect of this optimism is to minimize the chance of unnecessary bundle-layer retransmission, which could seriously degrade DTN performance by consuming valuable bandwidth.
8.2 End-to-end Retransmission The availability of timer-based retransmission and acknowledgment mechanisms to support custody transfers means that the mechanisms to support end-to-end retransmission at the bundle layer are essentially available for free. If a DTN user has requested both custodial transfer and the return receipt delivery option, it is reasonable to assume that end-to-end retransmission would be appropriate if, for some reason, the custody transfer operation failed. However, for timer-based retransmission, we must set the retransmission timer to some reasonable value to account for the diligent efforts and ultimate failure of the underlying transport protocols to succeed in either the end-to-end transfer or the end-to-end return receipt. For custody transfers, appropriate retransmission timer setting is less of an issue, since presumably the transfer is between the current custodian and the next-hop custodian traverses fewer hops carried by underlying transport protocols. One could reasonably expect better predictions of this round trip time than one could for an end-to-end transfer.
The result is that a conservative (optimistic) retransmission time out value for an end-to-end transfer will likely be VERY large. And that value plus the anticipated end-to-end delay for a retransmitted bundle must be less than the time to live for the user's data or else the retransmitted data will time out in transit. If a bundle timed out in transit and the source received the indication of that error, the bundle layer could respond with an end-to-end retransmission, assuming that the remainder of the application's statement of the time-to-live for that bundle to have a reasonable chance of end-to- end transfer success.
So, while we believe that the mechanisms are available to effect end- to-end retransmission, we are unsure whether it will be of value in all DTN environments. It is possible that it may provide value in certain environments, and we will continue to consider whether it should be provided as an implicitly-requested capability when users request both custody transfer and return receipt. Cerf, et al. Expires October 2002 [Page 35] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
8.3 Congestion Control at the Bundle Layer DTN nodes that provide forwarding services are subject to congestion. There is no guarantee that outbound data rates will always exceed inbound rates, and even though these nodes will probably be built with considerable storage, it can fill up. Currently, we have two mechanisms for dealing with congestion in custodians. First, a congested custodian may simply not take custody of incoming bundles, and rather just forward them on toward their ultimate destinations, possibly by way of a nearby custodian. Second, the congested custodian may cease to advertise its status as a custodian via whatever routing protocol is in use. Although these techniques may eventually allow a congested custodial node to recover some of its storage, they do not address the problem that arises when the volume of inbound non-custodial bundles exceeds the capacity of the outbound links for a sustained period of time. We have not yet defined techniques to explicitly accommodate this situation, but feel that they are required. Whatever techniques we do ultimately define must take into account the fact that in the DTN environment, the control loops for congestion control tend to be long, allowing less agile control. We must develop techniques that anticipate congestion events sufficiently in advance of their manifestation that controls can be effective before significant data loss occurs.
9 State Management Considerations An important aspect of any networking architecture is its management of state information. This section describes the state information that is part of the bundle layer, and discusses the conditions under which that state information is established and how it is removed.
9.1 Application Interface State Although it is implementation-specific, it is very likely that application-programming interfaces (APIs) to the bundle layer will be stateful. In long/variable delay environments, an asynchronous interface seems to be the only sensible approach, and such interfaces involve registration actions that create state information. This information is typically created by explicit request of the application, and is removed by a separate explicit request (or, possibly, upon termination of the application).
Since operation in a DTN environment means that delays might be quite long, it is reasonable to expect that an application instance might terminate (voluntarily or not) between the time that a bundle is sent and the time its response is received. The application interface to the bundle layer will, in most cases, provide a mechanism to reinstantiate applications that have terminated, assuming the Cerf, et al. Expires October 2002 [Page 36] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
application has been written to take advantage of such a service. When a DTN node that is the destination of a bundle receives a it, the bundle layer attempts to deliver it to the destination application instance indicated in the destination tuple. If the application instance is unavailable for immediate delivery (for example, it runs as a result of a "cron" job), then state is created pending delivery of the bundle. That state is removed on successful delivery of the bundle to the application instance or on expiration of the time to live in the bundle. Note that if the return receipt delivery option is enabled for a bundle, that return receipt is not generated until the bundle has been successfully delivered to the destination application. Note that in some DTN environments, delays might REALLY be long, and bundle layer operations may be required to operate across system reboots, host changes, or possibly even operating system upgrades. To facilitate this, some bundle layer implementations will employ various forms of persistent storage for their state information, and will avoid operating system attempts to "clean up" state information.
9.2 Bundle retransmission state State information to support bundle retransmission is created at a DTN node as a result of either of two events: First, state is created when a bundle is received from a DTN user application requesting custodial transmission (assuming that DTN node is capable of supporting custodial operation). Second, state is created when a bundle is received from a peer DTN node and the receiving node intends to assume custody of the bundle.
In the first case, recall that applications may indicate a bundle time to live that is greater than that which is allowed in the network. (For example, a DTN application may legitimately feel that its data has value for a century or more, while the DTN that is carrying it doesn't want a particular bundle to potentially be in transit for that long.) The bundle layer may reduce the time to live value in the bundle itself to a value that is consistent with network operation rules. The bundle layer at the source *should* retain the information about the application's view of the bundle's valuable lifetime. In the event that a bundle *transmission* times out before custody is assumed, the bundle layer *may* restart the bundle transmission procedure. This highlights the need to be careful to ensure that bundle acknowledgments have a high probability of receipt, to avoid spurious retransmissions of bundles. At the source, the state associated with a custodially transmitted bundle is removed when a custody transfer acknowledgment is received, or when a period of time subject to local policy has elapsed.
For the second case (that of an in-network custodian) state information is removed when a custodial acknowledgment for the bundle Cerf, et al. Expires October 2002 [Page 37] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
is received or when the time to live field in the bundle has been exceeded.
9.3 Bundle routing state Routing tables, whether statically configured or maintained by routing protocols, introduce state information that must be managed. If the general approach to maintaining routing information is as described in section 6.4 (that is, maintaining link state information for next-hop neighbors, and distance vector information for points beyond), then we can make some basic statements about the amount of state information that must be maintained. For persistent links, in the worst case the volume of routing information for inter-region routing scales by (n*R), where n is the number of next hop neighbors and R is the number of regions in the DTN. For intermittent links, the volume of information scales by (c*n*R), where c is the number of contact periods maintained for planning purposes. These values are worst-case. Pruning and aggregation mechanisms can be used reduce the volume of information if necessary. In particular, it is likely that the intermittent links may be reduced to order (n*R) by simply assuming that the distance vector information is constant for all contacts. (There probably will not be enough useful information to do otherwise.) We have not yet seriously considered the routing metrics that we will maintain, so we do not have an estimate for the size of each routing entry. This remains work to be done. Additionally, we have not given significant consideration to intra- region routing, which will likely have different scaling properties. Intra-region routing information will be affected by the number of DTN gateways that are members of the region and by the routing approach used within the region. (By routing approach we mean broadly either proactive, meaning that routes to all possible destinations are maintained, or reactive, meaning that routes are discovered only when necessary and discarded after some period of time.) This also directly affects how and when routing state information is removed from a DTN forwarding node.
9.4 Transmission queue state Transmission queues are maintained within DTN nodes to manage bundles awaiting transmission. Although implementation dependent, this state information will likely include a list of next hop destinations, and for intermittently connected next-hop destinations, a sublist of upcoming contacts. These lists will likely contain lists of bundles for transmission on those contacts. When a new contact is scheduled or predicted with an intermittently-connected next-hop neighbor, a new list is created and made available for population with bundles. Bundles are removed from these lists upon successful transmission. If a contact ends with bundles remaining on the list to be transmitted, they are allocated to subsequent contact lists, and the list for the completed contact is removed.
Cerf, et al. Expires October 2002 [Page 38] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
9.5 Receive queue state Incoming bundles are received from lower layer entities and either placed on a transmission queue (for bundles to be forwarded) or placed in a receive queue (for local delivery). Receive queues are maintained to support demultiplexing of incoming bundles. Again, although implementation-specific, receive queues are likely associated with a particular local application entity. Bundles are removed from receive queues when they have been successfully delivered to their destination application entity. The receive queue itself is removed when an application explicitly requests that its information be purged from the bundle layer (as part of an un- registration action), or when the application entity has terminated without leaving instructions for the disposition of remaining bundles.
9.6 Network management state We acknowledge that network management information is likely to be a necessary part of the operation of delay tolerant networks. We have not, at this point, done a meaningful amount of work in identifying the network management requirements for DTNs or in defining the state to support such management. This remains an item for future work.
10 Convergence Layer Considerations for Use of Underlying Protocols The DTN Architecture provides for the existence of a convergence layer between the bundle layer and underlying transport protocols. The convergence layer manages the protocol-specific details of interfacing with a variety of underlying transport services and presents a consistent interface to the bundle layer. The convergence layer also allows additional capability to be inserted as necessary to augment the services of the underlying transport protocols.
The convergence layer provides an abstraction to the bundle layer in which bundles are delivered atomically. Partial bundle delivery, especially at the end of a contact, is accommodated within the convergence layer. Additionally, the convergence layer may provide performance enhancement services such as the ability to resume a partially-received bundle on a subsequent contact with the same next- hop neighbor (versus starting the bundle transmission over).
11 Bundle Header Information The bundle layer must carry some information end-to-end. This section documents our current thinking on the information that must be carried end-to-end, and notes which of those data elements may be supplied by the application using the bundle service.
* Version Identifier: this is small integer that indicates which version of the bundle protocol is being invoked. * Destination entity name: this is the IPN name of the remote Cerf, et al. Expires October 2002 [Page 39] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
bundle agent, and is a tuple, as described above. It is supplied by the local application using the bundle service. * Source entity name: this is the IPN name of the local bundle agent, and is a tuple. It is supplied by the local bundle service, since a particular host may have multiple names and one may be chosen based on routing decisions or other criteria opaque to the application (as in multihomed hosts). The source name may be returned to the application to support return receipt processing. * Reply-to entity name (optional): a source may anticipate not being able to accept replies, and may use the reply-to name to specify the destination for return receipts and delivery records. * Current custodian name (optional): the bundle protocol supports store-and-forward operation in which the custody of a bundle (that is, the responsibility for ensuring reliable delivery) may transfer from one DTN node to another as the bundle progresses through the DTN. There is not a requirement for *each* DTN node encountered to assume custody of a bundle. As a result, it is necessary to identify the upstream node that has custody of the bundle, in order to acknowledge correct receipt of the bundle and to accept custody of the bundle. * Class of service flags: − an indication that custody transfer is requested, − an indication that a return receipt is requested, − an indication that a delivery record for custody transfers is requested, − an indication that a delivery record for all forwarding operations is requested, − an indication of the priority of the bundle (bulk, normal, or expedited), and − an indication of whether authentication information is present and its type. * Send timestamp: the time that a bundle was presented by the sending application to the bundle layer for transmission. * Expiration time: an offset, in seconds, from the send timestamp that indicates when the bundle shall be purged from the DTN. * Authentication information (optional): access control information to prove that this bundle should be forwarded in the network. * User data: this is intended to be all of the data that the remote entity requires to perform whatever operation is requested. Since the environmental characteristics of a DTN tend to make interactivity difficult, the notion is that all of the information that is required to perform a particular "transaction" would be provided in a single bundle.
Some bundles cause a response to be generated by the bundle layer. Bundle layer responses are sent as bundles with the user data portion replaced by a Status Report, consisting of the following information:
* Source tuple of the subject bundle: this field partially Cerf, et al. Expires October 2002 [Page 40] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
identifies the bundle that is the subject of the Status Report. * Send timestamp of the subject bundle: this field completes the identification of the bundle that is the subject of the Status Report. * Status flags, indicating that: − The subject bundle was received correctly by the source of the Status Report − The source of the Status Report has taken custody of the subject bundle − The source of the Status Report has forwarded the subject bundle − The Status Report contains the time at which the source of the Status Report received the subject bundle − The Status Report contains the time at which the source of the Status Report forwarded the subject bundle * Time of Receipt (optional): the time at which the sender of the Status Report received the bundle. * Time of Forward (optional): the time at which the sender of the Status Report forwarded the bundle.
12 An Example Bundle Transfer
We provide the following example of an end-to-end bundle transfer across a Delay-Tolerant Network. This particular example is based on the Interplanetary Internet: A host on Earth sends a bundle to a destination on Mars. Figure 2 illustrates the network that is the subject of this example – the Interplanetary Internet in this example has five distinct regions interconnected by four DTN Gateways. This example highlights the actions taken by the bundle layer and the interactions of the bundle layer with applications and with underlying transport protocols.
12.1 Rules for forming tuples in the example network As noted in section 4.5, name tuples consist of three parts: a region ID, an entity ID, and an instance ID. Section 5.2 requires that each DTN region have an identifier space shared by all DTN nodes within that region. Section 5.4 requires that each DTN region have a unique identifier that is known among all regions in the DTN. This particular delay-tolerant network is the Interplanetary Internet. In this section we will establish the naming rules that permit interoperation within this network. Note that this is only an example, and that not all DTNs must use this particular region identifier space (subject to the requirements of section 4.5).
12.1.1 Region identification All regions in *this* DTN (the example Interplanetary Internet) must share a region identifier space. Per section 4.5, the DTN region *name* space is hierarchical, dot-separated text, structured such that left to right is leaf-to-root in the tree. The *identifier*
Cerf, et al. Expires October 2002 [Page 41] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
space may be exactly this name space, or a DTN may define a translation from the name to a particular identifier, in the same way that names in the DNS may be translated to Internet addresses. For this example, we will use the *names* as the *identifiers*. The DTN region name space is shown in Figure 1: Root . | The Interplanetary Internet int | The Solar System sol +-----+-----+-+---+-----+ ||||| Region jupiter mars earth venus ipn Figure 1. An Example Interplanetary Internet Region Name Space
12.1.2 Intra-region identification For simplicity in this example, we will assume that all regions use a well-known TCP port in combination with DNS host names as entity identifiers. The bundle layer application resides above this well- known port (which we arbitrarily choose to be TCP port 6769, a currently unassigned port in the registered port space). The interplanetary backbone region, labeled "ipn" in Figure 1, will certainly NOT use TCP as its underlying transport protocol. For the sake of simplicity in this example, let us assume that the protocol used within the interplanetary backbone region uses the same entity identifier space (IP addresses and port numbers) that the remainder of the network uses.
The instance identifier is entity-specific, and for the sake of simplicity, we will assume that this is a process ID. [Note: this is a simple, but quite limiting decision, as it has implications on process reinstantiation and process portability/migration from one entity to the next. We choose it only for simplicity.]
12.2 Example Network Topology at the Region Level
It is important to have some understanding of the routing that is required at the DTN Gateways, so it is important to understand the topology of the network at the region level. Unlike typical terrestrial communications, the Interplanetary Internet's (IPN’s) *long-haul* communication links are directional, mobile, and highly scheduled. This is important, because directionality combined with mobility means that a transmitter and receiver must track each
Cerf, et al. Expires October 2002 [Page 42] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
+------+ | Earth's Internet | | DTN Region: earth.sol | | +---+ | +------/ /|------+ +---+ | |G/W| + +------| 1 |/------+ | +---+ | | The "Backbone" | | DTN Region: ipn.sol | +---+ +---+ +---+ / /|------/ /|------/ /| +---+ | +---+ | +---+ | |G/W| + |G/W| + |G/W| + +------| 3 |/ +---| 4 |/-----+ | 2 |/------+ | +---+ | +---+ | +---+ | | Venus's Internet | | Jupiter's | | Mars's Internet | | DTN Region | | Internet | | DTN region: | | venus.sol | | DTN Region | | mars.sol | +------+ | jupiter.sol | +------+ +------+ Figure 2. An Interplanetary Internet of Five IPN Regions
other in order to establish and maintain a communication link. In the IPN, much of the mobility is due to orbital mechanics and is therefore relatively predictable. However, this means that nodes that we would normally consider to be fixed, such as antennas on the surface of the Earth, are actually highly mobile as a result of the Earth’s rotation and its revolution around the Sun. (In this example, we confine ourselves to our local solar system, and do not consider the motion of our sun relative to celestial bodies outside our solar system.)
We can describe the predictable aspects of node mobility with an ephemeris, a table of the positions of celestial bodies at specified intervals of time. Both a directional sender and receiver must know the other’s position in order to establish a link between the pair.
In addition, these communication resources are highly scheduled. It is not sufficient for a receiver to point at a prospective target and just wait – for example, a terrestrial node will typically have to point at several targets sequentially, and an interplanetary node will typically not have enough power to just wait for incoming messages. Rather, a schedule of communication *opportunities* must be calculated and then refined with planned communication *instances*. A communication opportunity establishes that the endpoints could establish a link if they were pointing at each other at the proper times. We refer to a planned communication instance as Cerf, et al. Expires October 2002 [Page 43] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
an agreement (although not irrevocable) between the two parties to establish contact and communicate for a defined period of time. The protocols for establishing the schedule of communication instances between all pairs of possible communicants will evolve -- from something primarily done manually to something more automated as the real Interplanetary Internet grows. The scheduled nature of connectivity in the Interplanetary Internet, particularly across the deep-space links, means that at the time of a bundle’s arrival at a DTN Gateway, some or all of the possible outbound routes may be "down." The gateway must store the bundle until the appropriate link is available and then transmit the bundle over that link. One of the fundamental differences between the Interplanetary Internet and the terrestrial Internet is this inherent use of store-and-forward mechanisms in routing bundles. With that in mind, let us consider the routing decisions made at some of the DTN Gateways in Figure 3.
12.3 DTN Gateway routing
Bundle routing at a DTN gateway will typically have to deal with a mix of continuously available links and intermittently available links. Routing across a continuously available link is a relatively straightforward activity. Routing in the presence of intermittently available links can be significantly more complex, as the gateway will need to decide not only the next hop destination but also the time at which to send the bundle. Conditions elsewhere in the network may make it more desirable to send a bundle to a next-hop destination that is not yet accessible, even when an alternative route is currently available. This decision process is discussed in section 6.3.
The intermittent links in this example provide connectivity among the DTN Gateways that are part of the ipn.sol.int region. The contacts among gateways in this region are scheduled. As is currently the case, Gateway 1 (the Earth gateway) has scheduled contacts with each of the other DTN gateways in the ipn.sol.int region (the "backbone"), but there is no direct contact among any of the DTN gateways on Venus, Jupiter, or Mars. Recall that this communication uses directional antennas, so it is generally not possible to communicate with two different entities at once unless they are in the same field of view. Power availability on the remote planets is an issue, so transmitters and receivers are turned on only during a contact. Further, the speed of light delays are nontrivial, skewing transmit and receive times between remote gateways. In Table 1, a schedule of contacts is presented that will be used in the example. All times are referenced to Gateway 1. The information in this table is completely hypothetical, and the speed of light delays are plausible, but completely back-of-the-envelope. Those details are perhaps interesting but not the point of the example.
Cerf, et al. Expires October 2002 [Page 44] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
Table 1. Contact schedule for Gateway 1. +------+------+------+------+------+ | Day |Destination | GW1 Send | GW1 Receive | Destination Send | | | | Time | Time | /Receive Time | +------+------+------+------+------+ | Monday | GW3 | 0900-1200 | 0908-1208 | 0904-1208 | +------+------+------+------+------+ | Tuesday | GW4 | 1300-1430 | 1404-1534 | 1332-1502 | +------+------+------+------+------+ |Wednesday| GW2 | 1000-1200 | 1020-1210 | 1010-1210 | +------+------+------+------+------+ Note that any bundles sent by GW3 after 1154 GW1 time cannot be acknowledged before the next contact (which might be the following Monday). Bundles sent by GW4 after 1358 cannot be acknowledged during the current contact. Similarly, bundles sent by GW2 after 1150 cannot be acknowledged during the contact. DTN Gateways 2, 3, and 4 have entries in their contact schedules for the contacts with Gateway 1.
12.4 Systems participating in example bundle data transfer
Figure 3 is a revision of Figure 2 that highlights those portions of the Interplanetary Internet that participate directly in the bundle transfer example. Also shown in Figure 3 are the source and destination for the transfer and the Domain Name System equivalents in the terrestrial Internet (DNS 1), in the IPN "Backbone" (DNS 2), and in the Mars Internet (DNS 3). This figure will serve as the basis for the bundle data transfer example.
Table 2 provides the full host names of each of the primary elements in Figure 4. Recall that in this example all bundle layer applications reside on TCP port 6769. Application instance identifiers, the third part of the DTN name tuple, have been omitted until the applications are discussed in section 12.5.1.
Cerf, et al. Expires October 2002 [Page 45] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
+---+ //| +------+---+ | +---+ Earth's Internet |DNS| + / /|IPN Region: earth.sol| 1 |/ +---+ | +---+ +---+ |SRC| +------/ /|------+ | |/ +---+ | +---+ |G/W| + +------| 1 |/------+ | +---+ | | The "Backbone" | | IPN Region: ipn.sol | +---+ +---+ +---+ / /|------/ /| / /| +---+ | +---+ | +---+ | |DNS| + |G/W| + |DST| + | 2 |/ | 2 |/------| |/+ +---+ +---+ +---+ | | Mars's Internet | +---+ IPN region: | / /| mars.sol | +---+ |------+ |DNS| + |3|/ +---+ Figure 1. Interplanetary Internet showing principal systems. Table 1. Host name tuples (application instance ID omitted). +------+------+------+ | Host | IPN Regions | Host name tuples | +------+------+------+ | SRC | earth.sol |{src.jpl.nasa.gov:6769, | | | | earth.sol} | +------+------+------+ | IPN G/W1 | earth.sol |{ipngw1.jpl.nasa.gov:6769, | | | | earth.sol} | | | ipn.sol |{ipngw1.jpl.nasa.gov:6769, | | | | ipn.sol} | +------+------+------+ | IPN G/W2 | ipn.sol |{ipngw2.nasa.mars.org:6769,| | | | ipn.sol} | | | mars.sol |{ipngw2.nasa.mars.org:6769,| | | | mars.sol} | +------+------+------+ | DST | mars.sol |{dst.jpl.nasa.gov:6769, | | | | mars.sol} | +------+------+------+
Cerf, et al. Expires October 2002 [Page 46] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
12.5 End-to-end Transfer 12.5.1 Step 0: Application instance registration Before the beginning of this example, the all of the bundle nodes in the network exchange their signed key material and credentials with next hop neighbors. These materials are cached for subsequent use. The applications at the source and destination register with their local bundle layers, providing similar key material and credentials to the bundle layer, and receiving in return their application instance identifiers. The destination has registered as a daemon application, and has been assigned its IPN-standardized well-known id of "8." The source has registered as an ephemeral application, and has received the application instance identifier "0x1763421A" (a hexadecimal number).
12.5.2 Step 1: Bundle creation and first-hop transmission
The application on the source host in Figure 3 has data that it wishes to send to the destination on Mars. The exact content of this data is opaque to the bundle transfer, but assume that it contains all of the information necessary to accomplish some desired function. That is, assume that application-specific instruction for storage, handling, error processing, and disposal accompanies whatever data object is to be operated upon. The application invokes the bundle layer, supplying it the information shown in Table 2. Table 2. Information supplied by source application. +------+------+------+ | Item | Value | Description | +------+------+------+ | Destination | {mars.sol, | IPN Name tuple of the | | DTN | dst.jpl.nasa.gov, | destination. Note that appl.| | tuple | 8} | instance ID 8 is supplied. | +------+------+------+ | Source | 0x1763421A | Value used to identify the | | application | | appropriate instance of the | | instance | | source application for | | identifier | | response processing | +------+------+------+ | Class of | Custodial delivery, | The services requested from | | service | normal priority, | the bundle layer. | | | data obsolete in 36 | | | | hours. | | +------+------+------+ | Signature | Opaque | Digital signature of the | | | | app.-supplied information | +------+------+------+ | User data | N/A | | +------+------+------+
Cerf, et al. Expires October 2002 [Page 47] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
The bundle agent verifies the signature, then creates a bundle and stores it in persistent storage (on disk or other non-volatile memory). There are some fields of the bundle header that the bundle agent must supply: the Sending Timestamp, the Source Host name tuple, the Custodian name tuple, and the time to live. (The application may state a time after which the data are obsolete, but the actual time- to-live field in the bundle header uses the application’s data in combination with network restrictions on time-to-live to initialize this field properly.) The bundle layer consults routing tables notes that its next-hop destination to reach the mars.ipn.sol region within the earth.ipn.sol region is ipngw1.jpl.nasa.gov:6769. (Since a host may reside in multiple IPN Regions, the source host name tuple is a function of the outbound route selected. The bundle layer uses this information to complete the Source Host and Custodian name tuples prior to transmission.) Having verified the application's signature, it incorporates this into the authentication information of the bundle header and appends its own credentials, as described in section 7.2. It further notes that it has a continuous connection to that gateway, and transmits the bundle to it, retaining a copy for custodial storage. The bundle layer starts a retransmission timer for the bundle and awaits a custodial transfer acknowledgment.
12.5.3 Step 2: Bundle processing at first-hop destination
When the IPN Gateway {ipngw1.jpl.nasa.gov, earth.sol} receives the bundle via TCP, it checks the signature of the previous router and determines that the bundle has been forwarded by a legitimate source. Further, since this is the security boundary for the Interplanetary Internet, it verifies the signature of the sending application, requesting a copy of the application's public key from a secure distribution service if it does not already have one cached. Having verified that the application is authorized to access the deep-space portion of the Interplanetary Internet, the bundle layer replaces the signature block of the bundle layer entity with its own, leaving the application's signature block intact. Itstores the received bundle on persistent storage (disk). The bundle layer consults the contact schedule, and determines that the appropriate next-hop destination is in the "ipn.sol" IPN Region: {ipngw2.nasa.mars.org, ipn.sol}, and that the next contact is the following Wednesday. The bundle layer manifests the bundle on the contact for that Wednesday.
In considering alternative contacts for the bundle, the dispatcher checks the time-to-live in the bundle, which was 36 hours from the time of initial submission to the bundle agent at the source, to ensure that the route selected is consistent with the time-to-live requirements of the bundle. The bundle transport functionality of the bundle agent in ipngw1 accepts custody of the bundle, updates this information in the bundle header, and informs the source that has done so. The sources bundle agent deletes its custodial copy of the bundle. When the time arrives for contact with the
Cerf, et al. Expires October 2002 [Page 48] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
ipngw2.nasa.mars.org DTN gateway to be established, the convergence layer establishes that contact via the Long Haul Transport Protocol (LTP). When informed that the contact is available, the bundle layer posts its bundles to the convergence layer for transmission.
12.5.4 Step 3: Bundle processing at gateway to destination IPN Region The Mars gateway, {ipngw2.nasa.mars.org, mars.sol}, receives the bundle from the Earth gateway via LTP. It verifies the signature block of the Earth gateway, then replaces that signature block with its own. It stores the bundle in persistent storage and accepts custody of the bundle, signaling back to the Earth gateway that it has done so. When the notification of acceptance reaches the Earth gateway, ipngw1 deletes its custodial copy. The Mars gateway consults its routing tables to find an outbound contact to forward the bundle over. It determines that the appropriate next hop is the destination itself, that the proper transport protocol is TCP, and that the destination is accessible immediately. The gateway verifies that the time-to-live has not expired, and forwards the bundle to the destination.
12.5.5 Step 4: Bundle processing at destination
The destination bundle layer receives the bundle via TCP, verifies the signature block of the IPN G/W2, stores it on its own persistent storage, and accepts custody of the bundle from IPN G/W2. The bundle agent "awakens" the destination application process identified by the Destination Application Instance Handle. This may involve creating a new instance of a server from a daemon process, signaling an idle running process, or reinstantiating a process that has been suspended with its state stored on persistent storage. The bundle agent deletes the copy of the bundle from persistent storage when the application has received it. The destination application may generate an application-layer acknowledgment in a new bundle and send it to the source’s application instance identifier (0x1763421A from Table 2).
12.6 Error Conditions at the Bundle Layer
This section describes the error conditions that may arise at the bundle layer during bundle creation and transport. When these errors occur within the sender’s DTN region, it may be possible to conduct a near-real-time dialog to correct them before the bundle is forwarded. We say ‘may be possible’ because even if two nodes are in the same IPN domain, they may not have real-time connectivity. An example of such a situation would be if a lander were on the opposite side of the planet from its DTN gateway, and used bundles to communicate with the gateway through a low altitude orbiter, with the orbiter itself serving as a bundle agent.
Cerf, et al. Expires October 2002 [Page 49] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
Table 3: Error conditions at the bundle layer. +------+------+------+ | Error | Description | Places where Error can Occur | +------+------+------+ | 1* | Unknown destination region| Source Bundle Node | +------+------+------+ | 2* | Invalid Source App. | Source Bundle Node | +------+------+------+ | 3* | Bundle Parameter Syntax | Source Bundle Node | | | Error | | +------+------+------+ | 4* | Bundle Parameter Semantic | Source Bundle Node | | | Error | | +------+------+------+ | 5 | Insufficient buffer space | Any bundle node | +------+------+------+ | 6 | DNS unreachable | Any bundle node | +------+------+------+ | 7* | Time exceeded | Any bundle node other than | | | | the source | +------+------+------+ | 8* | Source Entity Access | Any bundle node other than | | | Denied | the source | +------+------+------+ | 9 * | Invalid Entity ID in | IPN gateway serving | | | Destination Name | destination DTN region | +------+------+------+ | 11* | Invalid Destination App. | Destination | +------+------+------+ | 12* | End-to-end Access Denied | Destination | +------+------+------+ The errors that can occur at the bundle layer are shown in Table 3. Error numbers marked with an asterisk (*) are reported back to the sending application.
* Unknown Destination Region: This error occurs when the source bundle node is directed to create a bundle destined for an DTN Region that is not recognized. Note that only the DTN Region part of the destination name has to be interpretable outside the destination’s DTN Region. In particular, the entity identifier of the destination name need not be interpretable to the source (assuming the source and destination are in different DTN Regions), so it cannot necessarily be checked when the bundle is created. * Invalid Source Application: If the source application instance handle supplied by the source application is invalid or the source authentication information fails, the source bundle layer responds with an Invalid Source Application error. This might be the case, for instance, if the source application provided an instance handle referencing a system process for which the application didn’t have privileges. Cerf, et al. Expires October 2002 [Page 50] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
* Bundle Parameter Syntax Error: The source bundle layer may check the syntax of some of the bundle-creation parameters (i.e. it may ensure that the end-to-end and DTN access security certificates are well-formed, etc.) If a parameter is found to be syntactically incorrect or obviously and definitely erroneous, the bundle layer will report a Bundle Parameter Syntax Error back to the source that includes, at a minimum, the parameter that caused the error. * Bundle Parameter Semantic Error: If the source bundle layer can identify a particular bundle creation parameter as being well- formed but unserviceable, it will report a Bundle Parameter Semantic Error to the source application that includes, at a minimum, the parameter that caused the error. * Insufficient Buffer Space: If a bundle node does not have sufficient buffer space to accept a bundle, it drops the bundle and generates an Insufficient Buffer Space error. Note that a bundle node may choose to drop lower priority bundles in order to make room for higher priority ones. This error is not propagated back to the source. * DNS Unreachable: If a bundle node needs access to its DNS (or DNS- equivalent) and cannot obtain information from it, it generates a DNS Unreachable error. This information is not propagated back to the source application. * Time Exceeded: If the time-to-live field (either the source- provided TTL or the internal bundle TTL) expires, the source is notified with a Time Exceeded message. These errors are propagated to the source application. * Source Entity Access Denied: This error indicates that the source entity does not have access to a needed resource at a DTN node. The source might not be authorized to use the node at all, or it might not have authorization to use a particular interface required by the bundle. Source Entity Access Denied errors indicate that the source is not *authorized* to use a particular resource; other errors (e.g. Insufficient Buffer Space) indicate that a particular resource is *unavailable* to a bundle. For example, an entity on the surface of a planet might be authorized to communicate, using the bundle protocol, with another entity on the other side of the planet via a low-altitude orbiter that is also an IPN gateway. The sender might not, however, be authorized to send bundles across interplanetary space. In this case bundles sent to the orbiter destined for the other side of the planet would not cause errors, while any bundles with off-planet destination addresses would. Source Entity Access Denied errors are propagated back to the source application. * Invalid Entity ID in Destination Name: Once a bundle has reached its destination DTN Region, the Entity ID part of the destination name can be verified. If the Entity ID of the destination name is not valid, the source is notified with an Invalid Administrative Destination Name error message. * Invalid Destination Application: If the destination bundle layer cannot instantiate the destination application (based on the destination application instance identifier in the bundle), it Cerf, et al. Expires October 2002 [Page 51] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
notifies the source application with an Invalid Destination Application error message. * End-to-End Access Denied: If the bundle destination does not accept the bundle due to an authentication or access-control error, the source is notified with an End-to-End Access Denied Message.
13 Summary
This architecture addresses many of the problems of networks that must operate in extreme environments. It is message based, and uses as an example of service classes those offered by the postal mail system. It accommodates many different forms of connectivity, including scheduled, predicted, and opportunistically connected links. It introduces a novel approach to end-to-end reliability across frequently partitioned and unreliable networks. It also introduces a novel scheme for securing the network infrastructure against unauthorized access. It is our belief that this architecture is applicable to many different types of extreme environments. In subsequent documents, we intend to specify profiles of this architecture that address specific environments in detail. We plan to develop profiles of this architecture for Interplanetary Internetworking (the genesis of the architecture), for Sensor Internetworking, for Military Tactical Internetworking, and for "Snowmobile" Internetworking. In addition to these profiles, our upcoming tasks include precise specification of the constituent protocols in concert with their prototyping and testing. These activities are currently under way.
14 References [NEWARCH] NewArch Project: Future-Generation Internet Architecture. http://www.isi.edu/newarch/ [META] Wroclawski, John T., "The Metanet", Workshop on Research Directions for the Next Generation Internet, May 12-14, 1997, Vienna, VA. http://www.cra.org/Policy/NGI/papers/wroklawWP
[WhynotTCP] "Why not use the Standard Internet Suite for the Interplanetary Internet?" http://www.ipnsig.org/reports/TCP_IP.pdf
[FISHEYE] A. Iwata, C.-C. Chiang, G. Pei, M. Gerla and T.-W. Chen, "Scalable Routing Strategies for Ad Hoc Wireless Networks," JSAC99, IEEE Journal on Selected Areas in Communications, Vol. 17, No. 8, pages 1369-1379, August 1999.
15 Security Considerations Security is an integral concern of the Delay Tolerant Network Architecture. Section 7 of this document, also titled "Security
Cerf, et al. Expires October 2002 [Page 52] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
considerations" is devoted to examining the issues involved in securing the DTN architecture and providing basic security services to DTN applications.
Cerf, et al. Expires October 2002 [Page 53] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
16 Authors' Addresses Dr. Vinton G. Cerf MCI WorldCom 22001 Loudoun County Parkway Building F2, Room 4115, ATTN: Vint Cerf Ashburn, VA 20147 Telephone +1 (703) 886-1690 FAX +1 (703) 886-0047 Email [email protected] Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 179-206 Pasadena, CA 91109-8099 Telephone +1 (818) 393-3353 FAX +1 (818) 354-1075 Email [email protected] Robert C. Durst The MITRE Corporation 1820 Dolley Madison Blvd. M/S W650 McLean, VA 22102 Telephone +1 (703) 883-7535 FAX +1 (703) 883-7142 Email [email protected] Dr. Kevin Fall Intel Research, Berkeley 2150 Shattuck Ave., #1300 Berkeley, CA 94704 Telephone +1 (510) 495-3014 FAX +1 (510) 495-3049 Email [email protected] Adrian J. Hooke Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 303-400 Pasadena, CA 91109-8099 Telephone +1 (818) 354-3063 FAX +1 (818) 393-3575 Email [email protected]
Dr. Keith L. Scott The MITRE Corporation 1820 Dolley Madison Blvd. M/S W650 McLean, VA 22102 Telephone +1 (703) 883-6547 Cerf, et al. Expires October 2002 [Page 54] Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002
FAX +1 (703) 883-7142 Email [email protected]
Leigh Torgerson Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: T1710- Pasadena, CA 91109-8099 Telephone +1 (818) 393-0695 FAX +1 (818) 354-9068 Email [email protected] Eric J. Travis Global Science and Technology, Inc. 6411 Ivy Lane Suite 300 Greenbelt, MD 20770 Telephone +1 (301) 474-9696 FAX +1 (301) 474-5970 Email [email protected]
Howard S. Weiss SPARTA, Inc. 9861 Broken Land Parkway Columbia, MD 21046 Telephone +1 (410) 381-9400 x201 FAX +1 (410) 381-5559 Email [email protected] Please refer comments to [email protected]
Cerf, et al. Expires October 2002 [Page 55]