DTN Research Group V. Cerf INTERNET-DRAFT MCI/Jet Propulsion Laboratory S. Burleigh October 2003 A. Hooke Expires April 2003 L. Torgerson NASA/Jet Propulsion Laboratory R. Durst K. Scott The MITRE Corporation K. Fall Intel Corporation H. Weiss SPARTA, Inc. Delay-Tolerant Network Architecture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG). The charter documents for this research group can be found at http://www.irtf.org. Other information may be found at the research group's web site: http://www.dtnrg.org. Abstract This document describes the Delay-Tolerant Networking (DTN) Architecture. It aims to present a system for providing interoperable communications across a variety of internetworks with operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. It is a generalization of the IPN architecture originally designed for the Interplanetary Internet [B03]. We define a message-oriented overlay that exists above the transport layer of the networks on which it is hosted. The document presents an architectural overview followed by discussions of services, topology, routing, security, reliability and state management. Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................2 1 Introduction................................................4 2 Why an Architecture for Delay-Tolerant Networking?..........4 2.1 Problems with the Existing Internet Protocols..........4 2.2 DTN Design Principles..................................5 3 DTN Architectural Description...............................5 3.1 Virtual Message Switching..............................5 3.2 Store and Forward Operation............................6 3.3 DTN Delivery Mimics Postal Operations..................7 3.4 Nodes and Agents.......................................9 3.5 Regions and Gateways..................................10 3.6 Tuples................................................12 3.7 Late Binding..........................................13 3.8 Routing...............................................13 3.9 Bundle Fragmentation and Reassembly...................16 3.10 Bundle Layer Reliability and Custody Transfer.........17 3.11 Time Synchronization..................................17 3.12 Congestion and Flow Control at the Bundle Layer.......18 3.13 Security..............................................19 4 State Management Considerations............................20 4.1 Demultiplexing and Binding State......................21 4.2 Bundle Retransmission State...........................21 4.3 Bundle Routing State..................................21 4.4 Security-Related State................................22 5 Bundle Header Information..................................22 6 Application Structuring Issues.............................23 7 Convergence Layer Considerations for Use of Underlying Protocols..................................................24 8 Summary....................................................25 9 Informative References.....................................25 10 Security Considerations....................................26 11 Authors' Addresses.........................................27 12 Intellectual Property Notices..............................28 13 Copyright Notices..........................................28 Cerf, et al. Expires April 2004 [Page 2] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 Acknowledgments John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen Farrell and Craig Partridge all contributed useful thoughts and criticisms to previous versions of this document. We are grateful for their time and participation. This work was performed in part under DOD Contract DAA-B07-00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407. Release History draft-irtf-ipnrg-arch-00.txt, May 2001: Original Issue. draft-irtf-ipnrg-arch-01.txt, August 2002: -Restructured document to generalize architecture for delay-tolerant networking. -Refined DTN classes of service and delivery options. Added a "reply-to" address to have response information such as error messages or end-to-end acks directed to a source-specified third party. -Further defined the topological elements of delay tolerant networks. -Elaborated routing and reliability considerations. -Initial model for securing the delay tolerant network infrastructure. -Expanded discussion of flow and congestion control. -Added section discussing state information at the bundle layer. -Updated bundle header information and end-to-end data transfer. draft-irtf-dtnrg-arch-00.txt, March 2003: -Revised model for delay tolerant network infrastructure security. -Introduced fragmentation and reassembly to the architecture. -Removed significant amounts of rationale and redundant text.-Moved bundle transfer example(s) to separate draft(s). draft-irtf-dtnrg-arch-01.txt, October 2003: -Generalized model language to accommodate the possibility of using Identity Based Encryption (IBE) -Small extension to custody discussion. -Introduced a list of what applications always specify when requesting a bundle to be sent. Cerf, et al. Expires April 2004 [Page 3] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 1 Introduction This document describes a data communications architecture for Delay and Disconnection-Tolerant interoperable networking. The architecture embraces the concepts of occasionally-connected networks that may suffer from frequent partitions and that may be comprised of more than one divergent set of protocol families. The basis for this architecture lies with that of the Interplanetary Internet, which focused primarily on the issue of deep space communication in high- delay environments. We expect the current DTN architecture described here to be utilized in various high-delay and unusual environments; the case of deep space is one of these, and is still being pursued as a specialization of this architecture (See http://www.ipnsig.org and [B03] for more details). Other networks to which we believe this architecture may apply include sensor-based networks using scheduled intermittent connectivity, classes of terrestrial wireless networks that cannot ordinarily maintain end-to-end connectivity, and more "conventional" internets with long delays. A DTN tutorial [W03], aimed at introducing DTN and the types of networks for which it is designed, is available to introduce new readers to the fundamental concepts and motivation. A technical description may be found in [F03]. The particular approach we employ is that of an end-to-end message- based overlay that exists above the transport layers of the networks on which it is hosted. The overlay employs persistent storage at intermediate message switches, includes a hop-by-hop transfer of reliable delivery responsibility, and provides an optional end-to-end acknowledgement. For interoperability it includes a flexible naming format (based on URIs) capable of encapsulating different naming schemes in the same overall naming format. It also has a basic security model aimed at protecting infrastructure from unauthorized use. 2 Why an Architecture for Delay-Tolerant Networking? The reason for pursuing an architecture for delay tolerant networking stems from experience gained while attempting to impose Internet- style networking over networks for which it was not designed. In so doing, several particular problems related to built-in assumptions of the Internet protocols are encountered. Understanding the limitations posed by these assumptions leads to a set of design principles that guide the DTN architectural design. These factors are summarized below; more detail on their rationale can be found in [B03,F03,DFS02]. 2.1 Problems with the Existing Internet Protocols The existing Internet Protocols do not work well for some environments, due to fundamental assumptions built into the Internet architecture: Cerf, et al. Expires April 2004 [Page 4] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 - that an end-to-end path between source and destination exists for the duration of the communication session; - (for reliable communication) that the maximum round-trip time over that path is not excessive and not highly variable from packet to packet - that the end-to-end packet loss is relatively small - that all routers and end stations support the TCP/IP protocols - that applications need not worry about the performance of underlying physical links - that endpoint-based security mechanisms are sufficient for meeting most security concerns In several networks one or more of these assumptions may be violated. In addition, these networks are often unusual and not designed with interoperability in mind. Thus, a DTN design should facilitate operation among poorly-connected networks but also provide a mechanism to achieve interoperability among such networks. 2.2 DTN Design Principles In light of these assumptions, coupled with the desire to communicate through and among networks with radically different performance characteristics, the DTN architecture is conceived based on a number of design principles that are summarized here: - provide a coarse-grained class of service and delivery options based on non-real-time services provided by the US (and other) postal systems - use variable-length (possibly long) messages (not streams or limited-sized packets) as the communication abstraction to help enhance the ability of the network to make good scheduling/path selection decisions - encourage applications to minimize round-trip exchanges - guide application design to cope with application restart after failure while network transactions remain pending - use storage within the network to support end-to-end reliable delivery of messages, even if these networks suffer from frequent partitioning or high data loss (e.g. support operation in environments where no end-to-end path may ever exist) - provide security mechanisms that protect the infrastructure from unauthorized use; if appropriate, provide access to these mechanisms by applications for use in their own application-level security protocols 3 DTN Architectural Description The previous section summarized the design principles that guide the definition of the DTN architecture. This section outlines the design decisions that result from those design principles. 3.1 Virtual Message Switching Cerf, et al. Expires April 2004 [Page 5] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 A DTN-enabled application specifies either a file-based or memory- based copy of data to be transmitted by a nearby (local) DTN forwarding agent using a specialized API. The agent forms a "bundle" containing whatever the requesting application wishes to send, plus some header information it creates. Bundles are also called "messages" in this document. Data submitted by applications can be of arbitrary length (subject to any implementation limitations), as can bundles. Bundles preserve application message boundaries: application data are written and read in an atomic fashion, although bundles may be split up during transmission and their relative order may not be preserved. Generally, forwarding agents (executing as applications) send messages among themselves above the transport layers of the networks they interconnect, forming an overlay network called the "bundle layer." Bundles contain (variable-length) names ("tuples") that identify the sender and intended receiver of a message. A sending application typically forms the sending tuple identifier by combining information it learns from its local forwarding agent, in combination with its own application-specific data. The resulting tuple provides enough information for a receiving application to reply. The destination tuple is also supplied by the application. It is interpreted by the forwarding agent as little as possible: only that portion of the destination tuple required for determining the next hop is interpreted. The rest is treated as opaque data, allowing the overall naming system to take advantage of late binding (see Section 3.7). In adition to the sender and receiver tuples, messages may also contain an optional "report-to" tuple used when special operations are requested to direct diagnostic and delivery notification messages to an entity other than the sender. A message-switched abstraction provides the bundle layer with a- priori knowledge of the size and performance requirements of requested data transfers. When there is resource contention in the network, the advantage provided by knowing this information may be significant for making scheduling and path selection decisions. An alternative abstraction (i.e. of stream based delivery) would make such scheduling very difficult. Although packets provide some of the same benefits as messages, larger aggregates provide a way for the network to make scheduling, buffer management and path selection decisions to entire units of data that are meaningful to applications. 3.2 Store and Forward Operation An essential element of virtual switching of messages is that they have a place to wait in a queue until an outbound communication opportunity ("contact") becomes available. This highlights the following assumptions: 1. that storage is available and well-distributed throughout the network Cerf, et al. Expires April 2004 [Page 6] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 2. that storage is sufficiently persistent and robust to store messages until forwarding can occur, and 3. (implicitly) that this 'store-and-forward' model is a better choice than attempting to use other approaches such as TCP/IP or other alternatives that require continuous connectivity For a network to effectively support the DTN architecture, these assumptions must be considered and must be found to hold. 3.3 DTN Delivery Mimics Postal Operations The (U.S. or similar) Postal Service provides a strong metaphor for the services that a Delay-Tolerant Network offers. Traffic is generally not interactive. It may be one-way in nature. There are generally no strong guarantees of timely delivery (with some limited exceptions), yet there are some forms of class of service and security. Postal services have evolved over hundreds of years and serve a very large and diverse user community. They have therefore already explored various service classes and special delivery options, which we leverage here for the DTN architecture. The DTN Architecture, like the most postal services, offers *relative* measures of priority (low, medium, high which correspond roughly to bulk, first class, and express mail). It also offers basic special delivery options, for example: "the intended recipient has accepted delivery of the message," "the route taken by this message is as follows...", and "the message has been accepted for transmission." 3.3.1 DTN Classes of Service We have currently defined three specific classes of service in the DTN architecture, based on their postal mail counterparts: - Bulk - In bulk class, bundles are shipped on a "best effort" basis. No bulk class bundle will be shipped until all complete bundles of other classes bound for the same next hop destination have been shipped. - Normal - Normal class bundles that are in queue and bound for the same next hop destination are shipped prior to any complete bulk class bundles that are in queue. - Expedited - Expedited bundles, in general, are shipped prior to bundles of other classes. However, the bundle layer *may* implement a queue service discipline that prevents starvation of the normal class, which may result in some normal bundles being shipped before expedited bundles bound for the same next hop destination as the normal class bundles. Cerf, et al. Expires April 2004 [Page 7] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 Applications specify their requested class of service. This request, coupled with policy applied at message switches, affects the overall likelihood and timeliness of message delivery. 3.3.2 DTN Postal-Style Delivery Options Applications may request any of the following five delivery options: - Custodial Delivery - a bundle will be transmitted by the bundle layer using reliable transport protocols (if available), and the point of reliable delivery responsibility (i.e. retransmission buffer) will advance through the network from one custodian to another until the bundle reaches its destination. The bundle layer depends on the underlying transport protocols of the networks that it operates over to provide the primary means of reliable transfer from one bundle layer to the next. However, when custodial delivery is requested, the bundle layer provides an additional coarse-grained timeout and retransmission mechanism and an accompanying (bundle-layer) hop-by-hop acknowledgment mechanism. When a bundle application does *not* request custodial delivery, this bundle layer timeout and retransmission mechanism is not employed, and successful bundle layer delivery depends solely on the reliability mechanisms of the underlying transport layers - Return Receipt - a return-receipt bundle is issued by the receiving bundle layer implementation when the (arriving) subject bundle is consumed *by the destination application* (not simply the destination bundle layer). The receipt is issued to the entity specified in the source tuple of the subject bundle or the source's designated alternate (report-to field), which would typically be located on a different host. The return receipt uses the same custodial delivery option setting used in the subject bundle. (Return receipts are never issued with the return receipt delivery option requested, to avoid "return receipt storms.") - Forwarding Indication - sent by an agent when the last fragment (in terms of time) of a bundle has been forwarded. The indication is sent to the report-to destination if specified, and to the source of the subject bundle otherwise - Custody Transfer Indication - same as forwarding indication, but sent when a custodial transfer has successfully completed - Secured Delivery - indicates the application has provided authentication material along with its message send request. To operate under general circumstances, applications should be prepared to supply authentication credentials and request secured delivery. Local policy determines whether any bundles may be sent lacking the security option, and regions beyond the originating region may require security even if the originating region does not. 3.3.3 Required Information - Applications always specify the following information when requesting to send data: Cerf, et al. Expires April 2004 [Page 8] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 - Expiration Time - indicates the time at which the data is no longer useful to the application. If a bundle is stored in the network when its expiration time is reached, it may be discarded. Expiration times are expressed as an offset relative to the current time of day, which is assumed to be known by all DTN nodes - Source Tuple - an identifying name of the sender - Destination Tuple - an identifying name of the recipient - Report-To Tuple - an identifying name of where reports (return- receipt, route-tracing functions, etc.) should be sent. This will often coincide with the Source Tuple. - Receive-only applications need only specify a receiving tuple when requesting to receive data. 3.4 Nodes and Agents A DTN forwarding agent (or "agent" in this document) is an engine for sending and receiving DTN messages (bundles). Agents are typically programs (similar to mail transfer agents in e-mail systems) that execute in a host environment. The execution environment for an agent is called a DTN "node" and is typically a single computer. DTN agents may act as sources, destinations, or forwarders of bundles. A node may support more than one agent, although we do not believe this configuration to be particularly common or desirable. Each agent is uniquely identified by at least one tuple; an agent that is reachable in multiple regions will have at least one identifying tuple for each region in which it resides. Applications may be co-resident on a node with the agent it uses for DTN communications, or they may be separated (and use some private protocol other than bundling for the agent-to-application communication). Each bundle agent on a DTN node has a distinguishing name (distinct from any applications *using* that agent). This is necessary for generating custody acknowledgments to the agent itself rather than to an application. Cerf, et al. Expires April 2004 [Page 9] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 3.5 Regions and Gateways The DTN architecture defines a "network of internets" comprised of "DTN regions." Assignment of DTN agents to particular regions is an administrative decision, and may be influenced by differences in protocol families, connection dynamics, or administrative policies. Regions may also be delimited based upon other criteria, such as trust boundaries [NEWARCH] or global/local address partitions [IPNL, TRIAD]. Each DTN region has a unique name that is known (or knowable) among all regions of the DTN. Thus, a DTN-wide directory for region names is required for inter-region operations. Regions are key concepts in the DTN architecture. DTN bundles that originate outside the destination region are first transmitted toward one of the DTN gateways that connect the source region with one or more other regions. Routing outside the destination region is based on the destination region's name, and not on the completely formed destination tuple (see below). All inter-region message forwarding takes place between DTN agents called *gateways*, which provide the interconnection points between regions. These correspond to "waypoints" in [META], and to the gateways described in the original ARPANET/Internet designs [CK74]. DTN gateways differ from ARPANET gateways because they operate above the transport layer and are focused on message switching rather than packet switching. However, both DTN gateways and ARPANET gateways provide interoperability between the protocols specific to one region and the protocols specific to another, and both provide a store-and- forward forwarding service (with DTN gateways employing persistent storage for its store and forward function). The following list identifies the requirements for DTN regions: - Each DTN region shall have an identifier space that is shared by all DTN agents within the region. A region must specify the naming conventions to be employed within that region for entity identification. - Each agent that is a member of the region shall have a unique identifier drawn from that identifier space. (Note that for some types of regions, a "node" may be made up of a collection of computational elements, possibly geographically distributed. A single unique identifier may collectively refer to them. Further, the unique identifier requirement only applies to nodes that are intended to *receive* data from other DTN nodes.) - To be considered a member of a region, each prospective member of the region shall have the ability to reach every other member of the region without depending on any DTN nodes outside the region using some protocol(s) known or knowable to each node. (Although a DTN node may not necessarily be *directly* reachable. This may Cerf, et al. Expires April 2004 [Page 10] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 require forwarding and/or store-and-forward operation by other DTN nodes inside the same region.) Cerf, et al. Expires April 2004 [Page 11] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 3.6 Tuples The region name described above (plus some forwarding state) is necessary and sufficient to route a bundle to its destination region, but not to its final destination(s). The DTN architecture uses a tuple comprised of the region name and a region-specific entity name to identify a particular entity (or set of entities) in a DTN. The entity name is *opaque* outside the region of definition, but must be resolvable to one or more endpoints within its containing region. An entity might be a host, a protocol, an application, some aggregate of these, or something else depending on the nature of the addressing and naming structures used in the containing region. We have adopted a format based upon Universal Resource Identifiers (URIs) [RFC2396] as the general (written) structure for tuples using the reserved URI scheme name "bundles." A "fully-qualified" tuple is thus expressed using the following convention: bundles:///:// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (opaque portion: entity name) This structure represents a nested URI. The portion of the tuple identifies a region name in some yet-to-be-specified global namespace. The identifier, which must be resolvable in the region specified by , specifies the semantics to be applied to the portion of the tuple. A concrete example in an Internet-like region named "Earth.Internet" might be the following: bundles://Earth.Internet/tcp://venera.isi.edu:5000/243845 Here, "bundles" is the (proposed) reserved URI scheme name [RFC2396]. The second-level scheme name identifies the scheme "tcp" which implies a reliable connection (presumably using the TCP protocol) should be used to contact a host specified by DNS name "venera.isi.edu" at port 5000. Any data beyond this in the tuple not required by the delivery semantics of the "tcp" scheme is given to receiving applications. Clearly, some form of binding mechanism (local to the containing region) is required to allow applications to associate themselves with DTN tuples. The details of the binding mechanism are region and API-specific and not discussed here. However, any such mechanism must provide a way for a requesting application to bind to a *prefix* of a fully qualified destination tuple. This allows the system to support multiple receiving applications associated with the same destination tuple. Discovery of valid DTN region names and how to reach them is the responsibility of bundle-layer routing (see below), which includes both path selection and scheduling. This problem is presently an area of active research. Knowing the destination name of a desired Cerf, et al. Expires April 2004 [Page 12] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 communication peer (i.e. how to acquire the appropriate entity names of a peer in a remote region) is out of the scope of this document, but corresponds directly to the Internet problem of knowing port numbers a-priori. An out-of-band mechanism is frequently used. 3.7 Late Binding The opacity of entity names outside their local region enforces another key concept in the DTN Architecture: that of late binding. Late binding refers to the fact that the entity name of a tuple is not interpreted (e.g., used to form an address for delivery within the region) 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 each region. The entity names used in tuples might be built on URIs (as illustrated above), or might look like "expressions of interest" or forms of database-like queries as in a directed diffusion-routed network [IGE00] or as in intentional naming [WSBL99]. Additionally, late binding avoids the delay-related issue that the name/location binding information in a region might be highly ephemeral relative to the transit time of a bundle. We assume that the internal details of a destination region will be sufficiently stable, at least for the duration of a message transit delay within that region, or that delay-tolerant mechanisms will be employed *within* the region to compensate. (This is, by definition, a local issue within the region and may be accommodated in whatever manner is most practical for that region.) 3.8 Routing The bundle layer provides routing among DTN agents, including DTN gateways. There may be many DTN gateways that interconnect adjacent regions, and there may be multiple bundle routing "hops" within a single region (especially if intra-regional connectivity is intermittent). Routes (choice of next hop bundle agent for each bundle and when to send traffic to them) are computed based on a collection of "contacts" that indicate the start time, duration, endpoints, forwarding capacity and latency of a link in the topology graph. They are generally assumed to be describing edges on a *directed, time-varying, multi-graph*. (A multi-graph may have more than one edge between the same two vertices). Contacts may be deterministic and well-known, or may be derived from estimates and may therefore contain errors (see below). Note that for DTN routing, location of the next hop toward a specified destination is not the only type of routing that may need to be accomplished. In addition, a bundle requiring custody transfer may need to be forwarded to a next hop toward a next custodian, and Cerf, et al. Expires April 2004 [Page 13] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 this route may not coincide with the best next hop toward the destination. 3.8.1 Types of Routes DTNs may be required to function in the presence of various forms of connectivity characterized by several "contact types": Persistent Contacts Persistent contacts are contacts that are always available, with no connection establishment required. In the IP world, a Digital Subscriber Line (DSL) or other "always-on" connection is an example. OnDemand Contacts OnDemand contacts are contacts that require some action in order to instantiate, but otherwise function as persistent contacts until terminated. Dial-up connections are an example of OnDemand contacts (at least, from the viewpoint of the dialer; they may be viewed as an Opportunistic Contact - below - from the viewpoint of the dial-up service provider). Intermittent - Scheduled Contacts Scheduled contacts are those where there is an agreement to establish a link between two points at a particular time, for a particular duration. An example of a scheduled contact is a link that uses a low-earth orbiting satellite. A schedule of view times, durations, capacities and latencies can be constructed for each next-hop neighbor reachable via the satellite. Intermittent - Opportunistic Contacts Opportunistic contacts are those that are not scheduled, but rather present themselves unexpectedly and frequently arise due to node mobility. For example, an opportunistic contact may arise with an aircraft flying overhead (whose flight path is unknown) that beacons, thereby advertising its availability for communication. Another type of opportunistic contacts might be via an infrared or BlueTooth communication link between a personal digital assistant (PDA) and a kiosk in an airport concourse offering bundle service. As the PDA is brought near the kiosk, and if its owner so authorizes, it could advertise the owner's planned travel path and express a desire to have contacts with subsequent kiosks along the path provided. This information could be used by the collection of kiosks to form a set of probable communication opportunities for which bundle transfers can be scheduled. In such cases it may be profitable to consider limited duplication or flooding in the network [VB00] to enhance the likelihood of reliable delivery. Intermittent - Predicted Contacts Cerf, et al. Expires April 2004 [Page 14] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 Predicted contacts are those based not on a fixed schedule, but rather on statistical inference of likely contact times and durations derived from a history of previously observed contacts or other information. Given a great enough certainty that a predicted contact will occur, a DTN agent may allocate (schedule) bundles to that predicted contact that would otherwise be allocated to different contacts. In the previous example, the probable contacts in the airport concourse would result in the establishment of a set of predicted contacts of a given duration (perhaps based on the PDA owner's walking speed and the kiosk's coverage area). The PDA could decide how to use those contacts for scheduling outgoing bundles. The algorithms for establishing the predicted time and duration of a contact, the degree of uncertainty in those estimates, the time at which to abandon the wait for a predicted contact, and the guidelines for allocating bundles to such contacts are all open research areas. 3.8.2 Bundle Storage for Store-and-Forward operation While IP networks are based on "store-and-forward" operation, there is an assumption that the "storing" will not persist for more than a small amount of time (usually equal to the queuing and transmission delay). In contrast, the DTN architecture does not expect that an outbound link will be available when a bundle is received, and expects to store that bundle for some time until a link does become available. We anticipate that most DTN agents will use some form of persistent storage for this -- disk, flash memory, etc., and that stored bundles will survive system restarts. All DTN agents, even those that do not provide custodial operations as described in section 3.10, must be able to queue bundles until outbound contacts are available. Each DTN agent that is also willing to provide custody transfer operations should provision for longer- term storage of bundles, committing to store bundles for which it takes custody for the entire remainder of their lifetimes, if necessary. It is entirely possible that an agent will need to "take a break" from agreeing to new custody transfers while it completes pending custodial transfers and recovers persistent storage. Two mechanisms support this: First, the node can simply forward incoming bundles without taking custody. The fact that a node is a potential custodian is no guarantee that it will actually take custody of any given bundle that is routed to it. Second, the node can indicate to others it is no longer willing to take custody for future messages. Once other nodes become informed of this information, they can potentially seek an alternative custodian. The availability of long-term storage for bundles allows the next-hop forwarding decision to potentially be modified prior to transmission. In particular, if a future contact is chosen to carry a bundle and some other superior contact becomes known, the bundle could be re- Cerf, et al. Expires April 2004 [Page 15] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 assigned. Details of this re-assignment operation are local to a particular bundle router and influenced by the times at which contact schedules become known. 3.9 Bundle Fragmentation and Reassembly There are two forms of bundle fragmentation/reassembly. The first form corresponds closely to traditional IP fragmentation, while the second form is novel. In either case the *final destination(s)* are responsible for reassembling fragments of a bundle into the original: Any DTN agent may -proactively- choose to divide a bundle into multiple self-identifying smaller parts and transmit each such part as a bundle. This form of fragmentation is analogous to IP fragmentation. A bundle agent may -reactively- choose to fragment a bundle on receipt. This situation arises when a portion of a bundle may have been received successfully. In this case, the receiving node modifies the incoming bundle to indicate it is a fragment, and forwards it normally. The previous-hop sender may learn that only a portion of the bundle was delivered to the next hop, and optimistically continue sending the remaining portion of the original bundle when subsequent contacts become available. Reactive fragmentation is specifically designed to handle cases in which a router is faced with forwarding a bundle for which no single contact provides sufficient data transfer volume. Cerf, et al. Expires April 2004 [Page 16] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 3.10 Bundle Layer Reliability and Custody Transfer The bundle layer provides an end-to-end reliable message delivery service that employs in-network reliability mechanisms between (possibly non-network-layer-adjacent) DTN nodes. The bundle layer makes use of the reliability mechanisms available from the underlying transport layers of each region, and a single bundle-layer hop *may* span an entire region. The bundle layer supports end-to-end reliability derived solely from the custody transfer mechanism, but also provides a true (optional) end-to-end acknowledgement for application use. Applications wishing to utilize this indication for their own end-to-end bundle retransmission mechanisms are free to do so. The bundle layer provides three types of delivery services, with various levels of reliability-enhancing mechanisms: end-to-end acknowledgment of a bundle, custodial transmission (with in-network retransmission if required), and unacknowledged bundle transmission. Custody transfer allows the source to delegate retransmission responsibility and recover its retransmission-related resources relatively soon after sending the bundle (on the order of a round- trip time to the first bundle hop). While not every node in a DTN must be capable of providing custodial services, all DTN nodes that span networks that may be frequently disconnected are expected to be able to be custodians. 3.11 Time Synchronization The DTN architecture depends on time synchronization (supported by external, region-local protocols) for two primary purposes: routing with scheduled or predicted contacts and bundle expiration time computations. Routing based on schedules and dependent upon coordination of shared assets (such as directional antennas) may create other operational requirement for time synchronization to achieve contact rendezvous. Bundle expiration is achieved by including a source time stamp and an explicit expiration field (in time units after the time in the source time stamp) in each bundle header. Its sole use by the bundling layer is for purging data from the network, so the synchronization requirements posed here are not strict. This approach allows a source time stamp to be used for a number of purposes, such as unique identification of individual messages from a particular source. The source timestamp on an arriving bundle is made available to consuming applications by an API (specified elsewhere). DTN nodes must ensure that timestamps in bundles they send never decrease. This should not pose too burdensome a requirement---the current specification for the timestamp is 64 bits and includes a 32-bit quantity to count microseconds. Cerf, et al. Expires April 2004 [Page 17] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 3.12 Congestion and Flow Control at the Bundle Layer The subject of congestion control and flow control at the bundle layer is one on which the authors of this document have not yet reached complete consensus. We have unresolved concerns about the efficiency and efficacy of congestion and flow control schemes implemented across long and/or highly variable delay environments, and its relationship to routing and the custody transfer mechanism that may require nodes to retain messages for long periods of time For the purposes of this document, we define "flow control" as a means of assuring that the rate at which a sending node transmits data to a receiving node does not exceed the maximum rate at which the receiving node is prepared to receive data from that sender. (Note that this notion of flow control may be hop-by-hop among agents, rather than only end-to-end). We define "congestion control" as a means of assuring that the aggregate rate at which all traffic sources inject data into a network does not exceed the maximum aggregate rate at which the network can deliver data to destination nodes. If flow control is propagated backward from destination nodes to routers and eventually back to traffic sources, then flow control can be at least a partial solution to the problem of congestion as well. One view of congestion control is as follows: "Congestion control is concerned with allocating the resources in a network such that the network can operate at an acceptable performance level when the demand exceeds or is near the capacity of the network resources. These resources include bandwidths of links, buffer space (memory), and processing capacity at intermediate nodes. Congestion occurs when the demand is greater than the available resources." [J90] In a DTN, the likelihood of congestion occurring may vary widely based upon routing selections. If the routing process is provided a great deal of knowledge about contacts and traffic demands (and it employs a reservation scheme), it may be able to arrange for traffic to be sent so as to completely avoid congestion. If the routing process is only permitted to know a subset of this information (or the information provided to it is incorrect), data loss due to congestion may occur. In most cases, we expect DTN flow control decisions will be made locally to each agent based on a combination of global (that might be stale) and local knowledge regarding the topology, available buffers, and traffic demand. However, the bundle layer *might* be able to delegate the implementation of those decisions to the underlying transport protocols, as follows. For purposes of discussing flow control, we have not yet considered multipoint communication at or below the bundle layer, so each individual flow control problem involves just two nodes. Because inter-region traffic must pass through inter-region gateways, any two nodes between which flow control is an issue must inhabit a common DTN region and be using a common transport protocol below the bundle layer (otherwise they could not be communicating and there would be Cerf, et al. Expires April 2004 [Page 18] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 no flow to control). Therefore, it may be possible to accomplish DTN flow control by invoking whatever flow control mechanisms are already provided within the region by the common transport protocol, if such mechanisms exist. Alternatively, a new, supplementary flow control protocol could be developed at the bundling layer; this would have the advantage of reducing a DTN's reliance on capabilities provided by the underlying protocols and may be required anyhow for environments where the region-specific transport protocol(s) lack flow control. At this time it's still unclear which approach is preferable, and some combination of the two may eventually be declared to be the best choice. In either approach, the problem of flow control between nodes separated by very large signal propagation times remains to be solved: TCP's flow control and congestion control facilities could be leveraged within regions characterized by small round-trip times, but at this time no comparable protocol exists for very long delay paths. It remains as an exercise for us to demonstrate that a hop-by-hop flow control scheme in long and/or highly variable delay environments can effect end-to-end congestion control in a fair and efficient manner. 3.13 Security Resource scarcity in delay-tolerant networks dictates that some form of access control to the network itself is required in many circumstances. It is not acceptable for an unauthorized user to be able to easily flood the network with traffic, possibly preventing the network's mission from being accomplished. Implicit in this statement is a requirement for some form of admission control and/or in-network authentication and access control that is sensitive to the class of service that a user has requested. In a low delay environment, performing such computations would be tedious for performance reasons. In a high/variable delay, and possibly low data rate environment, it is problematic for other reasons: remote access control lists are difficult to update, query/response key distribution protocols are not resource-efficient, and routers or end nodes might be compromised for significant periods of time before being noticed. To implement a security model with infrastructure protection, each message includes an immutable signature containing a verifiable identity of the sender (or role), and other conventional cryptographic material to verify accuracy of the message content. Agents check these authentication credentials at each DTN hop, and discard traffic as early as possible if authentication or access control checks fail. This approach has the associated benefit of making denial-of-service attacks relatively harder to mount (as compared with conventional Internet routers). However, the obvious cost is the considerably larger computation and storage overhead required at each DTN node. Cerf, et al. Expires April 2004 [Page 19] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 The current approach uses asymmetric cryptography as a starting point for keying, and requires one or more trusted credential-issuing authorities. Each agent is issued initial configuration information usable to assess the validity of credentials they will be presented with in the future (e.g. a certificate authority's public key, or IBE system parameters [BF01]). An agent sending a message must obtain a verifiable copy of its public information from an authority known to other DTN agents (i.e. that corresponds to the initial configuration information other agents have been equipped with). An application then presents a copy of its verifiable public information along with a message to be carried signed appropriately using her private information. At the first DTN agent, the public information is verified to validate the sender and requested CoS against an access control list stored with the agent. Accepted messages are then re- signed using the private information of the router itself for transit. Using this approach, only "first-hop" agents need cache per-user information, and then only for adjacent users. Non-edge "core" agents can rely on the authentication of their upstream neighbors to verify the authenticity of messages. We believe this approach will help to improve the scalability of key management for these networks, as it will limit the number of cached public credentials to a function of the number of adjacent nodes rather than the number of end-users. This should provide both the obvious advantage of space savings, but also an improvement to system management as router keys are expected to be changed less frequently than end-user keys. As DTNs are likely to be deployed in remote areas, re-keying operations may be comparatively burdensome system management tasks, so limiting the number and frequency of certificate updates should provide additional savings. The approach described above is partially susceptible to compromised agents. If an otherwise-legitimate agent is compromised, it would be able to utilize network resources at an arbitrary CoS setting and send traffic purportedly originating from any user who's identity is known to the router. However, if message signatures are applied using user-provided keys at endpoints and carried end-to-end (an option for DTN security), a legitimate user could repudiate the origin of any traffic generated in this manner. Thus, we believe a reasonable trade-off is to admit the possibility that a compromised router could launch a denial-of-service attack in order to gain the scalability benefits of not checking end-user credentials at every hop. 4 State Management Considerations An important aspect of any networking architecture is its management of state information. This section describes the state information that is managed at the bundle layer and discusses the conditions under which that state information is established and how it is removed. Cerf, et al. Expires April 2004 [Page 20] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 4.1 Demultiplexing and Binding State In long/variable delay environments, an asynchronous application interface seems to be the only sensible approach. Such interfaces involve callback registration actions that create state information. This information is typically created by explicit request of the application, and is removed by a separate explicit request, and is thus "hard" state. In most cases, there must be a provision for retaining this state information across application and system restart because a client/server message round-trip time may exceed the requesting application's execution time (or node's uptime). In addition, the tuples for which an application wishes to receive data may incorporate entity names that are associatively-mapped (e.g. have properties in common with URNs [RFC2276]). That is, these names may need to be registered and resolved within a region using some directory service that provides an extra level of indirection (e.g. dynamic DNS [RFC2136]), and consequently may involve the establishment, maintenance, and tear-down of state dependent on the particular choice of indirection infrastructure. 4.2 Bundle Retransmission State State information to support bundle retransmission is created by a DTN agent when a bundle is received from a DTN application requesting custodial transmission or when a bundle is received from a peer DTN agent and the receiver intends to assume custody of the bundle. The bundle's expiration field (possibly mitigated by local policy) determines when this state is purged from the system in the event that it is not purged explicitly due to acknowledgment. 4.3 Bundle Routing State Forwarding and routing tables, whether statically configured or maintained by routing protocols, introduce state information that must be managed in a manner that is dependent upon the specific routing mechanisms employed. While routing protocols have not yet been developed for DTN networks, in order to provide forwarding, a DTN agent will be required to have available a forwarding table containing next-hops indexed by region names (and also conceivably by entity names for intra-region routing). In addition, as mentioned above, it seems highly useful to also include a method for agents to learn about potential custodians. This information would enlarge the overall forwarding state, but probably not significantly. We have not yet seriously considered the routing protocols or metrics that we will use, so we do not have an estimate for the size of each routing entry, whether it is for inter-region or intra-region routing. This remains as future work. Cerf, et al. Expires April 2004 [Page 21] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 4.4 Security-Related State The infrastructure protection model described in this architecture requires maintenance of state in all DTN nodes. All agents are required to store their own private keys and a block of information used to verify credentials issued by an agreed-upon set of authorities. Further, in most cases, DTN nodes will cache the public information (and possibly the credentials) of their next-hop (bundle) neighbors. All keys will have expiration times, and agents are responsible for acquiring and distributing newly-generated copies of their public information prior to the expiration of the old set (in order to avoid a disruption in network service). While the keying is used for authentication, access control lists represent another block of state present in any node that wishes to enforce security restrictions. The access control lists will presumably be of small size for core nodes, as they should only need to verify messages from their neighbors. Edge nodes, however, will likely have access control lists that scale as the number of users served by the agent in question. Some DTNs may implement security "boundaries" at various points in the network, where end-user credentials are checked in addition to checking agent credentials (at the cost of additional storage requirements). User-level public information will typically be cached at these points in the network. As with routing, the security approach is under development, so the exact enumeration of the required state will depend on the particular algorithms eventually selected for implementation. 5 Bundle Header Information The bundle layer must carry some information end-to-end. The full details of the fields present in a bundle header are specified in [BundleSpec]. This section documents the meta-data information that must be carried end-to-end, and notes which of those data elements may be supplied by the application using the bundle service. * Version Identifier: an 8-bit bundle protocol * Destination: a variable-length field containing the destination tuple, as described above. It is supplied by the local application when sending using the bundle service. * Source: this is also a variable-length field containing the identifier of the source tuple. It is supplied by the requesting application, possibly based upon knowledge provided by its local agent. Employing information provided by the local agent is useful because a particular agent may have multiple bundle interface names and one may be chosen based on routing decisions or other criteria. * Report-to (optional): a source may anticipate not being able to accept replies or diagnostic reports, and may use the report-to Cerf, et al. Expires April 2004 [Page 22] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 tuple to specify the destination for such receipts and diagnostics. * Current custodian (optional): Tuple identifying the current custodian. It is necessary to identify the upstream node that currently has custody of a bundle, in order to acknowledge correct receipt or custody transfer of a bundle or bundle fragments. * Class of service flags: - Flags: custody, return receipt, delivery record - CoS Selector: bulk, normal, expedited - Security: presence of authentication and/or encryption * Send timestamp: the time that a bundle was presented by the sending application to the bundle layer for transmission. Timestamps use microsecond-level granularity. * Expiration: an offset, in seconds, from the send timestamp that indicates when the bundle shall be purged from the DTN. * Authentication information (optional): authentication data used to prove that this bundle should be forwarded in the network. * Fragmentation information (optional): for a bundle fragment, indicates the place in the original bundle this fragment belongs. Some bundles (or events) cause a status indication to be generated by the bundle layer. Bundle layer indications are sent as bundles with the user data portion replaced by a Status Report, consisting of the following information: * Source tuple of the subject bundle: a copy of the source tuple from the subject bundle. * Send timestamp of the subject bundle: used to disambiguate status reports for different bundles from the same source entity * Status flags, indicating whether or not a bundle was: . received correctly by the sender of the Status Report . Custodially transferred to the sender of the Status Report . Forwarded by the sender of the Status Report * 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 6 Application Structuring Issues DTN bundle delivery is intended to operate in a *delay-tolerant* fashion over a broad range of network types. That does not mean that there *must* be delays in the network, but that there *may* be very significant delays (including extended periods of disconnection between sender and intended recipient). The protocols providing the services exposed by the bundle layer are delay tolerant, so to take best advantage of them, applications using them should be, too. Message-oriented communication differs from conversational communication. In general, applications should attempt to include enough information in a bundle so that it may be treated as an Cerf, et al. Expires April 2004 [Page 23] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 independent unit of work by the remote entity (a form of "application data unit" [CT90] or "transaction", although transactions carry connotations of multi-phase commitment that we do not intend here, but see [FHM03] for more discussion). The goal is to minimize conversation between applications that are separated by a network that presents long and possibly highly variable delays, and to constrain any conversation that does occur to be asynchronous in nature. A single file transfer request bundle, for example, might include authentication information, file location information, and requested file operation. Comparing this style of operation to a classic FTP transfer, one sees that the bundled model can complete in one round trip time, whereas an FTP file "put" operation can take as many as eight round trips to get to a point where file data can flow [DFS02]. Delay-tolerant applications must consider additional factors beyond the conversational implications of long delay paths. Applications may terminate (voluntarily or not) between the time that a bundle is sent and the time its response is received. If an application has anticipated this possibility, it is possible to re-instantiate the application with state information saved in persistent storage. This is an implementation issue, but also an application design consideration. Some consideration of delay-tolerant application design can result in applications that work reasonably well in low-delay environments, and that do not suffer extraordinarily in high or highly-variable delay environments. 7 Convergence Layer Considerations for Use of Underlying Protocols Implementation experience with the DTN architecture has revealed an important architectural construct and implementation methodology for DTN agents. Not all transport protocols in different protocol families provide the same exact functionality, so some additional adaptation or augmentation on a per-stack basis may be required to provide the reliable delivery the bundle layer expects. This adaptation is accomplished by a set of "convergence layers" placed between the bundle layer and underlying (transport) protocols. The convergence layers manage the protocol-specific details of interfacing with a particular transport service and present a consistent interface to the bundle layer. The complexity of a convergence layer may vary substantially depending on the type of protocol stack it adapts. For example, a TCP/IP convergence layer for use in the Internet might only have to add message boundaries to TCP streams (an SCTP convergence layer might be less complex), whereas a convergence layer for some network where no reliable transport protocol exists may have a considerable amount of work to do, at least if custody transfer is to be supported. The issues with implementing the bundle layer on top of unreliable regional transport protocols remains to be explored. Cerf, et al. Expires April 2004 [Page 24] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 8 Summary The DTN architecture addresses many of the problems exhibited by networks operating in environments subject to poor performance and non-continuous end-to-end connectivity. It is based on asynchronous store-and-forward messaging, and uses postal mail as a model of service classes and delivery semantics. It accommodates many different forms of connectivity, including scheduled, predicted, and opportunistically connected links. It introduces a novel approach to reliability with end-to-end acknowledgements across frequently partitioned and unreliable networks. It also proposes a model for securing the network infrastructure against unauthorized access. It is our belief that this architecture is applicable to many different types of emerging (and existing) networks that have, until recently, operated independently and isolated from each other. In subsequent documents, we intend to specify profiles of this architecture that address several specific environments in detail. 9 Informative References [B03] S. Burleigh et al, "Delay-Tolerant Networking: An Approach to Interplanetary Internet," IEEE Communications Magazine, June 2003. [CT90] D. Clark, D. Tennenhouse, "Architectural Considerations for a new generation of protocols," Proc. SIGCOMM 1990. [W03] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial", Wartham Associates, Available from http://www.dtnrg.org [F03] K. Fall, "A Delay-Tolerant Network Architecture for Challenged Internets," Intel Research, Proceedings SIGCOMM, Aug 2003. [IGE00] C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed Diffusion: A scalable and robust communication paradigm for sensor networks", MobiCOM 2000, Aug 2000. [WSBL99] W. Adjie-Winot, E. Schwartz, H. Balakrishnan, J. Lilley, "The design and implementation of an intentional naming system", Proc. 17th ACM SOSP, Kiawah Island, SC, Dec. 1999. [NEWARCH] NewArch Project: Future-Generation Internet Architecture. Home page: http://www.isi.edu/newarch [META] J. Wroclawski, "The Metanet," Workshop on Research Directions for the Next Generation Internet", May 1997. Available from http://www.cra.org/Policy/NGI/papers/wroklawWP. [CK74] V. Cerf, R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Trans. on Comm., COM-22(5), May 1974 Cerf, et al. Expires April 2004 [Page 25] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 [DFS02] R. Durst, P. Feighery, K. Scott, "Why not use the Standard Internet Suite for the Interplanetary Internet?", MITRE White Paper, http://www.ipnsig.org/reports/TCP-IP.pdf [J90] R. Jain, "Congestion Control in Computer Networks: Issues and Trends," IEEE Network Magazine, May 1990. [RFC2136] P. Vixie, ed., "Dynamic Updates in the Domain Name System (DNS UPDATE)," Internet Request for Comments, RFC2136, Apr. 1997 [BundleSpec] S. Burleigh, et al, "Bundle Protocol Specification" work in progress, (draft-irtf-dtnrg-bundle-spec-01.txt), October 2003. Available from http://www.dtnrg.org. [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", Internet RFC 2396, Aug 1998 [VB00] A. Vahdat, D. Becker, "Epidemic routing for partially- connected ad hoc networks", Duke Tech Report CS-200006", Apr. 2000 [IPNL] P. Francis, "IPNL: A NAT-Extended Internet Architecture", Proceedings SIGCOMM, Aug 2001. [TRIAD] D. Cheriton, M. Gritter, "TRIAD: A New Next-Generation Internet Architecture", Available from http://www.dsg.stanford.edu/triad/index.html [BF01] D. Boneh, M. Franklin, "Identity based encryption from the Weil pairing", SIAM J. of Computing, 32(3), 2003 [FHM03] K. Fall, W. Hong, S. Madden, "Custody Transfer for Reliable Delivery in Delay Tolerant Networks", Available from http://www.dtnrg.org [RFC2276] K. Sollins, "Architectural Principles of Uniform Resource Name Resolution", Internet RFC 2276, Jan 1998 10 Security Considerations Security is an integral concern of the Delay Tolerant Network Architecture. Section 3.13 of this document presents an approach for securing the DTN architecture. These capabilities may also be useful in providing facilities to DTN applications to construct their own end-to-end security protocols. Cerf, et al. Expires April 2004 [Page 26] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 11 Authors' Addresses Dr. Vinton G. Cerf MCI Corporation 22001 Loudoun County Parkway Building F2, Room 4115, ATTN: Vint Cerf Ashburn, VA 20147 Telephone +1 (703) 886-1690 FAX +1 (703) 886-0047 Email vcerf@mci.net Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 179-206 Pasadena, CA 91109-8099 Telephone +1 (818) 393-3353 FAX +1 (818) 354-1075 Email Scott.Burleigh@jpl.nasa.gov Robert C. Durst The MITRE Corporation 1820 Dolley Madison Blvd. M/S W650 McLean, VA 22102 Telephone +1 (703) 883-7535 FAX +1 (703) 883-7142 Email durst@mitre.org Dr. Kevin Fall Intel Research, Berkeley 2150 Shattuck Ave., #1300 Berkeley, CA 94704 Telephone +1 (510) 495-3014 FAX +1 (510) 495-3049 Email kfall@intel-research.net Adrian J. Hooke Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 303-400 Pasadena, CA 91109-8099 Telephone +1 (818) 354-3063 FAX +1 (818) 393-3575 Email Adrian.Hooke@jpl.nasa.gov Dr. Keith L. Scott The MITRE Corporation 1820 Dolley Madison Blvd. M/S W650 McLean, VA 22102 Telephone +1 (703) 883-6547 Cerf, et al. Expires April 2004 [Page 27] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 FAX +1 (703) 883-7142 Email kscott@mitre.org Leigh Torgerson Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: T1710- Pasadena, CA 91109-8099 Telephone +1 (818) 393-0695 FAX +1 (818) 354-9068 Email Leigh.Torgerson@jpl.nasa.gov Howard S. Weiss SPARTA, Inc. 9861 Broken Land Parkway Columbia, MD 21046 Telephone +1 (410) 381-9400 x201 FAX +1 (410) 381-5559 Email hsw@sparta.com Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay Tolerant Networking Research Group (DTNRG) web site is located at http://www.dtnrg.org. 12 Intellectual Property Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 13 Copyright Notices Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and Cerf, et al. Expires April 2004 [Page 28] Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003 furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Cerf, et al. Expires April 2004 [Page 29]