doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

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