interplanetary internet (ipn) architecture document · title: interplanetary internet (ipn)...

Cerf, et al. []

IPN Research Group V. CerfINTERNET-DRAFT Worldcom/Jet Propulsion Laboratory<draft-irtf-ipnrg-arch-01.txt> S. BurleighJuly 2002 A. HookeExpires January 2003 L. Torgerson

NASA/Jet Propulsion LaboratoryR. DurstK. Scott

The MITRE CorporationK. Fall

Intel CorporationE. Travis

Global Science and TechnologyH. Weiss

SPARTA, Inc.Delay-Tolerant Network Architecture:The Evolving Interplanetary Internet

draft-irtf-ipnrg-arch-01.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance withall provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet EngineeringTask Force (IETF), its areas, and its working groups. Note that othergroups may also distribute working documents as Internet-Drafts.Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet-Drafts as referencematerial or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.

Abstract

This document describes an architecture for delay-tolerant networks,and is a generalization of the architecture designed for theInterplanetary Internet: a communication system to provide Internet-like services across interplanetary distances in support of deepspace exploration. This generalization addresses networks whoseoperational characteristics conventional networking approachesunworkable or impractical. We define a message-based overlay thatexists above the transport layer of the networks on which it ishosted. The document presents an architectural overview followed bydiscussions of services, topology, routing, security, reliability andstate management. The document concludes with a discussion of end-to-end information exchange, including an example.

http://www.ietf.org/ietf/1id-abstracts.txt

http://www.ietf.org/shadow.html

Internet Draft draft-irtf-ipnrg-arch-01.txt July 2002

Cerf, et al. Expires October 2002 []

Table of ContentsStatus of this Memo................................................ 1Abstract........................................................... 1Table of Contents.................................................. 2Copyright Notice................................................... 3Acknowledgments.................................................... 4Foreword........................................................... 51 Introduction ................................................ 62 Why an Architecture for Delay-Tolerant Networking? .......... 6

2.1 Constraints Posed by Extreme Environments .............. 62.2 Problems with Internet Protocols and Applications ..... 102.3 DTN Principles of Design .............................. 12

3 DTN Architectural Overview ................................. 143.1 The DTN is Based on Message Switching ................. 153.2 DTN Classes of Service Mimic Postal Mail-like Operation 153.3 Regions and Region Identifiers ........................ 153.4 Tuples ................................................ 163.5 Late Binding .......................................... 163.6 The "Bundle Layer" Terminates Local Transport Protocols

and Operates End-to-End ............................... 173.7 Routing ............................................... 173.8 Bundle Layer Reliability and Custodianship ............ 173.9 Security .............................................. 183.10 Time Synchronization .................................. 19

4 Service Considerations: Application Instances and Bundles . 194.1 Networking Style Issues ............................... 194.2 Bundle Lifetime ....................................... 204.3 Classes of Service .................................... 204.4 Delivery Options ...................................... 214.5 Naming and Addressing ................................. 22

5 Topological Considerations: Node, Regions, and Gateways ... 225.1 Node .................................................. 225.2 Regions ............................................... 225.3 Gateways .............................................. 235.4 Discussion ............................................ 23

6 Routing considerations ..................................... 246.1 Types of Routes ....................................... 246.2 Store-and-forward operation ........................... 256.3 Contact-oriented routing .............................. 266.4 Routing protocols ..................................... 26

7 Security considerations .................................... 277.1 User-oriented security services ....................... 277.2 Infrastructure security services ...................... 29

8 Reliability Considerations ................................. 348.1 Custodial Operation ................................... 348.2 End-to-end Retransmission ............................. 358.3 Congestion Control at the Bundle Layer ................ 36

9 State Management Considerations ............................ 369.1 Application Interface State ........................... 369.2 Bundle retransmission state ........................... 379.3 Bundle routing state .................................. 389.4 Transmission queue state .............................. 38



9.5 Receive queue state ................................... 399.6 Network management state .............................. 39

10 Convergence Layer Considerations for Use of UnderlyingProtocols .................................................. 39

11 Bundle Header Information .................................. 3912 An Example Bundle Transfer ................................. 41

12.1 Rules for forming tuples in the example network ....... 4112.2 Example Network Topology at the Region Level .......... 4212.3 DTN Gateway routing ................................... 4412.4 Systems participating in example bundle data transfer . 4512.5 End-to-end Transfer ................................... 4712.6 Error Conditions at the Bundle Layer .................. 49

13 Summary .................................................... 5214 References ................................................. 5215 Security Considerations .................................... 5216 Authors' Addresses ......................................... 54

Copyright NoticeCopyright (C) The Internet Society (2002). All Rights Reserved.



Acknowledgments

John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, JoeTouch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, andCraig Partridge all contributed useful thoughts and criticisms tothis document. We are grateful for their time and participation.

This work was performed under DOD Contract DAA-B07-00-CC201, DARPA AOH912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA ContractNAS7-1407.



Foreword

The term 'sonata' can be applied to a large work in three movementsor to the three sections of a single movement: exposition,development, recapitulation. They resonate with the three acts of amovie or play, the three elements of a primal myth or legend (life,death, rebirth), the cycle of days (daylight, night, then daylightagain) and of the seasons in temperate climates (nice weather, thenwinter, then it gets nice again), the Star Wars trilogy, etc.Basically, in any human experience we start off brightly, full ofenergy and hope; then we experience reality and become thoughtful andreflective, darker and slower; then Something Happens and hope isreborn, our energy returns, and we reach that happy synthesis ofInnocence 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 anumber of different environments, potentially includinginterplanetary internetworking, military tactical networking, andsensor internetworking.

Refined DTN classes of service and delivery options. Introduced a"reply-to" address to have information directed to a third partyrather 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 delaytolerant network infrastructure, based on signed admission controlcredentials.

Added section discussing state information.

Updated bundle header information and end-to-end data transferexample.



1 Introduction

This document describes an architecture for delay-tolerant networks.We present this as a generalization and extension of our ongoing workon the Interplanetary Internet (http://www.ipnsig.org). We have cometo the realization that there are a number of different environmentsthat share essential characteristics for which the architecturepresented herein is appropriate.

The particular approach we employ is that of a message-based overlaythat exists above the transport layers of the networks on which it ishosted.

2 Why an Architecture for Delay-Tolerant Networking?

The existing TCP/IP-based internet, while fabulously successful inmany environments, does not suit all environments. The ability ofthe "TCP/IP suite" to provide service depends on a number ofimportant 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 topacket; and

− that the end-to-end loss is relatively small.

A class of "challenged networks," which may violate one or more ofthese assumptions, is becoming important and may not be well servedby the current end-to-end TCP/IP model. These networks typicallyserve environments in which it is either impractical or impossible toconfigure a communication environment that supports the assumptionson which the TCP/IP suite depends.This section examines some of the constraints posed by extremeenvironments that may result in "challenged networks," and considersthe problems that these environments might cause for common Internetprotocols and applications. Finally, we derive some "principles ofdesign" for the DTN.

2.1 Constraints Posed by Extreme Environments

The kinds of extreme environments that this DTN architectureaddresses constrain both the communication system and theapplications using that communication system. This section describessome 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, telephoneconversations over a terrestrial telephone line are markedly

http://www.ipnsig.org)/



different than telephone conversations that are routed over ageostationary satellite hop. Second, variability in delay can affectapplications and protocols. Consider a stream of packets carryingvoice data over a network. If the delay in the network variesgreatly from one packet to the next, a buffer is required to avoidthe perception of pauses in the reconstructed voice track. If theapplication is hosted on a network with greater delay variabilitythan the application was designed for, the stream will again havepauses, possibly of significant magnitude to make the voice dataunintelligible.

Delays are comprised primarily of three components: propagation delaythrough the medium; queuing delay within relay points, source, anddestination; and clocking delays associated with transmitting anatomic unit of data onto the medium.

Propagation delays can be long due to speed-of-light delays to crosslong distances (e.g., deep space). Alternatively, propagation delayscould be long due to the propagation medium (e.g.,acoustic/underwater). How long is long? Round trip delays to Marsrange between about 16 and 40 minutes at the speed of light.

Queuing delays are affected by traffic and service rate. In extremeenvironments, the service rate of a node may be low due to powerlimitations requiring a slow processor or a long wait while the unitis quiescent. Arrival distributions may cause significantvariability in delays, particularly for heavy-tailed distributions.

Clocking delays accrue each time a packet is transmitted if thepacket was fully received prior to transmission. ("Cut-through"routing, in which the first bits/bytes of a data unit are operatedupon before the last bits/bytes have been received, is a fairly rareoperation). For many types of data, the latency advantages of cut-through routing are more than offset by the reluctance of networkdesigners to forward corrupt data. (Although some types of data areuseful even if partially corrupted.) For data that are not forwardedbefore being fully received (and error checked), clocking delaysaccumulate at each hop in the network. For relatively slow, multi-hop networks, this can result in high per-packet delays, particularlyif packet sizes are large. (Which can, of course, increase queuingdelays for other packets, increasing both the round trip times andthe variability of delay.)

We assume that processing delay, another contributor to overalldelay, is comparatively low, and is therefore not discussed here.

Variability of delay can have a significant effect on communicationin addition to absolute delay. Many protocols attempt to providereliability through retransmission (ARQ) mechanisms. Timers are acritical element of most retransmission mechanisms, and establishinga retransmission time out value is an important aspect of themechanism. Some protocols, particularly those at the link layer,



have the ability to eliminate all components of round trip time otherthan propagation and clocking delays from their timings, and are ableto produce retransmission time out estimates that are quite close tothe actual round trip time. When queuing delay must be consideredand the timing does not have direct knowledge of the delays at all ofthe queues, estimating a reasonable (not too high, not too low)retransmission time out value becomes more complex. A reasonableretransmission time out value is necessary to prevent unnecessarilyretransmitting data (in the case of a timer that is set too low), andto prevent excessive delays in retransmitting lost data (in the caseof a timer that is set too high).

2.1.2 Frequent Partitioning

Network partitioning typically adds to data loss. If losses becometoo severe, applications typically fail. In addition to contributingto loss, network partitioning adds significantly to overall delay ifnodes are configured to store data until the outbound link isrestored. This behavior can also contribute to misordered dataarriving at the destination, which can cause poor performance in someprotocols.

2.1.3 Data rate asymmetry

Data rate asymmetry measures the ratio of forward-path minimumcapacity versus reverse-path minimum capacity. Data rate asymmetryadversely affects protocols using ARQ for reliable delivery byaltering the ACK or NACK return path. This effect has been studiedextensively with TCP, and is discussed below. At a higher layer,request/response applications that have not been appropriately tunedto balance the amount of request versus response traffic can time outwaiting for data to travel across the lower-capacity link. In themost extreme case of bandwidth data rate, the asymmetry is infinite(as is the case with communications to submarines, for example) andthe entire method of using ARQs for reliable delivery is notpossible. In these cases, forward error correction and periodicretransmission are typically used. See [BLMR98] as an example of howsuch techniques are used in the Internet.

Data rate asymmetry can arise due to routing path asymmetry,different forward/reverse path link technologies, or intentionalengineering tradeoffs. Moderate asymmetries in the wired Internetare found most commonly in asymmetric access technologies such as inCATV or ADSL-based subscriber lines. The largest asymmetries forwireless Internet access appear to be prevalent in in-flight Internetaccess systems. The AirTV system, for example, being proposed for2004 and beyond, could provide a ground-to-air speed of up to 45Mb/susing DVB satellite technology with a comparatively anemic air-to-ground bandwidth of a 128kb/s or less using INMARSAT [ARINC]. In thecase of deep space communications, downlink data rate isintentionally engineered to be much greater than uplink data rate.This tradeoff is not surprising given the goal of most science



missions: the capacity demands of downlinking high-resolution imagesand telemetry from a spacecraft dwarf the capacity required to uplinkshort 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 aparticular message of size m bytes across i links assuming anidentical, independently distributed (IID) stationary loss processwith constant bit error rate pe across all intervening forwarders.(In this equation, the carat -- ^ -- indicates exponentiation.) Thismetric, as expressed, does not account for congestive loss but doesaccount for message size and number of cascaded links given a fixedBER. For packet networks, most links employ some form of errordetection, implying that any bit loss creates an end-to-end packetloss. As can be clearly seen from the formula, the end-to-endprobability of successful delivery decays exponentially with path hopcount. Any congestive loss would only worsen the performance, butsome of these networks are engineered with admission control toeffectively eliminate in-network congestion.

For reliable transfer, excessive errors require repair using eithererror correction or retransmission. In the case of end- to-endretransmission, the path can be so lossy as to effectively cause end-to-end retransmission to be useless. Consider the probability ofpacket loss pp = 1 – Pr for some fixed m. Given the assumptionslisted above, the expected number of retransmissions required beforesuccessful delivery is given by: (1-(1-pp)^i)/(1-pp)^i. Consideringa packet error probability of 0.3. In this case, 4 hops requires 3retransmissions, 10 hops requires 34, and 20 hops requires about 1200retransmissions. If a hop-by-hop retransmission scheme were usedinstead, the total number (network wide) number of retransmissions isgiven by i*pp/(1-pp). For the same error probability of 0.3, thenumber of retransmissions for 4, 10, and 20 hops would be 2, 5, and9, respectively. Thus, for very lossy environments, an end to endretransmission strategy will not provide satisfactory performance.

2.1.5 Interoperating Among Differently-Challenged Networks

A complicating factor in building internetworks comprised of networksoperating in multiple different extreme environments is that there isno guarantee of support for any common communication technology. Inmany instances, at the time of deployment, only the barest minimum ofcapabilities can be fielded to support the given mission. If thesenetworks are successful, they evolve. In many cases, this evolutionleads to an expansion of scope and span for the network. Often thiscan result in a requirement to interoperate with another network inan environment that presents different challenges that have been



addressed by dramatically different solutions.

The ability to operate over many different types of networks thathave been fielded to support extreme environments is both a challengeand a constraint for this Delay Tolerant Networking Architecture.

2.1.6 Examples of some extreme environments

Several types of extreme environments currently exist, with moreappearing almost daily. If one considers the wired Internet, withmulti-gigabit backbones, almost no corruption-related data losses andrelatively short round trip times, then many different types ofenvironments seem extreme.

This architecture was originally conceived to support theInterplanetary Internet, which exhibits round trip delays on theorder of tens of minutes and intermittent connectivity that canresult in disconnection for weeks.

Military tactical networks, in which data rates are low, error ratesare high, and link interruptions are frequent, can likely derivegreat benefit from application of this architecture.

Similarly, sensor networks deployed in oceanic environments exhibitlong delays, significant data loss, and the potential for long linkoutages.

An individual seeking a networking solution for a particularlyintriguing and challenging environment has recently approached us todetermine if the DTN architecture was right for the followingenvironment. A group of widely dispersed communities of people inremote areas is not well served by either wired, fixed wireless, orsatellite internet service. They do, however, frequently travel onsnowmobiles from community to community, and congregate at work sitesand larger towns. To effectively serve this environment, anarchitecture is required that can embrace intermittent, probabilisticconnectivity, store and forward operation, and high and variabledelays. (The architecture described in this document meets theseneeds and more.)

2.2 Problems with Internet Protocols and Applications

This section discusses some of the issues associated with attemptingto serve challenged networks with the Internet suite of protocols.

2.2.1 Internet "Core" Protocols

The performance characteristics of challenged networks contribute toconfound the efficient operation of the core Internet protocols. Bythe ‘core’ Internet protocols we mean IP, TCP, UDP, BGP, common IGPs(RIP, OSPF, or EIGRP) and DNS. These protocols span the services ofend-to-end datagram delivery, reliable two-party stream delivery,



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 togetheras core protocols for the purposes of discussion.

Excessive latency affects TCP directly by severely limiting itsthroughput performance or interfering with connection establishment[DMT96]. Any application-layer protocol using TCP as its underlyingtransport is therefore affected (BGP and DNS zone transfers).Excessive latency also adversely affects the proper operation ofconventional routing protocols as links will be incorrectlydiscovered to be non-operating when soft-state refreshes are delayedtoo long (RIP), or a lack of response to link state “hello” messages(OSPF, EIGRP) is observed. UDP is not sensitive to excessivelatency because it does not contain timers that affect its operation.However, core application protocols that require it (DNSqueries/responses plus SNMP if used) will take too long to completewhen faced with excessive delay, triggering early application failure(or the lack of ability to use DNS name/address mappings in the caseof address-to-name queries).

Data rate asymmetry adversely affects TCP by altering the smooth flowof acknowledgments. Extensive studies have been conducted on TCPusing the normalized asymmetry ratio, which takes into account theasymmetric message sizes between data packets and returning ACKS[MLS00]. Results indicate that bandwidth asymmetry can lead to poorperformance of unidirectional transfers due to alterations in thetime series of the ACK channel. In particular, if ACKs are queued,their spacing in time causes the TCP sender to clock out subsequentpackets less frequently. If ACKs are lost, burstiness, slowcongestion window growth, or defeating of the fastretransmit/recovery algorithms can occur. (See [PILC-ASYM]characterization of this problem and some possible approaches toameliorate it). Any application layer protocols attempting to useTCP 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 willcontinue retrying with a backed-off retransmission timer until itgives up on retransmitting altogether and closes the connection.Somewhat more moderate losses will contribute to problems invokingthe fast retransmit and recovery algorithms, even in the presence ofSACK. IP performance can be affected by path loss if fragmentationis required. IP provides no mechanism for fragment retransmission,thereby causing the overall probability of successful datagramdelivery to be further reduced if datagrams are fragmented [M95].

Node longevity affects the probability of end-to-end delivery, asround-trip or even one-way delivery time of a particular message mayexceed the sender’s lifetime. Clearly, in such cases it is uselessto arrange for immediate acknowledgements to be returned. In such



cases, any notification of successful or unsuccessful delivery needsto 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 differentapplication protocols, including HTTP, SMTP, POP, IMAP, Microsoft’sExchange Protocol and FTP. These protocols, or in some cases theapplications that implement them, are either severely degraded orfail to operate entirely under challenging conditions. Two primaryreasons are application-level timeouts mismatched to the actualnetwork latency, and an excessive number of round-triprequest/response message exchanges required in order to accomplish aprotocol transaction. For example, web browsers and mail clientswill often time out during connection establishment after a minute ortwo. The SMTP protocol requires each peer to mutually identifyitself prior to actually exchanging the mail payload, even thoughthis early name exchange is not fundamental to the process ofdelivering e-mail. Such protocols have been called “chatty” due totheir excessive number of round-trip times required to accomplish asimple task. FTP has a similarly chatty interaction during itsinitial association as it exchanges user login and authenticationinformation.

2.2.3 Discussion

When considering the use of existing Internet protocols as a basisfor interconnecting challenged networks, certain properties of theoperational environment seem insurmountable. The possibility thatonly a one-directional path is available at any given time appears topreclude the use of conventional TCP-like protocols based on ARQ forreliability because an ACK channel may not be available. Withexponentially decaying probability of successful end-to-end deliveryas path length grows, end-to-end reliability should be avoided infavor of hop-by-hop retransmission in lossy environments. Given thepossibility of very high round-trip times, any expectation of timelyresponse in request/ response protocols must also be avoided.Finally, the regular Internet routing protocols assume the immediateexistence of an end-to-end path and do not accommodate the notion offuture (scheduled) routing opportunities that are needed foroperation in frequently disconnected environments.

2.3 DTN Principles of Design

After examining the environmental conditions cited above and seeingthe problems that the Internet protocols have with these conditions,we derived the following principles of design to guide the definitionof a Delay Tolerant Networking Architecture.



2.3.1 Use transport and network layer technologies appropriate to thelocal environment

Where Internet protocols work well, there is a distinct advantage tousing them. However, in other environments, such as sensor networksor certain radio networks, the internet suite may not be the best fitfor the task at hand. Some sensor networks, for example, use verydifferent routing and node naming concepts. The DTN architectureshould not restrict designers in building networks using transport,network, link, and physical layer technologies that are best suitedfor their environments. Rather, the DTN architecture should providethe means for dissimilar networks to interoperate. Whereas IPprovides the common substrate for the Internet above dissimilar linklayers, the dissimilarity of the extreme environments discussedprecludes the use of a single end-to-end transport protocol.Instead, end-to-end operations require us to provide a commonsubstrate above the *transport* layers of the constituent networks.Thus, the DTN architecture creates a "network of Internets" byproviding an end-to-end layer above the transport layer. We callthis 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 avoidedin the kinds of extreme environments described above. Rather, entireapplication-layer messages, which we call "bundles," move through thenetwork as units. These bundles are intended to have all of theprimary data and meta data necessary for their use at thedestination. 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 anddestination (e.g. "user:", response, "password:", response, etc.)when such exchanges can be "bundled" together into a singlecommunication.

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 istypically only long enough to determine the next hop destination andto wait for any packets to be transmitted that are ahead of thecurrent one. If no route to the destination exists at the point intime that the routing engine examines the packet, that packet istypically discarded.

In a Delay-Tolerant Network, it is considered *normal* for there tobe no path to the destination at the time a bundle is received.Bundles are routed based on the expectation of connectivity, eitheras a result of a firm schedule or previous experience. If an episodeof connectivity doesn't materialize, bundles are reroutedaccordingly. This approach assumes that there is a considerable



amount of storage available within the network, which is afundamental assumption for these types of delay-tolerant networks.

The result of this interpretation of store-and-forward operation isthat bundles of data can still make forward progress toward theirdestination even if a contemporaneous end-to-end path *never* exists.

2.3.4 Use custody transfer to advance the point of retransmissiontoward the destination

Upon receipt of a bundle, a node may *take custody* of it. This is acommitment made by the accepting-node that it will shoulder theburden of retransmission to insure that the bundle reaches itsdestination. This allows the source (or previous custodian) torelease the resources necessary to ensure delivery and moves thepoint of retransmission closer to the destination. The notion isthat by moving the point of retransmission forward, retransmissionswill be faster and will consume fewer network resources than if theyhad to come from the information source.

There is an obvious benefit to this approach if the point ofretransmission progresses across a *very* long delay hop (such as onethat spans interplanetary distance). However, in a network composedof a series of lossy links (such as a congested multi-hop wirelessnetwork), there is similar benefit, as discussed in section 2.1.4.

2.3.5 Provide security services to secure both the infrastructure andthe information

Networks in extreme environments may range from being completelydisposable to irreplaceably precious. Those that are disposable aretypically so resource starved that difficult tradeoffs must be maderegarding provision of service versus protection of infrastructure.These tradeoffs must be made by those who instantiate thearchitecture, and the architecture must provide for a range ofdecisions.

Minimally, we have concluded that the architecture must provide forinfrastructure protection, up to and including mutual suspicion amongDTN routers. However, this must be optional at the discretion ofthose who actually instantiate a particular delay tolerant network.Security services offered to users should include key management,authentication, integrity, and confidentiality, but availability anduse of those services may vary from DTN to DTN.

3 DTN Architectural Overview

The previous section presented the design principles that guide thedefinition of the DTN architecture. This section presents anoverview of the decisions that result from those design principles.



3.1 The DTN is Based on Message Switching

We note in the design principles that unnecessary interaction betweenthe source and destination should be avoided, and that a combinationof 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 ofthe size and performance requirements of requested data transfers.When there is a significant amount of queuing that can occur prior totransmission over an outbound route (as is the case in the DTNversion of store-and-forward) the advantage provided by thisinformation provided is significant. In an environment thatfrequently experiences network partitioning, messages are efficientunits 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 servicesthat a Delay-Tolerant Network offers. Traffic is generally notinteractive. It may be one-way in nature. There are generally nostrong guarantees of delivery delay.

The DTN Architecture, like the Postal Service, offers *relative*measures of priority (low, medium, high). It may offer basicnotifications, for example: "the intended recipient has accepteddelivery of the message," "the route taken by this message is asfollows..." and "the message has been transmitted."

An essential element of Postal Service operation is that mail has aplace to wait in queue until an outbound hop is available. Thishighlights 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, and4. (implicitly) that this ‘store-and-forward’ model is a better

trade-off than using resources to attempt to effect continuousconnectivity or other alternatives.

For a network to effectively support the DTN architecture, theseassumptions must be considered and must be decided uponaffirmatively.

3.3 Regions and Region Identifiers

The DTN architecture defines a "network of Internets." Each of theseInternets is called a "DTN region." Regions may be delimited bydifferences in network protocol, transport protocol, or addressingmechanism. Regions may also be delimited by other criteria, such as



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*, whichprovide the interconnection points between regions. These correspondto "waypoints" in [META], and to the gateways described in theoriginal ARPANET design [CK74]. DTN gateways differ from ARPANETgateways because they operate above the transport layer, and arefocused on message switching rather than packet switching. However,both DTN gateways and ARPANET gateways provide for the conversionbetween the protocols specific to one region and the protocolsspecific to another.

Region definition and region identification are key concepts in theDTN architecture. DTN bundles that originate outside the destinationregion are first transmitted to one of the DTN gateways that connectthe destination region with one or more other regions. Routingoutside the destination region is done based on the destinationregion's identification, meaning that there is a single regionidentifier space that is common across the end-to-end DTN.

3.4 Tuples

The region identifier described above is sufficient to get a bundleof data to its destination region, but not to deliver it to thespecific entity for which it is intended. The DTN architecture usesa tuple of the region identifier and a region-specific entityidentifier to identify a particular entity in a region. In the DTN,the tuple of {region ID, entity ID, instance ID} fully identifies anapplication instance. The tuple allows us to segregate data intothat which is necessary for routing *across* regions and that whichis necessary for delivery within a region and within a node. As aresult of this, the entity ID and instance ID are *opaque* outsidetheir region of definition. The referenced entity might be a host, aprotocol, an object, or something else. Further, the entityidentifier might be a name, an address, or a descriptor such as aURL. This is a local issue within the entity's region. (If theentity ID is a name, there is an assumption that a name-to-addressbinding function exists within the region to support eventual routingof the bundle to the destination entity.) The instance IDaccommodates the situation in which a particular *instance* of thatentity is targeted, such as with a reply to a query.

3.5 Late Binding

The opacity of entity IDs outside their local region enforces anotherkey concept in the DTN Architecture: that of late binding. Latebinding refers to the fact that the entity ID of a tuple is notinterpreted (e.g., bound to an address) outside its local region.This avoids having a universal name-to-address binding space (and its



associated database and synchronization issues).

This approach preserves a significant amount of autonomy within eachregion. The entity IDs used in bundles might be built on DNS names,or URLs, but they might also be "expressions of interest" as in adirected diffusion-routed network [ref. Estrin].

Additionally, late binding avoids the delay-related issue that thebinding information might be highly ephemeral relative to the transittime of a bundle. We assume that the internal details of adestination network will be sufficiently stable for the duration of atransmission of a message within that region, or that delay-tolerantmechanisms will be employed *within* the region to compensate. (Thisis, by definition, a local issue within the region and may beaccommodated in whatever manner is most practical for that region.)

3.6 The "Bundle Layer" Terminates Local Transport Protocols andOperates End-to-End

The bundle layer is an end-to-end protocol that employs custodytransfers for in-network retransmission (although not necessarilybundle-hop-by-bundle-hop retransmission). The bundle layer makes useof the reliability mechanisms available from the underlying transportlayers of each region, and a single bundle hop *may* span an entireregion.

3.7 Routing

The bundle layer provides routing among DTN-capable nodes, includingDTN gateways. There may be many DTN gateways that interconnectadjacent regions, and there may be multiple bundle routing "hops"within a region (particularly if intra-regional connectivity isintermittent).

Routing exchange mechanisms may differ from one instantiation of theDelay Tolerant Network Architecture to another, reflecting differentneeds and constraints of the extreme environments. Different routingprotocols may be employed for intra-region routing and for inter-region routing. We do not require that the *same* inter-regionrouting protocol run among all (inter-region) DTN gateways in a DelayTolerant Network. (It is required that necessary routing informationbe able to be propagated throughout the DTN, but the mechanisms fordoing 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 acknowledgmentand custodial transfers may be combined for additional reliability.



Reliability services at the bundle layer are relatively simplebecause the bundle layer depends upon the reliability mechanisms ineach of the underlying internets. Bundles are delivered atomicallyand are, generally, independent of other bundles. As a result,positive acknowledgment is possible, but partial or negativeacknowledgment is not. Since delays may be long and/or highlyvariable, retransmission timers must, in general, be coarse and maybe strongly affected by local policy.

Custody transfer, introduced in section 2.3.4, above, allows thesource to delegate retransmission responsibility and recover itsretransmission-related resources relatively soon after sending thebundle. While not every node in a DTN must be capable of providingcustodial services, all DTN gateways (that span two or more DTNregions) are expected to be able to be custodians. This introduces arequirement to be able to discover prospective custodians, selectone, and direct a bundle toward it.

3.9 Security

Resource scarcity in delay-tolerant networks dictates that some formof access control is required. It is not acceptable for anunauthorized user to be able to flood the network with high-prioritytraffic, possibly preventing the network's mission from beingaccomplished. Implicit in this statement is a requirement for someform of admission control and/or in-network authentication that issensitive to the class of service that a user has requested, and themeans to verify that the user is authorized to make that request. Ina low delay environment, this would simply be tedious. In ahigh/variable delay, low data rate environment, it is potentiallymuch worse: access control lists are difficult to update, re-keyingpresents hard problems, and routers or end nodes might becompromised.

Key management presents a number of dilemmas. Keys will almostcertainly require replacement in all but the most disposable ofnetworks. Re-keying and related operations on highly remote nodes ischallenging, and proper approaches to key distribution in thisenvironment remain active areas for research.

The DTN must be able to support end-to-end user services that includeverification of a message's integrity and the ability to provideconfidentiality of a user's message. It must do this in a way thatdoes not require a great deal of interaction across long-delay (orresource-constrained) data links. "Support" for these services mayinvolve provision of a key management service to support user-levelconfidentiality and integrity, or it may involve providing theseservices as part of the bundle layer. This is an area still underconsideration.



3.10 Time Synchronization

The DTN architecture depends on time synchronization for two primarypurposes: routing, and "time to live" computations.

Routing that is based on schedules and dependent upon coordination ofshared assets (such as directional antennas) creates a requirementfor time synchronization. As with many requirements, just how *much*time synchronization is required is an economic trade-off. The costto achieve a particular degree of time synchronization must beweighed against the cost of not having it. The costs of not havingtime synchronization include reduced overall efficiency of acommunication asset, potential loss of user data, power inefficiency,and many others. For some communication assets, such as NASA's DeepSpace Network, the operational cost is many thousands of dollars perhour, and the cost to achieve a modest level of time synchronizationbetween peers is quite justifiable. There is a study currentlyunderway [ref Mills] to examine the time synchronization issuesacross NASA's Deep Space Network and to determine a particular timesynchronization scheme suited to that network.

Given that DTN routing depends to some degree on timesynchronization, the DTN architects have made the decision to exploitits availability. In particular, time to live computations may bedone by including a source time stamp and an explicit time to livefield (in time units after the time in the source time stamp). Thisrequires some level of time synchronization, but since its sole useis for purging data from the network, the synchronizationrequirements are not strict. This approach allows a source timestamp to be used for a number of purposes, such as to prevent replayprotection and to identify individual messages.

4 Service Considerations: Application Instances and Bundles

This section describes the basic services available to applicationsusing the DTN Architecture's Bundle Service. The Bundle Service isthe message-oriented communication service provided by the "BundleLayer" described in section 3.6.

4.1 Networking Style Issues

Before discussing specific Bundle Services, a note about applicationinteraction style is in order. This service is intended to operatein *delay-tolerant* networks. That does not mean that there *must*be delays in the network, or that there *will* be delays, but thatthere *may* be delays. The protocols providing the services exposedby the bundle layer are delay tolerant. Applications using thoseservices should be, too.

Message-oriented communication differs from conversationalcommunication. In general, applications should attempt to includeenough information in a bundle so that it may be treated as an



independent unit of work by the remote entity (a "transaction",although transactions carry connotations of multi-phase commitmentthat we do not intend here). The goal is to minimize conversationbetween application entities that are separated by a network thatpresents long and possibly highly variable delays, and to constrainany conversation that does occur to be asynchronous in nature. Afile transfer application, for example, should incorporate accountinformation, file location information, file operation information,and file content within a bundle, allowing atomic operation on thatbundle. 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 roundtrips to get to a point where file data can flow. [ref. WhynotTCP].

Delay-tolerant applications must consider additional factors beyondthe conversational implications of long delay paths. Applicationinstances may terminate (voluntarily or not) between the time that abundle is sent and the time its response is received. If anapplication has anticipated this possibility, it is possible toreinstantiate the application instance based on state informationsaved in persistent storage. This is an implementation issue, butalso an application design consideration. Similarly, either host orapplication mobility may result in the application's address havingchanged by the time a response is received. If applications embedphysical addresses into their data, they will defeat the potentialbenefits that late binding provides.

Some consideration of delay-tolerant application design can result inapplications that work well in low-delay environments, and that donot suffer extraordinarily in high or highly-variable delayenvironments.

4.2 Bundle Lifetime

Applications are requested to provide an expiration time (actually, atime to live in seconds) for a bundle if the value of the data has afinite duration. If not supplied, or if the user-supplied value islarger than local policy permits, the bundle layer will provide avalue. Note that this value is treated as an actual "time to live" -- it is added to the time that a bundle was submitted by theapplication to determine the time at which the bundle will be purgedfrom the network. Appropriate values depend on the network and thedata, 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 aretransmitted.

We have currently defined three classes of service in the DTN



architecture:

− Bulk - In bulk class, bundles are shipped on an "as possible"basis. No bulk class bundle will be shipped until all bundles ofother classes bound for the same next hop destination have beenshipped.

− Normal - Normal class bundles that are in queue and bound for thesame next hop destination are shipped prior to any bulk class thatare in queue.

− Expedited - Expedited bundles, in general, are shipped prior tobundles of other classes. However, the bundle layer *may*implement a queue service discipline that prevents starvation ofthe normal class, which may result in some normal bundles beingshipped before expedited bundles bound for the same next hopdestination as the normal class bundles.

4.4 Delivery Options

The bundle layer offers a number of delivery options to users. Firstand foremost is the option of custodial delivery. Custodial deliverymeans that a bundle will be reliably transmitted by the bundle layer,and that the point of retransmission will advance through the networkfrom one custodian to another until the bundle reaches itsdestination. The bundle layer depends on the underlying transportprotocols of the networks that it operates over to provide theprimary means of reliable transfer from one bundle layer entity tothe next. However, when custodial delivery is requested, the bundlelayer additionally provides a coarse-grained timeout andretransmission mechanism and an accompanying acknowledgmentmechanism. When a bundle application does *not* request custodialdelivery, this bundle layer timeout and retransmission mechanism isnot employed, and the bundle depends solely on the reliabilitymechanisms of the underlying transport layers.

A second delivery option is the option of a return receipt. Anapplication may request a return receipt for a bundle that is beingtransmitted. When the subject bundle is received *by the destinationapplication* (not simply the destination bundle layer), a returnreceipt is generated by the bundle layer and returned to the sourceor the source's designated alternate (reply-to) application, whichwould typically be located on a different host. The return receiptuses the same custodial delivery option used in the bundle thatcaused the return receipt to be sent. (Return receipts are neverissued with the return receipt delivery option requested.)

The third and fourth delivery options are used for diagnosticpurposes, and may not be available to all users, subject to localpolicy. These two delivery options result in notifications beingsent to the reply-to application. The first causes a notification tobe sent every time a bundle is forwarded. The second option causes anotification to be sent every time a custody transfer occurs.



4.5 Naming and Addressing

As described in section 3.4, bundle applications refer to one anotherusing tuples. The tuple consists of three parts: a region identifieran entity identifier, and an instance identifier. DTN regions willbe discussed in more detail in section 5.2, but they are named byapplications using syntax identical to that used in the domain namesystem (DNS). (That is, hierarchical tree structure, dot-separatedtext node names, left to right progresses from leaf to root, siblingnodes must have different names.) When a region is served by theInternet's Domain Name System distributed database, DTN region namesmay or may not be stored in that database. The bundle layer maytranslate region names to a bundle-layer-specific region address fortransmission. The scope of the region name space and region addressspace spans an entire DTN, and name-to-address translations of DTNregions must be consistent and reversible throughout the DTN.

The second and third parts of a tuple (the entity and instanceidentifiers) are opaque outside the region specified by the tuple'sregion identifier (the "home region" for the entity). In internet-served regions, these may be a hostname and port or combined into aURL (depending on the region's internal rules). In diffusion-routedregions, 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 toan address from any location outside the entity’s home region.

Discovery of valid DTN region names, entity names, and instanceidentifiers 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 DTNarchitecture and how they are related: DTN nodes, DTN regions, andDTN gateways.

5.1 Nodes

A DTN node (or "node" in this document) is an engine for sending andreceiving DTN messages (bundles). DTN nodes may act as sources,destinations, or forwarders of bundles. Nodes are identified by atuple containing their region identifier and their entity identifier.

The identifier for a DTN node, meaning the bundle sending andreceiving engine itself as opposed to an application *using* thatengine, is accomplished in a region-specific manner using the entityidentifier and instance identifier.

5.2 Regions

The following list identifies the requirements for DTN regions:



− Each DTN region shall have an identifier space that is shared byall DTN nodes within the region. A region must specify the namingconventions to be employed within that region for entityidentification.

− Each node that is a member of the region shall have a uniqueidentifier drawn from that identifier space.

− To be considered a member of a region, each prospective member ofthe region shall have the ability to reach every other member ofthe 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 operationacross one or more connectivity changes.)

A DTN region is a generalization of the notion of a "network" thatrelaxes the assumption of real-time end-to-end connectivity within aregion.

DTN regions may be created for a number of reasons. Accommodation oftailored support for a particularly challenging networkingenvironment is one reason for defining a DTN region. Delimiting aparticular security boundary may be another reason for defining a DTNregion boundary.

5.3 Gateways

A gateway is an entity that has membership in two or more DTN regionsand relays messages between regions.

Entities that reside (only) in one region can only send messages toentities in other regions with the assistance of one or more DTNgateways.

5.4 Discussion

DTN nodes may act as "hosts," meaning entities that send and receivebundles, but do not forward them. DTN nodes may also act as"routers", meaning they perform the functions of a host, but alsoforward bundles within a single region. Finally, DTN nodes may actas gateways, forwarding bundles across region boundaries. A singleDTN node may act in any of these roles simultaneously.

As members in a store-and-forward chain, DTN nodes have theresponsibility for resource allocation to support bundle transfers.These resources include, among other things, buffer space andtransmission capacity.

Additionally, DTN nodes have the responsibility of actually executingthe bundle transfer. Reliability requirements for bundle transfers



are specified by the using application, and include both reliable andunreliable transfers. The DTN nodes are responsible for usingwhatever reliability mechanisms exist in the underlying (transport-and-below) layers, and augmenting those mechanisms with bundle-layermechanisms to effect the required reliability.

We require that each DTN region have a unique identifier that isknown among all regions in the DTN.

The entity identification rules for a particular DTN region havescope only within that region, and are opaque outside that region.However, all DTN nodes within a region must know and conform to theentity 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 specificmethods for the exchange of routing data, it acknowledges the factthat mechanisms for the exchange of intra-regional bundle routingdata may well be quite different from the mechanisms to exchangeinter-regional routing information. Further, the architecturerecognizes that mechanisms for inter-regional transfer in one portionof a DTN may be inappropriate for use in other portions of that DTN,and does not require homogeneity of inter-region routing protocolthroughout the DTN.

6.1 Types of Routes

DTNs may be required to function in the presence of any or all of thefollowing types of routes. These are presented as information ratherthan as requirements for all DTNs, although any of these may berequired for a *particular* DTN.

6.1.1 Persistent Contacts

Persistent contacts are sessions with a neighboring DTN node that arealways available or that can be made available on demand. In the IPworld, Digital Subscriber Line (DSL) connections are an example ofthe 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 alink between two points at a particular time, for a particularduration. Attributes of that link, such as its data rate,probability of loss, and the routing metrics to destinations via thatlink, are routing protocol-specific.

An example of a scheduled route is a link that uses a low-earthorbiting satellite. A schedule of view times and durations can beconstructed when next-hop neighbors are accessible via the satellite.



6.1.3 Intermittent - Opportunistic Contacts

Opportunistic contacts are those that are not scheduled, but ratherpresent themselves unexpectedly. Such contacts could be with anaircraft flying overhead and beaconing, advertising its availabilityfor communication. Other types of contacts might be via infraredcommunication link between a personal digital assistant (PDA) and akiosk in an airport concourse offering bundle service as the PDA'sowner walks by. If the PDA's owner authorizes it, the PDA couldcommunicate the owner's planned path and a desire for contacts withsubsequent kiosks in the concourse, resulting in a set of probablecontacts for which bundle transfers can be scheduled.

6.1.4 Intermittent - Predicted Contacts

Predicted contacts are those that are based on no fixed schedule, buta history of opportunistic contacts that suggests that contact withan intermittently-connected neighbor will probably occur within acertain period of time and will probably last for a certain duration.Given a great enough certainty that the contact will occur, a DTNnode may allocate bundles to that predicted contact period that wouldbe allocated to different contacts otherwise. In the previousexample, the probable contacts in the airport concourse would resultin the establishment of a set of predicted contacts of a givenduration (perhaps based on the PDA owner's walking speed and thekiosk's coverage area). The PDA could decide how to use thosecontacts for transmitting waiting bundles, as well as perhaps torequest bundles that were awaiting delivery at any of a number ofstore-and-forward points to which the user had access.

The algorithms for establishing the predicted time and duration of acontact, the degree of uncertainty in those estimates, the time atwhich to abandon the wait for a predicted contact, and the guidelinesfor 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, thereis an assumption that the "storing" will not be for more than amodest amount of queuing and transmission delay. In contrast, theDTN architecture does not expect that an outbound link will beavailable when a bundle is received, and expects to store that bundlefor some time until a link does become available. We anticipate thatmost 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 notprovide custodial operations as described in section 3.8, must beable to queue bundles until outbound contacts are available. DTNforwarding nodes and DTN gateways that also provide custody transfer



operations must provide for longer-term storage of bundles,committing to store bundles for which it takes custody for the entireremainder of their lifetime, if necessary. It is entirely possiblethat a custodian will need to "take a break" from furthercustodianship while it completes pending custodial operations andrecovers persistent storage. Two mechanisms support this: First, thenode can simply forward incoming bundles without taking custody. Thefact that a node is potential custodian is no guarantee that it willtake custody of any given bundle that is routed to it. Second, thenode can revise its advertisement of custodial capability in routingupdates (see section 6.4). This is a longer-term solution, but hasthe attractive property that DTN nodes searching for a custodian donot route a bundle out of its way vainly in search of custodianshipat the node in question.

6.3 Contact-oriented routing

Making routing decisions to allocate bundles to future contactsrequires a DTN forwarding node to probabilistically estimate what theconnectivity to other points in the network will be via that contact.We do not yet have a significant body of experience with this, butsuspect that maintaining a weighted average of previous routingmetrics and developing an uncertainty metric will be useful.

Based on the expected connectivity to the remainder of the networkfrom each of these intermittent contacts, and similarcharacterizations of connectivity for persistently connectedneighbors, a DTN forwarding node can make decisions about how toallocate bundles to contacts.

One could think of this allocation of bundles to contacts as beingmade by creating an ordered list of references to the bundles inpersistent storage and providing that list to the lower layerprotocol (or to the convergence layer) for transmission at the startof a contact. (We refer to such a list of bundles as a "contactlist.") Bundles not transmitted during the contact could be returnedon the list for allocation to subsequent contacts. With such anapproach, the bundle layer is certainly free to adjust the allocationof bundles to future contacts, based on the receipt of new, possiblyhigh priority bundles. It is also possible that the bundle layercould 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-regionrouting, and at least one to support intra-region routing.Realistically, there will probably be more than two. It is likelythat an inter-region routing protocol for a network having one ormore links with 40-minute one way delays and two-week link outages(such as might be encountered in a deep-space mission) would be



wholly different than an inter-region routing protocol to support asensor network connected to the Internet via a low-earth orbitingsatellite.

Our current thinking in routing protocols to support intermittentconnectivity is to maintain one-hop link state information and adistance-vector type of aggregation beyond one hop. We feel thatattempting to maintain an "accurate" picture of network connectivitybeyond one hop when routes are composed of scheduled or probabilisticconnections of uncertain capacity will be futile. However, webelieve that a probabilistic view of connectivity can be built andadvertised in a scalable way that permits effective use of theseintermittent contacts. The fact that there is no expectation of acontemporaneous end-to-end path makes the overall job seem morefeasible.

As previously mentioned, this area is teeming with interestingresearch topics. We intend to address some of these in comingmonths, but certainly solicit the participation of interestedresearchers.

7 Security considerations

While the particular security problems presented by delay-tolerantnetworks do not necessarily differ from those presented by othernetworks, the environment has a significant effect on the availablesolution space.

In addition to typical end user-oriented security, providing writer-to-reader services such as message confidentiality or end-to-end userauthentication, protection of the network infrastructure andcontrolling access to that infrastructure tend to be important indelay-tolerant networks, which are typically resource-challenged andcritical components to mission success. Along with high round-triptimes and frequent partitioning, delay-tolerant networks often havelow data rate links, making efficiency a necessary consideration inany solution. It is not unusual for delay-tolerant networks to bedeployed in places where a portion of the network might becomecompromised. Such compromise, should it occur, must be limited inscope and the effect finite in duration.

7.1 User-oriented security services

We have not received explicit user requirements for the followingsecurity services, but anticipate their need. We are as yetundecided whether to provide confidentiality and user authenticationas explicit bundle-layer services (a la IPSEC) or to simply make thekey management and distribution mechanisms we require available touser applications for them to provide their own confidentiality andauthentication (a la PGP, SSL, etc.). Current discussions havefocused on using public key cryptographic methods for the bulk of thesecurity services.



7.1.1 Confidentiality

The confidentiality service attempts to insure that the informationcontent of a bundle is not disclosed to anyone except the intendedrecipient. If the bundle layer provides the confidentiality service,the intended recipient will be the bundle layer entity at thedestination (rather than any specific application). In a public keybased system, this requires a high confidence that the sender has thepublic key of the intended recipient and that said key is unique.The confidentiality service will render all affected portions of thebundle unreadable, so it cannot be applied to fields in the bundleheader that are needed for delivery. In general, the bundle userdata is covered by the confidentiality service but none of the restof the bundle header is covered.

7.1.2 User Authentication

User authentication is a capability to prove that the bundle has beensent by the entity that claims to have sent it. Typically, anauthentication service ensures that the content of the bundle isunaltered as a means to prevent replay attacks. Authentication isaccomplished in a public key system by computing a hash of the datato be covered by the authentication, and then encrypting thatinformation with the private key of the sender. If the sender'spublic/private key pair is uncompromised and the cryptographicalgorithm is sufficiently strong, the recipient can apply thepurported sender's public key to the encrypted data, recover thehash, and compare it to a hash of the corresponding in formation inthe bundle. This allows the recipient to determine if the sender'skey is correct (authenticating the sender's identity), and if thedata received is identical to the data that was sent (verifying theintegrity of the data). Note that this service is required tosupport the infrastructure security model described in section 7.2,and hence could be made available to end-users to authenticate themto the remote bundle entity at relatively low cost. However, theremote bundle entity will have to request a trusted copy of thepurported sender's public key, potentially adding considerable delayto the receipt of the first bundles until a signed copy of thesources public key is received, verified, and cached.

7.1.3 Key Management and Distribution

In the public-key-based system under discussion, certificationauthorities sign keys and may securely place them in an otherwise-read-only distribution facility. Such a distribution facilityprovides some added assurance that a signed public key obtained fromthat facility has not been tampered with.

The system in section 7.2 makes use of public keys signed by atrusted authority. It does not explicitly require the availabilityof a distribution facility to improve the assurance that keys have



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 sanctioneddistribution facility rather than obtaining the same signedcertificate from the owner of the private key, we must carefullyexamine the costs of providing such a distribution facility inextreme environments. These costs (including the communication costsof maintaining such a facility, the risks of its compromise, and thepotential delays associated with accessing it via an extreme network)must be weighed against the benefit of the incremental security thatsuch facilities provide. The results of such a cost-benefit studywill likely vary widely from one DTN environment to another.

7.2 Infrastructure security services

The following model describes an approach to secure theinfrastructure of delay tolerant networks to a modest degree. It issensitive to the effects of delay and constrained data rates on theability to provide effective security services and of the effects ofthe resource requirements of those security services on the abilityof the network to support user traffic.

This model is preliminary, and like the rest of this document, isstill 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 theservices of the DTN must register its public key with a certificateauthority, and receive a copy of that public key signed by thatcertificate authority and a copy of its infrastructure credentialssigned by the certificate authority. Note that this single sentencecombines elements of Pretty Good Privacy (PGP) systems, Public KeyInfrastructure (PKI) systems, and Kerberos systems. The usergenerates his own public/private key pairs, as in PGP. Thecertificate authority (or registration authority) verifies theidentity of the prospective user and signs public keys, as in PKI.Additionally, the certificate authority either assigns or acquires ina secure manner and signs a set of infrastructure credentials.

The infrastructure credentials authorize the user to request some DTNclasses of service, but possibly not others. The infrastructurecredentials also have an expiration time. The user must obtain a newset of infrastructure credentials before the current set expires orelse there will be a lapse in the user's access rights to thenetwork.

There may (and probably should) be more than one certificateauthority in the network. The effects of a (detected) compromise of



a certificate authority will be discussed in a subsequent paragraph.

This model is described in terms of four types of elements: a user, aDTN router, a DTN interregional gateway (DTN gateway for short), anda DTN certificate authority. We consider the following hierarchy:DTN users and DTN certificate authorities are attached to DTNrouters. DTN users are subordinate to DTN routers. For purposes ofdata transfer, certificate authorities are subordinate to DTNrouters, but special authentication rules may apply. A single DTNuser may attach to and be supported by multiple DTN routers. (DTNrouters support more than one DTN user.) DTN routers are attached toother DTN routers as peers, and are subordinate to DTN gateways. DTNgateways are peers of other DTN gateways. (There may be morestructure among the DTN routers within a region, but that is notdiscussed in this model. The level of organization offered here isadequate to describe the concepts in this security model.)

Prior to accessing the network, a prospective user of the DTN mustpresent to a DTN certificate authority its public key (and possibly alarge bag of unmarked bills). It obtains from the DTN certificateauthority a signed copy of that public key and a signed set ofcredentials that authorize the user to source data using some subsetof the various classes of service offered by the DTN. This set ofcredentials includes a timestamp that identifies when the credentialsexpire. A provision is made for a DTN router or DTN gateway torequest an initial signed public key and set of credentials on behalfof a remote user.

The expiration time on the credentials provides a coarse mechanism todeal with system compromise. Rather than attempt to revoke a set ofcredentials, they are just not renewed. The expiration time must belarge enough that the delays involved in propagating the renewal andresponse do not result in inadvertent revocation of credentials, andlarge enough that the network isn't continually flooded with renewalrequests. This must be balanced with the effect on the network if asystem is compromised and is allowed to continue to consume networkresources until the credentials expire. If expiration times are verylong, a localized revocation scheme might need to be employed. Thisscheme would restrict credentials to a single DTN region, and upon adetection of system compromise, issue an explicit revocation ofcredentials within that region that remains in effect until theexpiration time of the revoked credentials.

When a DTN user wishes to send a bundle via a DTN router, it mustfirst present to the router its signed public key and its signedcredentials. The router verifies the signatures and stores thepublic key and credentials in a cache. The cached entry has anexpiration time that is the same as the expiration time of thecredentials. Prior to the expiration time, the DTN user must presentan updated set of credentials to the router in order to continuereceiving service. If a DTN user does not have a signed public key



and credentials, it may present its public key and some other TBDidentifying material to the DTN router and request that the routerobtain a signed version of the key and an appropriate set ofcredentials. The DTN router will pass this material along to acertificate authority requesting that the identification material beverified and credentials be issued. The DTN router will neitherroute nor enqueue data on behalf of the user until the certificateauthority 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 ofthe message header a field that contains a hash of the messagecontent, including timestamp, encrypted in the user's private key.We refer to this information as the signature block. [NOTE: It maynot be necessary to compute a hash over the entire message in orderto prevent application of these credentials to other messages.Alternatively, one might randomly select an offset and length in themessage and compute the hash of that range, and encrypt the offset,length, and hash. This might be beneficial to some computationallychallenged nodes for messages larger than some given size.]

Upon receipt by the first hop DTN router, the router decrypts thesignature block using the sender's public key, and then verifies thatthe message content matches the hash. This ensures that the senderis who he purports to be. [NOTE: An alternative reality might bethat his private key has been compromised. This document does notprovide guidance on how to determine if a user's key has beencompromised, only what to do once that compromise has been detected.]The DTN router compares the requested class of service against thecached credentials for this user, and decides whether or not toforward the message. If the router decides to forward the message,it generates a new signature block encrypted with its *own* privatekey, and the requested capabilities are the intersection of theuser's request and the router's own capabilities. Depending on whatthe user has requested during registration with the router, therouter-generated signature block either replaces the user's signatureblock, or is chained to it. [NOTE: The simplest approach is to havethe DTN router replace the user's signature block with its own.However, this precludes the establishment of user-specific securityboundaries elsewhere in the network. Consider that the DTN modelcatches on and it becomes broadly adopted throughout the Internet.The decision by a DTN router on, say, a university campus should NOTaffect whether that bundle is radiated to a spacecraft in Mars orbit.Rather, a separate security boundary should be established withinJPL. The original, source-specific signature block should be usedfor access control into this area, and therefore must be retained.Regardless of whether the user's signature block is retained, the DTNrouter's signature block is replaced at each hop. Therefore, themaximum header bloat is one signature block.] In this manner, theDTN router assumes custody of the message from an infrastructureprotection standpoint. DTN routers perform the same kind of publickey and credentials exchange during router discovery that user nodes



perform with DTN routers. Additionally, a DTN router cannot forwarda user message requesting a class of service higher than that whichthe router is authorized to provide. (It is not clear thatrestricting a router's authorized capabilities provides distinctadvantage. However, if a router cannot provide the full set ofcapabilities authorized to a particular DTN user, the router shouldflag that condition during the user's registration.)

This model provides the advantage that for the purposes ofinfrastructure protection, an individual user's public key and signedset of authorized capabilities do not have to be placed throughoutthe network. Rather, only the DTN routers that are one hop away arerequired to maintain this material unless there are special securityboundaries in the network that cause the user to explicitly requestretention of the user signature block. In that case, only the firsthop neighbors and the special security boundaries are required tomaintain user-specific public key and capabilities material.

Each DTN router has a unique public/private key pair and acapabilities-list that are signed by a certificate authority in thesame manner that a DTN user's is. The capabilities list has anexpiration time (although it may be longer than that issued to DTNusers), must be refreshed, and must be exchanged with next-hop DTNrouters and DTN gateways. As with DTN users, DTN router public keyinformation need not propagate more than one hop in the network. Thepreceding DTN router's signature block is *always* replaced aftervalidation.

7.2.2 Discussion

In considering the merits of such an approach, some evaluationcriteria are beneficial. The criteria on which this approach shouldbe 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 thesystem? To the number of infrastructure elements? To the numberof 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 obtainingthe private key of a DTN user, a DTN router, a DTN gateway, or acertificate authority. In the event of compromise, an unauthorizedDTN user, router, or gateway will be able to use the resources of thenetwork until the compromise is discovered and the capabilities-



authorization has expired (or an explicit revocation has been issuedto its one-hop neighbors for the remaining duration of itscapabilities-authorization). It is possible to use a voting schemeto deal with compromise of a certificate authority. (For example,the role of certificate authority may be considered a networkcapability, and entities claiming to provide that capability mayrequire that their public keys be signed by at least two othercertificate authorities. This is notional, and requiressignificantly more thought.) A DTN router may be flooded by requestsfrom a next hop neighbor, but until that prospective user's signedpublic key and capabilities list are received from a certificateauthority, no router resources will be dedicated to servicing thatuser beyond those required to identify and discard the traffic.

In general, the DTN routers and gateways that are adjacent to asubject entity (DTN user, router, or gateway) maintain stateinformation is maintained about that entity. That state isestablished through user interaction with a trusted certificateauthority and registration with next-hop routing neighbors (DTNrouters and gateways). Credentials are accompanied with anexpiration time, and state is removed when that time has passed.Additionally, in the event of a discovered compromise, explicitrevocation actions may be taken to limit the impact of thatcompromise. Those revocation actions introduce state into DTNrouting entities adjacent to the compromised entity. That state isremoved when the expiration time of compromised entity's credentialshas passed.

The information management requirements for a DTN routing entityscale with the number of next-hop neighbors. Additionally, DTNrouting entities must know about at least one certificate authority,but would preferably be aware of several or all, particularly in thecase of the previously-mentioned voting scheme among certificateauthorities.

This system can impose a registration delay of one round trip betweenthe DTN routing entity and the certificate authority if a prospectiveDTN user does not have a signed public key and capabilities list. Ona per-message basis, the system imposes the delay required to decryptthe signature block, verify the message hash, and either replace orappend a second signature block.

The signature block includes the following fields of clear text: 8bytes of sending timestamp, TBD bytes message hash (and, optionally,4 bytes offset and 4 bytes length if a hash is computed only over arandom subset of the message). The sending timestamp is included toprevent replay attacks. There can be, at most, two signature blocksin a message, and then only when explicitly requested by the DTNuser. The sending timestamp is included in the clear text of thesignature block as a premature optimization that assumes thatcomputing a hash over the immutable part of the bundle header and asecond hash over the payload will be larger than just including 8



more bytes. A further assumption is that the hassle of physicallycoalescing this information in order to compute a single hash is notworth it. The encrypted size of the signature block is algorithm anddata specific.

If infrastructure elements (DTN routers, gateways) change during thecourse of operation, registration by next-hop neighbors of these newelements will be required, but may use existing signed public keysand capabilities lists.

8 Reliability Considerations

The bundle layer depends on underlying transport services to providehop-by-hop reliability. In this context, "hop-by-hop" means from oneDTN node to the next. Those nodes may be separated by *many* hops inan underlying network, and the DTN architecture intends to exploitthe reliability, flow control, and congestion control capabilities ofthose underlying networks. However, some significant reliabilityissues remain at the bundle layer. This section discusses the issuesthat we have currently identified.

8.1 Custodial Operation

One of the fundamental tenets of the DTN architecture is that we mustbe able to provide reliable end-to-end message transfer via aninfrastructure that may *never* be connected end-to-endcontemporaneously.

Because no single transport-layer protocol operates end-to-end acrossthe IPN, end-to-end reliability can only be assured at the bundlelayer. At each node along an end-to-end route, the bundle-layerprotocol entity passes bundle data to the Transport layer fortransmission. Each bundle layer entity is highly confident that thetransport layer will successfully convey the data entrusted to it tothe next bundle-layer protocol entity (which may "take custody" ofthe data or merely relay it; a single hop). But failures arepossible (e.g., a host computer does an unplanned reboot).

A bundle custodian makes a commitment to store the subject bundleuntil one of two events occurs: another DTN node accepts custody ofthe bundle, or its time to live expires. The bundle layer attemptsto deal with bundles atomically and independently of other bundles.In this model, positive acknowledgement of a bundle is possible, butnegative acknowledgment is not. We consider the opportunity to *not*deal with partial bundles a significant plus. Since the underlyingtransport protocols are working on our behalf, we do not consider thelack of a negative acknowledgment capability a significant minus.(Note that there actually *is* a circumstance in which a negativeacknowledgment can be sent -- when the time to live for a bundleexpires. 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



to cause either an application layer retransmission or a bundle-layerretransmission (see section 8.2, below).

Without a negative acknowledgment mechanism, retransmission must beaccomplished solely via timer expiration. The bundle layer’sconfidence in the effectiveness of the underlying transport-layerprotocols is reflected in the design of the timers for bundle-layerreliability. These timers are highly optimistic – that is, theyexpire as late as possible – in order to give the transport protocolsevery opportunity to complete reliable transmission. The effect ofthis optimism is to minimize the chance of unnecessary bundle-layerretransmission, which could seriously degrade DTN performance byconsuming valuable bandwidth.

8.2 End-to-end Retransmission

The availability of timer-based retransmission and acknowledgmentmechanisms to support custody transfers means that the mechanisms tosupport end-to-end retransmission at the bundle layer are essentiallyavailable for free. If a DTN user has requested both custodialtransfer and the return receipt delivery option, it is reasonable toassume that end-to-end retransmission would be appropriate if, forsome reason, the custody transfer operation failed. However, fortimer-based retransmission, we must set the retransmission timer tosome reasonable value to account for the diligent efforts andultimate failure of the underlying transport protocols to succeed ineither the end-to-end transfer or the end-to-end return receipt.

For custody transfers, appropriate retransmission timer setting isless of an issue, since presumably the transfer is between thecurrent custodian and the next-hop custodian traverses fewer hopscarried by underlying transport protocols. One could reasonablyexpect better predictions of this round trip time than one could foran end-to-end transfer.

The result is that a conservative (optimistic) retransmission timeout value for an end-to-end transfer will likely be VERY large. Andthat value plus the anticipated end-to-end delay for a retransmittedbundle must be less than the time to live for the user's data or elsethe retransmitted data will time out in transit. If a bundle timedout 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 thetime-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 inall DTN environments. It is possible that it may provide value incertain environments, and we will continue to consider whether itshould be provided as an implicitly-requested capability when usersrequest both custody transfer and return receipt.



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 exceedinbound rates, and even though these nodes will probably be builtwith considerable storage, it can fill up.

Currently, we have two mechanisms for dealing with congestion incustodians. First, a congested custodian may simply not take custodyof incoming bundles, and rather just forward them on toward theirultimate destinations, possibly by way of a nearby custodian.Second, the congested custodian may cease to advertise its status asa custodian via whatever routing protocol is in use.

Although these techniques may eventually allow a congested custodialnode to recover some of its storage, they do not address the problemthat arises when the volume of inbound non-custodial bundles exceedsthe capacity of the outbound links for a sustained period of time.We have not yet defined techniques to explicitly accommodate thissituation, but feel that they are required. Whatever techniques wedo ultimately define must take into account the fact that in the DTNenvironment, the control loops for congestion control tend to belong, allowing less agile control. We must develop techniques thatanticipate congestion events sufficiently in advance of theirmanifestation that controls can be effective before significant dataloss occurs.

9 State Management Considerations

An important aspect of any networking architecture is its managementof state information. This section describes the state informationthat is part of the bundle layer, and discusses the conditions underwhich that state information is established and how it is removed.

9.1 Application Interface State

Although it is implementation-specific, it is very likely thatapplication-programming interfaces (APIs) to the bundle layer will bestateful. In long/variable delay environments, an asynchronousinterface seems to be the only sensible approach, and such interfacesinvolve registration actions that create state information. Thisinformation is typically created by explicit request of theapplication, 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 quitelong, it is reasonable to expect that an application instance mightterminate (voluntarily or not) between the time that a bundle is sentand the time its response is received. The application interface tothe bundle layer will, in most cases, provide a mechanism toreinstantiate applications that have terminated, assuming the



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 destinationapplication instance indicated in the destination tuple. If theapplication instance is unavailable for immediate delivery (forexample, it runs as a result of a "cron" job), then state is createdpending delivery of the bundle. That state is removed on successfuldelivery of the bundle to the application instance or on expirationof the time to live in the bundle. Note that if the return receiptdelivery option is enabled for a bundle, that return receipt is notgenerated until the bundle has been successfully delivered to thedestination application.

Note that in some DTN environments, delays might REALLY be long, andbundle layer operations may be required to operate across systemreboots, host changes, or possibly even operating system upgrades.To facilitate this, some bundle layer implementations will employvarious forms of persistent storage for their state information, andwill avoid operating system attempts to "clean up" state information.

9.2 Bundle retransmission state

State information to support bundle retransmission is created at aDTN node as a result of either of two events: First, state is createdwhen a bundle is received from a DTN user application requestingcustodial transmission (assuming that DTN node is capable ofsupporting custodial operation). Second, state is created when abundle is received from a peer DTN node and the receiving nodeintends to assume custody of the bundle.

In the first case, recall that applications may indicate a bundletime to live that is greater than that which is allowed in thenetwork. (For example, a DTN application may legitimately feel thatits data has value for a century or more, while the DTN that iscarrying it doesn't want a particular bundle to potentially be intransit for that long.) The bundle layer may reduce the time to livevalue in the bundle itself to a value that is consistent with networkoperation rules. The bundle layer at the source *should* retain theinformation about the application's view of the bundle's valuablelifetime. In the event that a bundle *transmission* times out beforecustody is assumed, the bundle layer *may* restart the bundletransmission procedure. This highlights the need to be careful toensure that bundle acknowledgments have a high probability ofreceipt, to avoid spurious retransmissions of bundles. At thesource, the state associated with a custodially transmitted bundle isremoved when a custody transfer acknowledgment is received, or when aperiod of time subject to local policy has elapsed.

For the second case (that of an in-network custodian) stateinformation is removed when a custodial acknowledgment for the bundle



is received or when the time to live field in the bundle has beenexceeded.

9.3 Bundle routing state

Routing tables, whether statically configured or maintained byrouting protocols, introduce state information that must be managed.If the general approach to maintaining routing information is asdescribed in section 6.4 (that is, maintaining link state informationfor next-hop neighbors, and distance vector information for pointsbeyond), then we can make some basic statements about the amount ofstate information that must be maintained. For persistent links, inthe worst case the volume of routing information for inter-regionrouting scales by (n*R), where n is the number of next hop neighborsand 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 ofcontact periods maintained for planning purposes. These values areworst-case. Pruning and aggregation mechanisms can be used reducethe volume of information if necessary. In particular, it is likelythat the intermittent links may be reduced to order (n*R) by simplyassuming that the distance vector information is constant for allcontacts. (There probably will not be enough useful information todo otherwise.) We have not yet seriously considered the routingmetrics that we will maintain, so we do not have an estimate for thesize 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 ofDTN gateways that are members of the region and by the routingapproach used within the region. (By routing approach we meanbroadly either proactive, meaning that routes to all possibledestinations are maintained, or reactive, meaning that routes arediscovered only when necessary and discarded after some period oftime.) This also directly affects how and when routing stateinformation is removed from a DTN forwarding node.

9.4 Transmission queue state

Transmission queues are maintained within DTN nodes to manage bundlesawaiting transmission. Although implementation dependent, this stateinformation will likely include a list of next hop destinations, andfor intermittently connected next-hop destinations, a sublist ofupcoming contacts. These lists will likely contain lists of bundlesfor transmission on those contacts. When a new contact is scheduledor predicted with an intermittently-connected next-hop neighbor, anew 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 betransmitted, they are allocated to subsequent contact lists, and thelist for the completed contact is removed.



9.5 Receive queue state

Incoming bundles are received from lower layer entities and eitherplaced on a transmission queue (for bundles to be forwarded) orplaced in a receive queue (for local delivery). Receive queues aremaintained to support demultiplexing of incoming bundles. Again,although implementation-specific, receive queues are likelyassociated with a particular local application entity. Bundles areremoved from receive queues when they have been successfullydelivered to their destination application entity. The receive queueitself is removed when an application explicitly requests that itsinformation be purged from the bundle layer (as part of an un-registration action), or when the application entity has terminatedwithout leaving instructions for the disposition of remainingbundles.

9.6 Network management state

We acknowledge that network management information is likely to be anecessary part of the operation of delay tolerant networks. We havenot, at this point, done a meaningful amount of work in identifyingthe network management requirements for DTNs or in defining the stateto 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 convergencelayer between the bundle layer and underlying transport protocols.The convergence layer manages the protocol-specific details ofinterfacing with a variety of underlying transport services andpresents a consistent interface to the bundle layer. The convergencelayer also allows additional capability to be inserted as necessaryto augment the services of the underlying transport protocols.

The convergence layer provides an abstraction to the bundle layer inwhich bundles are delivered atomically. Partial bundle delivery,especially at the end of a contact, is accommodated within theconvergence layer. Additionally, the convergence layer may provideperformance enhancement services such as the ability to resume apartially-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. Thissection documents our current thinking on the information that mustbe carried end-to-end, and notes which of those data elements may besupplied by the application using the bundle service.

* Version Identifier: this is small integer that indicates whichversion of the bundle protocol is being invoked.

* Destination entity name: this is the IPN name of the remote



bundle agent, and is a tuple, as described above. It issupplied by the local application using the bundle service.

* Source entity name: this is the IPN name of the local bundleagent, and is a tuple. It is supplied by the local bundleservice, since a particular host may have multiple names and onemay be chosen based on routing decisions or other criteriaopaque to the application (as in multihomed hosts). The sourcename may be returned to the application to support returnreceipt processing.

* Reply-to entity name (optional): a source may anticipate notbeing able to accept replies, and may use the reply-to name tospecify the destination for return receipts and deliveryrecords.

* Current custodian name (optional): the bundle protocol supportsstore-and-forward operation in which the custody of a bundle(that is, the responsibility for ensuring reliable delivery) maytransfer from one DTN node to another as the bundle progressesthrough the DTN. There is not a requirement for *each* DTN nodeencountered to assume custody of a bundle. As a result, it isnecessary to identify the upstream node that has custody of thebundle, in order to acknowledge correct receipt of the bundleand 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 thenetwork.

* User data: this is intended to be all of the data that theremote entity requires to perform whatever operation isrequested. Since the environmental characteristics of a DTNtend to make interactivity difficult, the notion is that all ofthe 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 portionreplaced by a Status Report, consisting of the following information:

* Source tuple of the subject bundle: this field partially



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 StatusReport.

* 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 transferacross a Delay-Tolerant Network. This particular example is based onthe Interplanetary Internet: A host on Earth sends a bundle to adestination on Mars. Figure 2 illustrates the network that is thesubject of this example – the Interplanetary Internet in this examplehas five distinct regions interconnected by four DTN Gateways. Thisexample highlights the actions taken by the bundle layer and theinteractions of the bundle layer with applications and withunderlying 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 regionID, an entity ID, and an instance ID. Section 5.2 requires that eachDTN region have an identifier space shared by all DTN nodes withinthat region. Section 5.4 requires that each DTN region have a uniqueidentifier that is known among all regions in the DTN. Thisparticular delay-tolerant network is the Interplanetary Internet. Inthis section we will establish the naming rules that permitinteroperation within this network. Note that this is only anexample, and that not all DTNs must use this particular regionidentifier space (subject to the requirements of section 4.5).

12.1.1 Region identification

All regions in *this* DTN (the example Interplanetary Internet) mustshare a region identifier space. Per section 4.5, the DTN region*name* space is hierarchical, dot-separated text, structured suchthat left to right is leaf-to-root in the tree. The *identifier*



space may be exactly this name space, or a DTN may define atranslation from the name to a particular identifier, in the same waythat names in the DNS may be translated to Internet addresses. Forthis 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 awell-known TCP port in combination with DNS host names as entityidentifiers. The bundle layer application resides above this well-known port (which we arbitrarily choose to be TCP port 6769, acurrently unassigned port in the registered port space). Theinterplanetary backbone region, labeled "ipn" in Figure 1, willcertainly NOT use TCP as its underlying transport protocol. For thesake of simplicity in this example, let us assume that the protocolused within the interplanetary backbone region uses the same entityidentifier space (IP addresses and port numbers) that the remainderof the network uses.

The instance identifier is entity-specific, and for the sake ofsimplicity, we will assume that this is a process ID. [Note: thisis a simple, but quite limiting decision, as it has implications onprocess reinstantiation and process portability/migration from oneentity 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 isrequired at the DTN Gateways, so it is important to understand thetopology of the network at the region level. Unlike typicalterrestrial communications, the Interplanetary Internet's (IPN’s)*long-haul* communication links are directional, mobile, and highlyscheduled. This is important, because directionality combined withmobility means that a transmitter and receiver must track each



+-------------------------+| 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. Inthe IPN, much of the mobility is due to orbital mechanics and istherefore relatively predictable. However, this means that nodesthat we would normally consider to be fixed, such as antennas on thesurface of the Earth, are actually highly mobile as a result of theEarth’s rotation and its revolution around the Sun. (In thisexample, we confine ourselves to our local solar system, and do notconsider the motion of our sun relative to celestial bodies outsideour solar system.)

We can describe the predictable aspects of node mobility with anephemeris, a table of the positions of celestial bodies at specifiedintervals of time. Both a directional sender and receiver must knowthe other’s position in order to establish a link between the pair.

In addition, these communication resources are highly scheduled. Itis not sufficient for a receiver to point at a prospective target andjust wait – for example, a terrestrial node will typically have topoint at several targets sequentially, and an interplanetary nodewill typically not have enough power to just wait for incomingmessages. Rather, a schedule of communication *opportunities* mustbe calculated and then refined with planned communication*instances*. A communication opportunity establishes that theendpoints could establish a link if they were pointing at each otherat the proper times. We refer to a planned communication instance as



an agreement (although not irrevocable) between the two parties toestablish contact and communicate for a defined period of time.

The protocols for establishing the schedule of communicationinstances between all pairs of possible communicants will evolve --from something primarily done manually to something more automated asthe 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 abundle’s arrival at a DTN Gateway, some or all of the possibleoutbound routes may be "down." The gateway must store the bundleuntil the appropriate link is available and then transmit the bundleover that link. One of the fundamental differences between theInterplanetary Internet and the terrestrial Internet is this inherentuse of store-and-forward mechanisms in routing bundles. With thatin mind, let us consider the routing decisions made at some of theDTN Gateways in Figure 3.

12.3 DTN Gateway routing

Bundle routing at a DTN gateway will typically have to deal with amix of continuously available links and intermittently availablelinks. Routing across a continuously available link is a relativelystraightforward activity. Routing in the presence of intermittentlyavailable links can be significantly more complex, as the gatewaywill need to decide not only the next hop destination but also thetime at which to send the bundle. Conditions elsewhere in thenetwork may make it more desirable to send a bundle to a next-hopdestination that is not yet accessible, even when an alternativeroute is currently available. This decision process is discussed insection 6.3.

The intermittent links in this example provide connectivity among theDTN Gateways that are part of the ipn.sol.int region. The contactsamong gateways in this region are scheduled. As is currently thecase, Gateway 1 (the Earth gateway) has scheduled contacts with eachof the other DTN gateways in the ipn.sol.int region (the "backbone"),but there is no direct contact among any of the DTN gateways onVenus, Jupiter, or Mars. Recall that this communication usesdirectional antennas, so it is generally not possible to communicatewith two different entities at once unless they are in the same fieldof view. Power availability on the remote planets is an issue, sotransmitters and receivers are turned on only during a contact.Further, the speed of light delays are nontrivial, skewing transmitand receive times between remote gateways. In Table 1, a schedule ofcontacts is presented that will be used in the example. All timesare referenced to Gateway 1. The information in this table iscompletely hypothetical, and the speed of light delays are plausible,but completely back-of-the-envelope. Those details are perhapsinteresting but not the point of the example.



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 beacknowledged before the next contact (which might be the followingMonday). Bundles sent by GW4 after 1358 cannot be acknowledgedduring the current contact. Similarly, bundles sent by GW2 after1150 cannot be acknowledged during the contact.

DTN Gateways 2, 3, and 4 have entries in their contact schedules forthe 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 ofthe Interplanetary Internet that participate directly in the bundletransfer example. Also shown in Figure 3 are the source anddestination for the transfer and the Domain Name System equivalentsin the terrestrial Internet (DNS 1), in the IPN "Backbone" (DNS 2),and in the Mars Internet (DNS 3). This figure will serve as thebasis for the bundle data transfer example.

Table 2 provides the full host names of each of the primary elementsin Figure 4. Recall that in this example all bundle layerapplications reside on TCP port 6769. Application instanceidentifiers, the third part of the DTN name tuple, have been omitteduntil the applications are discussed in section 12.5.1.



+---+/ /|

+------------------------+---+ |+---+ 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} |+------------+------------------+---------------------------+



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 inthe network exchange their signed key material and credentials withnext hop neighbors. These materials are cached for subsequent use.The applications at the source and destination register with theirlocal bundle layers, providing similar key material and credentialsto the bundle layer, and receiving in return their applicationinstance identifiers. The destination has registered as a daemonapplication, and has been assigned its IPN-standardized well-known idof "8." The source has registered as an ephemeral application, andhas received the application instance identifier "0x1763421A" (ahexadecimal number).

12.5.2 Step 1: Bundle creation and first-hop transmission

The application on the source host in Figure 3 has data that itwishes to send to the destination on Mars. The exact content of thisdata is opaque to the bundle transfer, but assume that it containsall 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 dataobject is to be operated upon. The application invokes the bundlelayer, 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 | |+-------------+---------------------+------------------------------+



The bundle agent verifies the signature, then creates a bundle andstores it in persistent storage (on disk or other non-volatilememory). There are some fields of the bundle header that the bundleagent must supply: the Sending Timestamp, the Source Host name tuple,the Custodian name tuple, and the time to live. (The application maystate a time after which the data are obsolete, but the actual time-to-live field in the bundle header uses the application’s data incombination with network restrictions on time-to-live to initializethis field properly.) The bundle layer consults routing tables notesthat its next-hop destination to reach the mars.ipn.sol region withinthe earth.ipn.sol region is ipngw1.jpl.nasa.gov:6769. (Since a hostmay reside in multiple IPN Regions, the source host name tuple is afunction of the outbound route selected. The bundle layer uses thisinformation to complete the Source Host and Custodian name tuplesprior to transmission.) Having verified the application's signature,it incorporates this into the authentication information of thebundle header and appends its own credentials, as described insection 7.2. It further notes that it has a continuous connection tothat gateway, and transmits the bundle to it, retaining a copy forcustodial storage. The bundle layer starts a retransmission timerfor 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 thebundle via TCP, it checks the signature of the previous router anddetermines that the bundle has been forwarded by a legitimate source.Further, since this is the security boundary for the InterplanetaryInternet, it verifies the signature of the sending application,requesting a copy of the application's public key from a securedistribution service if it does not already have one cached. Havingverified that the application is authorized to access the deep-spaceportion of the Interplanetary Internet, the bundle layer replaces thesignature block of the bundle layer entity with its own, leaving theapplication's signature block intact. Itstores the received bundleon persistent storage (disk). The bundle layer consults the contactschedule, and determines that the appropriate next-hop destination isin the "ipn.sol" IPN Region: {ipngw2.nasa.mars.org, ipn.sol}, andthat the next contact is the following Wednesday. The bundle layermanifests the bundle on the contact for that Wednesday.

In considering alternative contacts for the bundle, the dispatcherchecks the time-to-live in the bundle, which was 36 hours from thetime of initial submission to the bundle agent at the source, toensure that the route selected is consistent with the time-to-liverequirements of the bundle. The bundle transport functionality ofthe bundle agent in ipngw1 accepts custody of the bundle, updatesthis information in the bundle header, and informs the source thathas done so. The sources bundle agent deletes its custodial copy ofthe bundle. When the time arrives for contact with the



ipngw2.nasa.mars.org DTN gateway to be established, the convergencelayer establishes that contact via the Long Haul Transport Protocol(LTP). When informed that the contact is available, the bundle layerposts 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 thebundle from the Earth gateway via LTP. It verifies the signatureblock of the Earth gateway, then replaces that signature block withits own. It stores the bundle in persistent storage and acceptscustody of the bundle, signaling back to the Earth gateway that ithas done so. When the notification of acceptance reaches the Earthgateway, ipngw1 deletes its custodial copy. The Mars gatewayconsults its routing tables to find an outbound contact to forwardthe bundle over. It determines that the appropriate next hop is thedestination itself, that the proper transport protocol is TCP, andthat the destination is accessible immediately. The gateway verifiesthat the time-to-live has not expired, and forwards the bundle to thedestination.

12.5.5 Step 4: Bundle processing at destination

The destination bundle layer receives the bundle via TCP, verifiesthe signature block of the IPN G/W2, stores it on its own persistentstorage, and accepts custody of the bundle from IPN G/W2. The bundleagent "awakens" the destination application process identified by theDestination Application Instance Handle. This may involve creating anew instance of a server from a daemon process, signaling an idlerunning process, or reinstantiating a process that has been suspendedwith its state stored on persistent storage. The bundle agentdeletes the copy of the bundle from persistent storage when theapplication has received it. The destination application maygenerate an application-layer acknowledgment in a new bundle and sendit to the source’s application instance identifier (0x1763421A fromTable 2).

12.6 Error Conditions at the Bundle Layer

This section describes the error conditions that may arise at thebundle layer during bundle creation and transport. When these errorsoccur within the sender’s DTN region, it may be possible to conduct anear-real-time dialog to correct them before the bundle is forwarded.We say ‘may be possible’ because even if two nodes are in the sameIPN domain, they may not have real-time connectivity. An example ofsuch a situation would be if a lander were on the opposite side ofthe planet from its DTN gateway, and used bundles to communicate withthe gateway through a low altitude orbiter, with the orbiter itselfserving as a bundle agent.



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 thesending application.

* Unknown Destination Region: This error occurs when the sourcebundle node is directed to create a bundle destined for an DTNRegion that is not recognized. Note that only the DTN Region partof the destination name has to be interpretable outside thedestination’s DTN Region. In particular, the entity identifier ofthe destination name need not be interpretable to the source(assuming the source and destination are in different DTNRegions), so it cannot necessarily be checked when the bundle iscreated.

* Invalid Source Application: If the source application instancehandle supplied by the source application is invalid or the sourceauthentication information fails, the source bundle layer respondswith an Invalid Source Application error. This might be the case,for instance, if the source application provided an instancehandle referencing a system process for which the applicationdidn’t have privileges.



* Bundle Parameter Syntax Error: The source bundle layer may checkthe syntax of some of the bundle-creation parameters (i.e. it mayensure that the end-to-end and DTN access security certificatesare well-formed, etc.) If a parameter is found to besyntactically incorrect or obviously and definitely erroneous, thebundle layer will report a Bundle Parameter Syntax Error back tothe source that includes, at a minimum, the parameter that causedthe error.

* Bundle Parameter Semantic Error: If the source bundle layer canidentify a particular bundle creation parameter as being well-formed but unserviceable, it will report a Bundle ParameterSemantic Error to the source application that includes, at aminimum, the parameter that caused the error.

* Insufficient Buffer Space: If a bundle node does not havesufficient buffer space to accept a bundle, it drops the bundleand generates an Insufficient Buffer Space error. Note that abundle node may choose to drop lower priority bundles in order tomake room for higher priority ones. This error is not propagatedback 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 aDNS Unreachable error. This information is not propagated back tothe source application.

* Time Exceeded: If the time-to-live field (either the source-provided TTL or the internal bundle TTL) expires, the source isnotified with a Time Exceeded message. These errors arepropagated to the source application.

* Source Entity Access Denied: This error indicates that the sourceentity 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 itmight not have authorization to use a particular interfacerequired by the bundle. Source Entity Access Denied errorsindicate that the source is not *authorized* to use a particularresource; other errors (e.g. Insufficient Buffer Space) indicatethat a particular resource is *unavailable* to a bundle. Forexample, an entity on the surface of a planet might be authorizedto communicate, using the bundle protocol, with another entity onthe other side of the planet via a low-altitude orbiter that isalso an IPN gateway. The sender might not, however, be authorizedto send bundles across interplanetary space. In this case bundlessent to the orbiter destined for the other side of the planetwould not cause errors, while any bundles with off-planetdestination addresses would. Source Entity Access Denied errorsare propagated back to the source application.

* Invalid Entity ID in Destination Name: Once a bundle has reachedits destination DTN Region, the Entity ID part of the destinationname can be verified. If the Entity ID of the destination name isnot valid, the source is notified with an Invalid AdministrativeDestination Name error message.

* Invalid Destination Application: If the destination bundle layercannot instantiate the destination application (based on thedestination application instance identifier in the bundle), it



notifies the source application with an Invalid DestinationApplication error message.

* End-to-End Access Denied: If the bundle destination does notaccept the bundle due to an authentication or access-controlerror, the source is notified with an End-to-End Access DeniedMessage.

13 Summary

This architecture addresses many of the problems of networks thatmust operate in extreme environments. It is message based, and usesas an example of service classes those offered by the postal mailsystem. It accommodates many different forms of connectivity,including scheduled, predicted, and opportunistically connectedlinks. It introduces a novel approach to end-to-end reliabilityacross frequently partitioned and unreliable networks. It alsointroduces a novel scheme for securing the network infrastructureagainst unauthorized access.

It is our belief that this architecture is applicable to manydifferent types of extreme environments. In subsequent documents, weintend to specify profiles of this architecture that address specificenvironments in detail. We plan to develop profiles of thisarchitecture for Interplanetary Internetworking (the genesis of thearchitecture), for Sensor Internetworking, for Military TacticalInternetworking, and for "Snowmobile" Internetworking. In additionto these profiles, our upcoming tasks include precise specificationof the constituent protocols in concert with their prototyping andtesting. 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 ResearchDirections 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 theInterplanetary 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 NetworkArchitecture. Section 7 of this document, also titled "Security

http://www.isi.edu/newarch/

http://www.cra.org/Policy/NGI/papers/wroklawWP

http://www.ipnsig.org/reports/TCP_IP.pdf



considerations" is devoted to examining the issues involved insecuring the DTN architecture and providing basic security servicesto DTN applications.



16 Authors' Addresses

Dr. Vinton G. CerfMCI WorldCom22001 Loudoun County ParkwayBuilding F2, Room 4115, ATTN: Vint CerfAshburn, VA 20147Telephone +1 (703) 886-1690FAX +1 (703) 886-0047Email [email protected]

Scott C. BurleighJet Propulsion Laboratory4800 Oak Grove DriveM/S: 179-206Pasadena, CA 91109-8099Telephone +1 (818) 393-3353FAX +1 (818) 354-1075Email [email protected]

Robert C. DurstThe MITRE Corporation1820 Dolley Madison Blvd.M/S W650McLean, VA 22102Telephone +1 (703) 883-7535FAX +1 (703) 883-7142Email [email protected]

Dr. Kevin FallIntel Research, Berkeley2150 Shattuck Ave., #1300Berkeley, CA 94704Telephone +1 (510) 495-3014FAX +1 (510) 495-3049Email [email protected]

Adrian J. HookeJet Propulsion Laboratory4800 Oak Grove DriveM/S: 303-400Pasadena, CA 91109-8099Telephone +1 (818) 354-3063FAX +1 (818) 393-3575Email [email protected]

Dr. Keith L. ScottThe MITRE Corporation1820 Dolley Madison Blvd.M/S W650McLean, VA 22102Telephone +1 (703) 883-6547

mailto:[email protected]







FAX +1 (703) 883-7142Email [email protected]

Leigh TorgersonJet Propulsion Laboratory4800 Oak Grove DriveM/S: T1710-Pasadena, CA 91109-8099Telephone +1 (818) 393-0695FAX +1 (818) 354-9068Email [email protected]

Eric J. TravisGlobal Science and Technology, Inc.6411 Ivy LaneSuite 300Greenbelt, MD 20770Telephone +1 (301) 474-9696FAX +1 (301) 474-5970Email [email protected]

Howard S. WeissSPARTA, Inc.9861 Broken Land ParkwayColumbia, MD 21046Telephone +1 (410) 381-9400 x201FAX +1 (410) 381-5559Email [email protected]

Please refer comments to [email protected]





interplanetary internet (ipn) architecture document · title: interplanetary internet (ipn)...

Documents