1 Network Working Group                                            V. Cerf

     2 Request for Comments: 4838              Google/Jet Propulsion Laboratory

     3 Category: Informational                                      S. Burleigh

     4                                                                 A. Hooke

     5                                                             L. Torgerson

     6                                           NASA/Jet Propulsion Laboratory

     7                                                                 R. Durst

     8                                                                 K. Scott

     9                                                    The MITRE Corporation

    10                                                                  K. Fall

    11                                                        Intel Corporation

    12                                                                 H. Weiss

    13                                                             SPARTA, Inc.

    14                                                               April 2007

    15 

    16                 Delay-Tolerant Networking Architecture

    17 

    18 Status of This Memo

    19 

    20    This memo provides information for the Internet community.  It does

    21    not specify an Internet standard of any kind.  Distribution of this

    22    memo is unlimited.

    23 

    24 Copyright Notice

    25 

    26    Copyright (C) The IETF Trust (2007).

    27 

    28 IESG Note

    29 

    30    This RFC is a product of the Internet Research Task Force and is not

    31    a candidate for any level of Internet Standard.  The IRTF publishes

    32    the results of Internet-related research and development activities.

    33    These results might not be suitable for deployment on the public

    34    Internet.

    35 

    36 Abstract

    37 

    38    This document describes an architecture for delay-tolerant and

    39    disruption-tolerant networks, and is an evolution of the architecture

    40    originally designed for the Interplanetary Internet, a communication

    41    system envisioned to provide Internet-like services across

    42    interplanetary distances in support of deep space exploration.  This

    43    document describes an architecture that addresses a variety of

    44    problems with internetworks having operational and performance

    45    characteristics that make conventional (Internet-like) networking

    46    approaches either unworkable or impractical.  We define a message-

    47    oriented overlay that exists above the transport (or other) layers of

    48 

    49    the networks it interconnects.  The document presents a motivation

    50    for the architecture, an architectural overview, review of state

    51    management required for its operation, and a discussion of

    52    application design issues.  This document represents the consensus of

    53    the IRTF DTN research group and has been widely reviewed by that

    54    group.

    55 

    56 Table of Contents

    57 

    58    1. Introduction ....................................................3

    59    2. Why an Architecture for Delay-Tolerant Networking? ..............4

    60    3. DTN Architectural Description ...................................5

    61       3.1. Virtual Message Switching Using Store-and-Forward

    62            Operation ..................................................5

    63       3.2. Nodes and Endpoints ........................................7

    64       3.3. Endpoint Identifiers (EIDs) and Registrations ..............8

    65       3.4. Anycast and Multicast .....................................10

    66       3.5. Priority Classes ..........................................10

    67       3.6. Postal-Style Delivery Options and Administrative Records ..11

    68       3.7. Primary Bundle Fields .....................................15

    69       3.8. Routing and Forwarding ....................................16

    70       3.9. Fragmentation and Reassembly ..............................18

    71       3.10. Reliability and Custody Transfer .........................19

    72       3.11. DTN Support for Proxies and Application Layer Gateways ...21

    73       3.12. Timestamps and Time Synchronization ......................22

    74       3.13. Congestion and Flow Control at the Bundle Layer ..........22

    75       3.14. Security .................................................23

    76    4. State Management Considerations ................................25

    77       4.1. Application Registration State ............................25

    78       4.2. Custody Transfer State ....................................26

    79       4.3. Bundle Routing and Forwarding State .......................26

    80       4.4. Security-Related State ....................................27

    81       4.5. Policy and Configuration State ............................27

    82    5. Application Structuring Issues .................................28

    83    6. Convergence Layer Considerations for Use of Underlying

    84       Protocols ......................................................28

    85    7. Summary ........................................................29

    86    8. Security Considerations ........................................29

    87    9. IANA Considerations ............................................30

    88    10. Normative References ..........................................30

    89    11. Informative References ........................................30

    90    12. Acknowledgments ...............................................32

    91 

    92 1.  Introduction

    93 

    94    This document describes an architecture for delay and disruption-

    95    tolerant interoperable networking (DTN).  The architecture embraces

    96    the concepts of occasionally-connected networks that may suffer from

    97    frequent partitions and that may be comprised of more than one

    98    divergent set of protocols or protocol families.  The basis for this

    99    architecture lies with that of the Interplanetary Internet, which

   100    focused primarily on the issue of deep space communication in high-

   101    delay environments.  We expect the DTN architecture described here to

   102    be utilized in various operational environments, including those

   103    subject to disruption and disconnection and those with high-delay;

   104    the case of deep space is one specialized example of these, and is

   105    being pursued as a specialization of this architecture (See [IPN01]

   106    and [SB03] for more details).

   107 

   108    Other networks to which we believe this architecture applies include

   109    sensor-based networks using scheduled intermittent connectivity,

   110    terrestrial wireless networks that cannot ordinarily maintain end-to-

   111    end connectivity, satellite networks with moderate delays and

   112    periodic connectivity, and underwater acoustic networks with moderate

   113    delays and frequent interruptions due to environmental factors.  A

   114    DTN tutorial [FW03], aimed at introducing DTN and the types of

   115    networks for which it is designed, is available to introduce new

   116    readers to the fundamental concepts and motivation.  More technical

   117    descriptions may be found in [KF03], [JFP04], [JDPF05], and [WJMF05].

   118 

   119    We define an end-to-end message-oriented overlay called the "bundle

   120    layer" that exists at a layer above the transport (or other) layers

   121    of the networks on which it is hosted and below applications.

   122    Devices implementing the bundle layer are called DTN nodes.  The

   123    bundle layer forms an overlay that employs persistent storage to help

   124    combat network interruption.  It includes a hop-by-hop transfer of

   125    reliable delivery responsibility and optional end-to-end

   126    acknowledgement.  It also includes a number of diagnostic and

   127    management features.  For interoperability, it uses a flexible naming

   128    scheme (based on Uniform Resource Identifiers [RFC3986]) capable of

   129    encapsulating different naming and addressing schemes in the same

   130    overall naming syntax.  It also has a basic security model,

   131    optionally enabled, aimed at protecting infrastructure from

   132    unauthorized use.

   133 

   134    The bundle layer provides functionality similar to the internet layer

   135    of gateways described in the original ARPANET/Internet designs

   136    [CK74].  It differs from ARPANET gateways, however, because it is

   137    layer-agnostic and is focused on virtual message forwarding rather

   138    than packet switching.  However, both generally provide

   139    interoperability between underlying protocols specific to one

   140 

   141    environment and those protocols specific to another, and both provide

   142    a store-and-forward forwarding service (with the bundle layer

   143    employing persistent storage for its store and forward function).

   144 

   145    In a sense, the DTN architecture provides a common method for

   146    interconnecting heterogeneous gateways or proxies that employ store-

   147    and-forward message routing to overcome communication disruptions.

   148    It provides services similar to electronic mail, but with enhanced

   149    naming, routing, and security capabilities.  Nodes unable to support

   150    the full capabilities required by this architecture may be supported

   151    by application-layer proxies acting as DTN applications.

   152 

   153 2.  Why an Architecture for Delay-Tolerant Networking?

   154 

   155    Our motivation for pursuing an architecture for delay tolerant

   156    networking stems from several factors.  These factors are summarized

   157    below; much more detail on their rationale can be explored in [SB03],

   158    [KF03], and [DFS02].

   159 

   160    The existing Internet protocols do not work well for some

   161    environments, due to some fundamental assumptions built into the

   162    Internet architecture:

   163 

   164    - that an end-to-end path between source and destination exists for

   165      the duration of a communication session

   166 

   167    - (for reliable communication) that retransmissions based on timely

   168      and stable feedback from data receivers is an effective means for

   169      repairing errors

   170 

   171    - that end-to-end loss is relatively small

   172 

   173    - that all routers and end stations support the TCP/IP protocols

   174 

   175    - that applications need not worry about communication performance

   176 

   177    - that endpoint-based security mechanisms are sufficient for meeting

   178      most security concerns

   179 

   180    - that packet switching is the most appropriate abstraction for

   181      interoperability and performance

   182 

   183    - that selecting a single route between sender and receiver is

   184      sufficient for achieving acceptable communication performance

   185 

   186    The DTN architecture is conceived to relax most of these assumptions,

   187    based on a number of design principles that are summarized here (and

   188    further discussed in [KF03]):

   189 

   190    - Use variable-length (possibly long) messages (not streams or

   191      limited-sized packets) as the communication abstraction to help

   192      enhance the ability of the network to make good scheduling/path

   193      selection decisions when possible.

   194 

   195    - Use a naming syntax that supports a wide range of naming and

   196      addressing conventions to enhance interoperability.

   197 

   198    - Use storage within the network to support store-and-forward

   199      operation over multiple paths, and over potentially long timescales

   200      (i.e., to support operation in environments where many and/or no

   201      end-to-end paths may ever exist); do not require end-to-end

   202      reliability.

   203 

   204    - Provide security mechanisms that protect the infrastructure from

   205      unauthorized use by discarding traffic as quickly as possible.

   206 

   207    - Provide coarse-grained classes of service, delivery options, and a

   208      way to express the useful lifetime of data to allow the network to

   209      better deliver data in serving the needs of applications.

   210 

   211    The use of the bundle layer is guided not only by its own design

   212    principles, but also by a few application design principles:

   213 

   214    - Applications should minimize the number of round-trip exchanges.

   215 

   216    - Applications should cope with restarts after failure while network

   217      transactions remain pending.

   218 

   219    - Applications should inform the network of the useful life and

   220      relative importance of data to be delivered.

   221 

   222    These issues are discussed in further detail in Section 5.

   223 

   224 3.  DTN Architectural Description

   225 

   226    The previous section summarized the design principles that guide the

   227    definition of the DTN architecture.  This section presents a

   228    description of the major features of the architecture resulting from

   229    design decisions guided by the aforementioned design principles.

   230 

   231 3.1.  Virtual Message Switching Using Store-and-Forward Operation

   232 

   233    A DTN-enabled application sends messages of arbitrary length, also

   234    called Application Data Units or ADUs [CT90], which are subject to

   235    any implementation limitations.  The relative order of ADUs might not

   236    be preserved.  ADUs are typically sent by and delivered to

   237 

   238    applications in complete units, although a system interface that

   239    behaves differently is not precluded.

   240 

   241    ADUs are transformed by the bundle layer into one or more protocol

   242    data units called "bundles", which are forwarded by DTN nodes.

   243    Bundles have a defined format containing two or more "blocks" of

   244    data.  Each block may contain either application data or other

   245    information used to deliver the containing bundle to its

   246    destination(s).  Blocks serve the purpose of holding information

   247    typically found in the header or payload portion of protocol data

   248    units in other protocol architectures.  The term "block" is used

   249    instead of "header" because blocks may not appear at the beginning of

   250    a bundle due to particular processing requirements (e.g., digital

   251    signatures).

   252 

   253    Bundles may be split up ("fragmented") into multiple constituent

   254    bundles (also called "fragments" or "bundle fragments") during

   255    transmission.  Fragments are themselves bundles, and may be further

   256    fragmented.  Two or more fragments may be reassembled anywhere in the

   257    network, forming a new bundle.

   258 

   259    Bundle sources and destinations are identified by (variable-length)

   260    Endpoint Identifiers (EIDs, described below), which identify the

   261    original sender and final destination(s) of bundles, respectively.

   262    Bundles also contain a "report-to" EID used when special operations

   263    are requested to direct diagnostic output to an arbitrary entity

   264    (e.g., other than the source).  An EID may refer to one or more DTN

   265    nodes (i.e., for multicast destinations or "report-to" destinations).

   266 

   267    While IP networks are based on "store-and-forward" operation, there

   268    is an assumption that the "storing" will not persist for more than a

   269    modest amount of time, on the order of the queuing and transmission

   270    delay.  In contrast, the DTN architecture does not expect that

   271    network links are always available or reliable, and instead expects

   272    that nodes may choose to store bundles for some time.  We anticipate

   273    that most DTN nodes will use some form of persistent storage for this

   274    -- disk, flash memory, etc. -- and that stored bundles will survive

   275    system restarts.

   276 

   277    Bundles contain an originating timestamp, useful life indicator, a

   278    class of service designator, and a length.  This information provides

   279    bundle-layer routing with a priori knowledge of the size and

   280    performance requirements of requested data transfers.  When there is

   281    a significant amount of queuing that can occur in the network (as is

   282    the case in the DTN version of store-and-forward), the advantage

   283    provided by knowing this information may be significant for making

   284    scheduling and path selection decisions [JFP04].  An alternative

   285    abstraction (i.e., of stream-based delivery based on packets) would

   286 

   287    make such scheduling much more difficult.  Although packets provide

   288    some of the same benefits as bundles, larger aggregates provide a way

   289    for the network to apply scheduling and buffer management to units of

   290    data that are more useful to applications.

   291 

   292    An essential element of the bundle-based style of forwarding is that

   293    bundles have a place to wait in a queue until a communication

   294    opportunity ("contact") is available.  This highlights the following

   295    assumptions:

   296 

   297    1. that storage is available and well-distributed throughout the

   298       network,

   299 

   300    2. that storage is sufficiently persistent and robust to store

   301       bundles until forwarding can occur, and

   302 

   303    3. (implicitly) that this "store-and-forward" model is a better

   304       choice than attempting to effect continuous connectivity or other

   305       alternatives.

   306 

   307    For a network to effectively support the DTN architecture, these

   308    assumptions must be considered and must be found to hold.  Even so,

   309    the inclusion of long-term storage as a fundamental aspect of the DTN

   310    architecture poses new problems, especially with respect to

   311    congestion management and denial-of-service mitigation.  Node storage

   312    in essence represents a new resource that must be managed and

   313    protected.  Much of the research in DTN revolves around exploring

   314    these issues.  Congestion is discussed in Section 3.13, and security

   315    mechanisms, including methods for DTN nodes to protect themselves

   316    from handling unauthorized traffic from other nodes, are discussed in

   317    [DTNSEC] and [DTNSOV].

   318 

   319 3.2.  Nodes and Endpoints

   320 

   321    A DTN node (or simply "node" in this document) is an engine for

   322    sending and receiving bundles -- an implementation of the bundle

   323    layer.  Applications utilize DTN nodes to send or receive ADUs

   324    carried in bundles (applications also use DTN nodes when acting as

   325    report-to destinations for diagnostic information carried in

   326    bundles).  Nodes may be members of groups called "DTN endpoints".  A

   327    DTN endpoint is therefore a set of DTN nodes.  A bundle is considered

   328    to have been successfully delivered to a DTN endpoint when some

   329    minimum subset of the nodes in the endpoint has received the bundle

   330    without error.  This subset is called the "minimum reception group"

   331    (MRG) of the endpoint.  The MRG of an endpoint may refer to one node

   332    (unicast), one of a group of nodes (anycast), or all of a group of

   333    nodes (multicast and broadcast).  A single node may be in the MRG of

   334    multiple endpoints.

   335 

   336 3.3.  Endpoint Identifiers (EIDs) and Registrations

   337 

   338    An Endpoint Identifier (EID) is a name, expressed using the general

   339    syntax of URIs (see below), that identifies a DTN endpoint.  Using an

   340    EID, a node is able to determine the MRG of the DTN endpoint named by

   341    the EID.  Each node is also required to have at least one EID that

   342    uniquely identifies it.

   343 

   344    Applications send ADUs destined for an EID, and may arrange for ADUs

   345    sent to a particular EID to be delivered to them.  Depending on the

   346    construction of the EID being used (see below), there may be a

   347    provision for wildcarding some portion of an EID, which is often

   348    useful for diagnostic and routing purposes.

   349 

   350    An application's desire to receive ADUs destined for a particular EID

   351    is called a "registration", and in general is maintained persistently

   352    by a DTN node.  This allows application registration information to

   353    survive application and operating system restarts.

   354 

   355    An application's attempt to establish a registration is not

   356    guaranteed to succeed.  For example, an application could request to

   357    register itself to receive ADUs by specifying an Endpoint ID that is

   358    uninterpretable or unavailable to the DTN node servicing the request.

   359    Such requests are likely to fail.

   360 

   361 3.3.1.  URI Schemes

   362 

   363    Each Endpoint ID is expressed syntactically as a Uniform Resource

   364    Identifier (URI) [RFC3986].  The URI syntax has been designed as a

   365    way to express names or addresses for a wide range of purposes, and

   366    is therefore useful for constructing names for DTN endpoints.

   367 

   368    In URI terminology, each URI begins with a scheme name.  The scheme

   369    name is an element of the set of globally-managed scheme names

   370    maintained by IANA [ISCHEMES].  Lexically following the scheme name

   371    in a URI is a series of characters constrained by the syntax defined

   372    by the scheme.  This portion of the URI is called the scheme-specific

   373    part (SSP), and can be quite general.  (See, as one example, the URI

   374    scheme for SNMP [RFC4088]).  Note that scheme-specific syntactical

   375    and semantic restrictions may be more constraining than the basic

   376    rules of RFC 3986.  Section 3.1 of RFC 3986 provides guidance on the

   377    syntax of scheme names.

   378 

   379    URI schemes are a key concept in the DTN architecture, and evolved

   380    from an earlier concept called regions, which were tied more closely

   381    to assumptions of the network topology.  Using URIs, significant

   382    flexibility is attained in the structuring of EIDs.  They might, for

   383    example, be constructed based on DNS names, or might look like

   384 

   385    "expressions of interest" or forms of database-like queries as in a

   386    directed diffusion-routed network [IGE00] or in intentional naming

   387    [WSBL99].  As names, EIDs are not required to be related to routing

   388    or topological organization.  Such a relationship is not prohibited,

   389    however, and in some environments using EIDs this way may be

   390    advantageous.

   391 

   392    A single EID may refer to an endpoint containing more than one DTN

   393    node, as suggested above.  It is the responsibility of a scheme

   394    designer to define how to interpret the SSP of an EID so as to

   395    determine whether it refers to a unicast, multicast, or anycast set

   396    of nodes.  See Section 3.4 for more details.

   397 

   398    URIs are constructed based on rules specified in RFC 3986, using the

   399    US-ASCII character set.  However, note this excerpt from RFC 3986,

   400    Section 1.2.1, on dealing with characters that cannot be represented

   401    by US-ASCII:  "Percent-encoded octets (Section 2.1) may be used

   402    within a URI to represent characters outside the range of the US-

   403    ASCII coded character set if this representation is allowed by the

   404    scheme or by the protocol element in which the URI is referenced.

   405    Such a definition should specify the character encoding used to map

   406    those characters to octets prior to being percent-encoded for the

   407    URI".

   408 

   409 3.3.2.  Late Binding

   410 

   411    Binding means interpreting the SSP of an EID for the purpose of

   412    carrying an associated message towards a destination.  For example,

   413    binding might require mapping an EID to a next-hop EID or to a lower-

   414    layer address for transmission.  "Late binding" means that the

   415    binding of a bundle's destination to a particular set of destination

   416    identifiers or addresses does not necessarily happen at the bundle

   417    source.  Because the destination EID is potentially re-interpreted at

   418    each hop, the binding may occur at the source, during transit, or

   419    possibly at the destination(s).  This contrasts with the name-to-

   420    address binding of Internet communications where a DNS lookup at the

   421    source fixes the IP address of the destination node before data is

   422    sent.  Such a circumstance would be considered "early binding"

   423    because the name-to-address translation is performed prior to data

   424    being sent into the network.

   425 

   426    In a frequently-disconnected network, late binding may be

   427    advantageous because the transit time of a message may exceed the

   428    validity time of a binding, making binding at the source impossible

   429    or invalid.  Furthermore, use of name-based routing with late binding

   430    may reduce the amount of administrative (mapping) information that

   431 

   432    must propagate through the network, and may also limit the scope of

   433    mapping synchronization requirements to a local topological

   434    neighborhood where changes are made.

   435 

   436 3.4.  Anycast and Multicast

   437 

   438    As mentioned above, an EID may refer to an endpoint containing one or

   439    more DTN nodes.  When referring to a group of size greater than one,

   440    the delivery semantics may be of either the anycast or multicast

   441    variety (broadcast is considered to be of the multicast variety).

   442    For anycast group delivery, a bundle is delivered to one node among a

   443    group of potentially many nodes, and for multicast delivery it is

   444    intended to be delivered to all of them, subject to the normal DTN

   445    class of service and maximum useful lifetime semantics.

   446 

   447    Multicast group delivery in a DTN presents an unfamiliar issue with

   448    respect to group membership.  In relatively low-delay networks, such

   449    as the Internet, nodes may be considered to be part of the group if

   450    they have expressed interest to join it "recently".  In a DTN,

   451    however, nodes may wish to receive data sent to a group during an

   452    interval of time earlier than when they are actually able to receive

   453    it [ZAZ05].  More precisely, an application expresses its desire to

   454    receive data sent to EID e at time t.  Prior to this, during the

   455    interval [t0, t1], t > t1, data may have been generated for group e.

   456    For the application to receive any of this data, the data must be

   457    available a potentially long time after senders have ceased sending

   458    to the group.  Thus, the data may need to be stored within the

   459    network in order to support temporal group semantics of this kind.

   460    How to design and implement this remains a research issue, as it is

   461    likely to be at least as hard as problems related to reliable

   462    multicast.

   463 

   464 3.5.  Priority Classes

   465 

   466    The DTN architecture offers *relative* measures of priority (low,

   467    medium, high) for delivering ADUs.  These priorities differentiate

   468    traffic based upon an application's desire to affect the delivery

   469    urgency for ADUs, and are carried in bundle blocks generated by the

   470    bundle layer based on information specified by the application.

   471 

   472    The (U.S. or similar) Postal Service provides a strong metaphor for

   473    the priority classes offered by the forwarding abstraction offered by

   474    the DTN architecture.  Traffic is generally not interactive and is

   475    often one-way.  There are generally no strong guarantees of timely

   476    delivery, yet there are some forms of class of service, reliability,

   477    and security.

   478 

   479    We have defined three relative priority classes to date.  These

   480    priority classes typically imply some relative scheduling

   481    prioritization among bundles in queue at a sender:

   482 

   483    - Bulk - Bulk bundles are shipped on a "least effort" basis.  No

   484      bundles of this class will be shipped until all bundles of other

   485      classes bound for the same destination and originating from the

   486      same source have been shipped.

   487 

   488    - Normal - Normal-class bundles are shipped prior to any bulk-class

   489      bundles and are otherwise the same as bulk bundles.

   490 

   491    - Expedited - Expedited bundles, in general, are shipped prior to

   492      bundles of other classes and are otherwise the same.

   493 

   494    Applications specify their requested priority class and data lifetime

   495    (see below) for each ADU they send.  This information, coupled with

   496    policy applied at DTN nodes that select how messages are forwarded

   497    and which routing algorithms are in use, affects the overall

   498    likelihood and timeliness of ADU delivery.

   499 

   500    The priority class of a bundle is only required to relate to other

   501    bundles from the same source.  This means that a high priority bundle

   502    from one source may not be delivered faster (or with some other

   503    superior quality of service) than a medium priority bundle from a

   504    different source.  It does mean that a high priority bundle from one

   505    source will be handled preferentially to a lower priority bundle sent

   506    from the same source.

   507 

   508    Depending on a particular DTN node's forwarding/scheduling policy,

   509    priority may or may not be enforced across different sources.  That

   510    is, in some DTN nodes, expedited bundles might always be sent prior

   511    to any bulk bundles, irrespective of source.  Many variations are

   512    possible.

   513 

   514 3.6.  Postal-Style Delivery Options and Administrative Records

   515 

   516    Continuing with the postal analogy, the DTN architecture supports

   517    several delivery options that may be selected by an application when

   518    it requests the transmission of an ADU.  In addition, the

   519    architecture defines two types of administrative records: "status

   520    reports" and "signals".  These records are bundles that provide

   521    information about the delivery of other bundles, and are used in

   522    conjunction with the delivery options.

   523 

   524 3.6.1.  Delivery Options

   525 

   526    We have defined eight delivery options.  Applications sending an ADU

   527    (the "subject ADU") may request any combination of the following,

   528    which are carried in each of the bundles produced ("sent bundles") by

   529    the bundle layer resulting from the application's request to send the

   530    subject ADU:

   531 

   532    - Custody Transfer Requested - requests sent bundles be delivered

   533      with enhanced reliability using custody transfer procedures.  Sent

   534      bundles will be transmitted by the bundle layer using reliable

   535      transfer protocols (if available), and the responsibility for

   536      reliable delivery of the bundle to its destination(s) may move

   537      among one or more "custodians" in the network.  This capability is

   538      described in more detail in Section 3.10.

   539 

   540    - Source Node Custody Acceptance Required - requires the source DTN

   541      node to provide custody transfer for the sent bundles.  If custody

   542      transfer is not available at the source when this delivery option

   543      is requested, the requested transmission fails.  This provides a

   544      means for applications to insist that the source DTN node take

   545      custody of the sent bundles (e.g., by storing them in persistent

   546      storage).

   547 

   548    - Report When Bundle Delivered - requests a (single) Bundle Delivery

   549      Status Report be generated when the subject ADU is delivered to its

   550      intended recipient(s).  This request is also known as "return-

   551      receipt".

   552 

   553    - Report When Bundle Acknowledged by Application - requests an

   554      Acknowledgement Status Report be generated when the subject ADU is

   555      acknowledged by a receiving application.  This only happens by

   556      action of the receiving application, and differs from the Bundle

   557      Delivery Status Report.  It is intended for cases where the

   558      application may be acting as a form of application layer gateway

   559      and wishes to indicate the status of a protocol operation external

   560      to DTN back to the requesting source.  See Section 11 for more

   561      details.

   562 

   563    - Report When Bundle Received - requests a Bundle Reception Status

   564      Report be generated when each sent bundle arrives at a DTN node.

   565      This is designed primarily for diagnostic purposes.

   566 

   567    - Report When Bundle Custody Accepted  - requests a Custody

   568      Acceptance Status Report be generated when each sent bundle has

   569      been accepted using custody transfer.  This is designed primarily

   570      for diagnostic purposes.

   571 

   572    - Report When Bundle Forwarded - requests a Bundle Forwarding Status

   573      Report be generated when each sent bundle departs a DTN node after

   574      forwarding.  This is designed primarily for diagnostic purposes.

   575 

   576    - Report When Bundle Deleted - requests a Bundle Deletion Status

   577      Report be generated when each sent bundle is deleted at a DTN node.

   578      This is designed primarily for diagnostic purposes.

   579 

   580    The first four delivery options are designed for ordinary use by

   581    applications.  The last four are designed primarily for diagnostic

   582    purposes and their use may be restricted or limited in environments

   583    subject to congestion or attack.

   584 

   585    If the security procedures defined in [DTNSEC] are also enabled, then

   586    three additional delivery options become available:

   587 

   588    - Confidentiality Required - requires the subject ADU be made secret

   589      from parties other than the source and the members of the

   590      destination EID.

   591 

   592    - Authentication Required - requires all non-mutable fields in the

   593      bundle blocks of the sent bundles (i.e., those which do not change

   594      as the bundle is forwarded) be made strongly verifiable (i.e.,

   595      cryptographically strong).  This protects several fields, including

   596      the source and destination EIDs and the bundle's data.  See Section

   597      3.7 and [BSPEC] for more details.

   598 

   599    - Error Detection Required - requires modifications to the non-

   600      mutable fields of each sent bundle be made detectable with high

   601      probability at each destination.

   602 

   603 3.6.2.  Administrative Records: Bundle Status Reports and Custody

   604         Signals

   605 

   606    Administrative records are used to report status information or error

   607    conditions related to the bundle layer.  There are two types of

   608    administrative records defined:  bundle status reports (BSRs) and

   609    custody signals.  Administrative records correspond (approximately)

   610    to messages in the ICMP protocol in IP [RFC792].  In ICMP, however,

   611    messages are returned to the source.  In DTN, they are instead

   612    directed to the report-to EID for BSRs and the EID of the current

   613    custodian for custody signals, which might differ from the source's

   614    EID.  Administrative records are sent as bundles with a source EID

   615    set to one of the EIDs associated with the DTN node generating the

   616    administrative record.  In some cases, arrival of a single bundle or

   617    bundle fragment may elicit multiple administrative records (e.g., in

   618    the case where a bundle is replicated for multicast forwarding).

   619 

   620    The following BSRs are currently defined (also see [BSPEC] for more

   621    details):

   622 

   623    - Bundle Reception - sent when a bundle arrives at a DTN node.

   624      Generation of this message may be limited by local policy.

   625 

   626    - Custody Acceptance - sent when a node has accepted custody of a

   627      bundle with the Custody Transfer Requested option set.  Generation

   628      of this message may be limited by local policy.

   629 

   630    - Bundle Forwarded - sent when a bundle containing a Report When

   631      Bundle Forwarded option departs from a DTN node after having been

   632      forwarded.  Generation of this message may be limited by local

   633      policy.

   634 

   635    - Bundle Deletion - sent from a DTN node when a bundle containing a

   636      Report When Bundle Deleted option is discarded.  This can happen

   637      for several reasons, such as expiration.  Generation of this

   638      message may be limited by local policy but is required in cases

   639      where the deletion is performed by a bundle's current custodian.

   640 

   641    - Bundle Delivery - sent from a final recipient's (destination) node

   642      when a complete ADU comprising sent bundles containing Report When

   643      Bundle Delivered options is consumed by an application.

   644 

   645    - Acknowledged by application - sent from a final recipient's

   646      (destination) node when a complete ADU comprising sent bundles

   647      containing Application Acknowledgment options has been processed by

   648      an application.  This generally involves specific action on the

   649      receiving application's part.

   650 

   651    In addition to the status reports, the custody signal is currently

   652    defined to indicate the status of a custody transfer.  These are sent

   653    to the current-custodian EID contained in an arriving bundle:

   654 

   655    - Custody Signal - indicates that custody has been successfully

   656      transferred.  This signal appears as a Boolean indicator, and may

   657      therefore indicate either a successful or a failed custody transfer

   658      attempt.

   659 

   660    Administrative records must reference a received bundle.  This is

   661    accomplished by a method for uniquely identifying bundles based on a

   662    transmission timestamp and sequence number discussed in Section 3.12.

   663 

   664 3.7.  Primary Bundle Fields

   665 

   666    The bundles carried between and among DTN nodes obey a standard

   667    bundle protocol specified in [BSPEC].  Here we provide an overview of

   668    most of the fields carried with every bundle.  The protocol is

   669    designed with a mandatory primary block, an optional payload block

   670    (which contains the ADU data itself), and a set of optional extension

   671    blocks.  Blocks may be cascaded in a way similar to extension headers

   672    in IPv6.  The following selected fields are all present in the

   673    primary block, and therefore are present for every bundle and

   674    fragment:

   675 

   676    - Creation Timestamp - a concatenation of the bundle's creation time

   677      and a monotonically increasing sequence number such that the

   678      creation timestamp is guaranteed to be unique for each ADU

   679      originating from the same source.  The creation timestamp is based

   680      on the time-of-day an application requested an ADU to be sent (not

   681      when the corresponding bundle(s) are sent into the network).  DTN

   682      nodes are assumed to have a basic time synchronization capability

   683      (see Section 3.12).

   684 

   685    - Lifespan - the time-of-day at which the message is no longer

   686      useful.  If a bundle is stored in the network (including the

   687      source's DTN node) when its lifespan is reached, it may be

   688      discarded.  The lifespan of a bundle is expressed as an offset

   689      relative to its creation time.

   690 

   691    - Class of Service Flags - indicates the delivery options and

   692      priority class for the bundle.  Priority classes may be one of

   693      bulk, normal, or expedited.  See Section 3.6.1.

   694 

   695    - Source EID - EID of the source (the first sender).

   696 

   697    - Destination EID - EID of the destination (the final intended

   698      recipient(s)).

   699 

   700    - Report-To Endpoint ID - an EID identifying where reports (return-

   701      receipt, route-tracing functions) should be sent.  This may or may

   702      not identify the same endpoint as the Source EID.

   703 

   704    - Custodian EID - EID of the current custodian of a bundle (if any).

   705 

   706    The payload block indicates information about the contained payload

   707    (e.g., its length) and the payload itself.  In addition to the fields

   708    found in the primary and payload blocks, each bundle may have fields

   709    in additional blocks carried with each bundle.  See [BSPEC] for

   710    additional details.

   711 

   712 3.8.  Routing and Forwarding

   713 

   714    The DTN architecture provides a framework for routing and forwarding

   715    at the bundle layer for unicast, anycast, and multicast messages.

   716    Because nodes in a DTN network might be interconnected using more

   717    than one type of underlying network technology, a DTN network is best

   718    described abstractly using a *multigraph* (a graph where vertices may

   719    be interconnected with more than one edge).  Edges in this graph are,

   720    in general, time-varying with respect to their delay and capacity and

   721    directional because of the possibility of one-way connectivity.  When

   722    an edge has zero capacity, it is considered to not be connected.

   723 

   724    Because edges in a DTN graph may have significant delay, it is

   725    important to distinguish where time is measured when expressing an

   726    edge's capacity or delay.  We adopt the convention of expressing

   727    capacity and delay as functions of time where time is measured at the

   728    point where data is inserted into a network edge.  For example,

   729    consider an edge having capacity C(t) and delay D(t) at time t.  If B

   730    bits are placed in this edge at time t, they completely arrive by

   731    time t + D(t) + (1/C(t))*B.  We assume C(t) and D(t) do not change

   732    significantly during the interval [t, t+D(t)+(1/C(t))*B].

   733 

   734    Because edges may vary between positive and zero capacity, it is

   735    possible to describe a period of time (interval) during which the

   736    capacity is strictly positive, and the delay and capacity can be

   737    considered to be constant [AF03].  This period of time is called a

   738    "contact".  In addition, the product of the capacity and the interval

   739    is known as a contact's "volume".  If contacts and their volumes are

   740    known ahead of time, intelligent routing and forwarding decisions can

   741    be made (optimally for small networks) [JFP04].  Optimally using a

   742    contact's volume, however, requires the ability to divide large ADUs

   743    and bundles into smaller routable units.  This is provided by DTN

   744    fragmentation (see Section 3.9).

   745 

   746    When delivery paths through a DTN graph are lossy or contact

   747    intervals and volumes are not known precisely ahead of time, routing

   748    computations become especially challenging.  How to handle these

   749    situations is an active area of work in the (emerging) research area

   750    of delay tolerant networking.

   751 

   752 3.8.1.  Types of Contacts

   753 

   754    Contacts typically fall into one of several categories, based largely

   755    on the predictability of their performance characteristics and

   756    whether some action is required to bring them into existence.  To

   757    date, the following major types of contacts have been defined:

   758 

   759    Persistent Contacts

   760 

   761       Persistent contacts are always available (i.e., no connection-

   762       initiation action is required to instantiate a persistent

   763       contact).  An 'always-on' Internet connection such as a DSL or

   764       Cable Modem connection would be a representative of this class.

   765 

   766    On-Demand Contacts

   767 

   768       On-Demand contacts require some action in order to instantiate,

   769       but then function as persistent contacts until terminated.  A

   770       dial-up connection is an example of an On-Demand contact (at

   771       least, from the viewpoint of the dialer; it may be viewed as an

   772       Opportunistic Contact, below, from the viewpoint of the dial-up

   773       service provider).

   774 

   775    Intermittent - Scheduled Contacts

   776 

   777       A scheduled contact is an agreement to establish a contact at a

   778       particular time, for a particular duration.  An example of a

   779       scheduled contact is a link with a low-earth orbiting satellite.

   780       A node's list of contacts with the satellite can be constructed

   781       from the satellite's schedule of view times, capacities, and

   782       latencies.  Note that for networks with substantial delays, the

   783       notion of the "particular time" is delay-dependent.  For example,

   784       a single scheduled contact between Earth and Mars would not be at

   785       the same instant in each location, but would instead be offset by

   786       the (non-negligible) propagation delay.

   787 

   788    Intermittent - Opportunistic Contacts

   789 

   790       Opportunistic contacts are not scheduled, but rather present

   791       themselves unexpectedly.  For example, an unscheduled aircraft

   792       flying overhead and beaconing, advertising its availability for

   793       communication, would present an opportunistic contact.  Another

   794       type of opportunistic contact might be via an infrared or

   795       Bluetooth communication link between a personal digital assistant

   796       (PDA) and a kiosk in an airport concourse.  The opportunistic

   797       contact begins as the PDA is brought near the kiosk, lasting an

   798       undetermined amount of time (i.e., until the link is lost or

   799       terminated).

   800 

   801    Intermittent - Predicted Contacts

   802 

   803       Predicted contacts are based on no fixed schedule, but rather are

   804       predictions of likely contact times and durations based on a

   805       history of previously observed contacts or some other information.

   806       Given a great enough confidence in a predicted contact, routes may

   807 

   808       be chosen based on this information.  This is an active research

   809       area, and a few approaches having been proposed [LFC05].

   810 

   811 3.9.  Fragmentation and Reassembly

   812 

   813    DTN fragmentation and reassembly are designed to improve the

   814    efficiency of bundle transfers by ensuring that contact volumes are

   815    fully utilized and by avoiding retransmission of partially-forwarded

   816    bundles.  There are two forms of DTN fragmentation/reassembly:

   817 

   818    Proactive Fragmentation

   819 

   820       A DTN node may divide a block of application data into multiple

   821       smaller blocks and transmit each such block as an independent

   822       bundle.  In this case, the *final destination(s)* are responsible

   823       for extracting the smaller blocks from incoming bundles and

   824       reassembling them into the original larger bundle and, ultimately,

   825       ADU.  This approach is called proactive fragmentation because it

   826       is used primarily when contact volumes are known (or predicted) in

   827       advance.

   828 

   829    Reactive Fragmentation

   830 

   831       DTN nodes sharing an edge in the DTN graph may fragment a bundle

   832       cooperatively when a bundle is only partially transferred.  In

   833       this case, the receiving bundle layer modifies the incoming bundle

   834       to indicate it is a fragment, and forwards it normally.  The

   835       previous- hop sender may learn (via convergence-layer protocols,

   836       see Section 6) that only a portion of the bundle was delivered to

   837       the next hop, and send the remaining portion(s) when subsequent

   838       contacts become available (possibly to different next-hops if

   839       routing changes).  This is called reactive fragmentation because

   840       the fragmentation process occurs after an attempted transmission

   841       has taken place.

   842 

   843       As an example, consider a ground station G, and two store-and-

   844       forward satellites S1 and S2, in opposite low-earth orbit.  While

   845       G is transmitting a large bundle to S1, a reliable transport layer

   846       protocol below the bundle layer at each indicates the transmission

   847       has terminated, but that half the transfer has completed

   848       successfully.  In this case, G can form a smaller bundle fragment

   849       consisting of the second half of the original bundle and forward

   850       it to S2 when available.  In addition, S1 (now out of range of G)

   851       can form a new bundle consisting of the first half of the original

   852       bundle and forward it to whatever next hop(s) it deems

   853       appropriate.

   854 

   855    The reactive fragmentation capability is not required to be available

   856    in every DTN implementation, as it requires a certain level of

   857    support from underlying protocols that may not be present, and

   858    presents significant challenges with respect to handling digital

   859    signatures and authentication codes on messages.  When a signed

   860    message is only partially received, most message authentication codes

   861    will fail.  When DTN security is present and enabled, it may

   862    therefore be necessary to proactively fragment large bundles into

   863    smaller units that are more convenient for digital signatures.

   864 

   865    Even if reactive fragmentation is not present in an implementation,

   866    the ability to reassemble fragments at a destination is required in

   867    order to support DTN fragmentation.  Furthermore, for contacts with

   868    volumes that are small compared to typical bundle sizes, some

   869    incremental delivery approach must be used (e.g., checkpoint/restart)

   870    to prevent data delivery livelock.  Reactive fragmentation is one

   871    such approach, but other protocol layers could potentially handle

   872    this issue as well.

   873 

   874 3.10.  Reliability and Custody Transfer

   875 

   876    The most basic service provided by the bundle layer is

   877    unacknowledged, prioritized (but not guaranteed) unicast message

   878    delivery.  It also provides two options for enhancing delivery

   879    reliability:  end-to-end acknowledgments and custody transfer.

   880    Applications wishing to implement their own end-to-end message

   881    reliability mechanisms are free to utilize the acknowledgment.  The

   882    custody transfer feature of the DTN architecture only specifies a

   883    coarse-grained retransmission capability, described next.

   884 

   885    Transmission of bundles with the Custody Transfer Requested option

   886    specified generally involves moving the responsibility for reliable

   887    delivery of an ADU's bundles among different DTN nodes in the

   888    network.  For unicast delivery, this will typically involve moving

   889    bundles "closer" (in terms of some routing metric) to their ultimate

   890    destination(s), and retransmitting when necessary.  The nodes

   891    receiving these bundles along the way (and agreeing to accept the

   892    reliable delivery responsibility) are called "custodians".  The

   893    movement of a bundle (and its delivery responsibility) from one node

   894    to another is called a "custody transfer".  It is analogous to a

   895    database commit transaction [FHM03].  The exact meaning and design of

   896    custody transfer for multicast and anycast delivery remains to be

   897    fully explored.

   898 

   899    Custody transfer allows the source to delegate retransmission

   900    responsibility and recover its retransmission-related resources

   901    relatively soon after sending a bundle (on the order of the minimum

   902    round-trip time to the first bundle hop(s)).  Not all nodes in a DTN

   903 

   904    are required by the DTN architecture to accept custody transfers, so

   905    it is not a true 'hop-by-hop' mechanism.  For example, some nodes may

   906    have sufficient storage resources to sometimes act as custodians, but

   907    may elect to not offer such services when congested or running low on

   908    power.

   909 

   910    The existence of custodians can alter the way DTN routing is

   911    performed.  In some circumstances, it may be beneficial to move a

   912    bundle to a custodian as quickly as possible even if the custodian is

   913    further away (in terms of distance, time or some routing metric) from

   914    the bundle's final destination(s) than some other reachable node.

   915    Designing a system with this capability involves constructing more

   916    than one routing graph, and is an area of continued research.

   917 

   918    Custody transfer in DTN not only provides a method for tracking

   919    bundles that require special handling and identifying DTN nodes that

   920    participate in custody transfer, it also provides a (weak) mechanism

   921    for enhancing the reliability of message delivery.  Generally

   922    speaking, custody transfer relies on underlying reliable delivery

   923    protocols of the networks that it operates over to provide the

   924    primary means of reliable transfer from one bundle node to the next

   925    (set).  However, when custody transfer is requested, the bundle layer

   926    provides an additional coarse-grained timeout and retransmission

   927    mechanism and an accompanying (bundle-layer) custodian-to-custodian

   928    acknowledgment signaling mechanism.  When an application does *not*

   929    request custody transfer, this bundle layer timeout and

   930    retransmission mechanism is typically not employed, and successful

   931    bundle layer delivery depends solely on the reliability mechanisms of

   932    the underlying protocols.

   933 

   934    When a node accepts custody for a bundle that contains the Custody

   935    Transfer Requested option, a Custody Transfer Accepted Signal is sent

   936    by the bundle layer to the Current Custodian EID contained in the

   937    primary bundle block.  In addition, the Current Custodian EID is

   938    updated to contain one of the forwarding node's (unicast) EIDs before

   939    the bundle is forwarded.

   940 

   941    When an application requests an ADU to be delivered with custody

   942    transfer, the request is advisory.  In some circumstances, a source

   943    of a bundle for which custody transfer has been requested may not be

   944    able to provide this service.  In such circumstances, the subject

   945    bundle may traverse multiple DTN nodes before it obtains a custodian.

   946    Bundles in this condition are specially marked with their Current

   947    Custodian EID field set to a null endpoint.  In cases where

   948    applications wish to require the source to take custody of the

   949    bundle, they may supply the Source Node Custody Acceptance Required

   950 

   951    delivery option.  This may be useful to applications that desire a

   952    continuous "chain" of custody or that wish to exit after being

   953    ensured their data is safely held in a custodian.

   954 

   955    In a DTN network where one or more custodian-to-custodian hops are

   956    strictly one directional (and cannot be reversed), the DTN custody

   957    transfer mechanism will be affected over such hops due to the lack of

   958    any way to receive a custody signal (or any other information) back

   959    across the path, resulting in the expiration of the bundle at the

   960    ingress to the one-way hop.  This situation does not necessarily mean

   961    the bundle has been lost; nodes on the other side of the hop may

   962    continue to transfer custody, and the bundle may be delivered

   963    successfully to its destination(s).  However, in this circumstance a

   964    source that has requested to receive expiration BSRs for this bundle

   965    will receive an expiration report for the bundle, and possibly

   966    conclude (incorrectly) that the bundle has been discarded and not

   967    delivered.  Although this problem cannot be fully solved in this

   968    situation, a mechanism is provided to help ameliorate the seemingly

   969    incorrect information that may be reported when the bundle expires

   970    after having been transferred over a one-way hop.  This is

   971    accomplished by the node at the ingress to the one-way hop reporting

   972    the existence of a known one-way path using a variant of a bundle

   973    status report.  These types of reports are provided if the subject

   974    bundle requests the report using the 'Report When Bundle Forwarded'

   975    delivery option.

   976 

   977 3.11.  DTN Support for Proxies and Application Layer Gateways

   978 

   979    One of the aims of DTN is to provide a common method for

   980    interconnecting application layer gateways and proxies.  In cases

   981    where existing Internet applications can be made to tolerate delays,

   982    local proxies can be constructed to benefit from the existing

   983    communication capabilities provided by DTN [S05, T02].  Making such

   984    proxies compatible with DTN reduces the burden on the proxy author

   985    from being concerned with how to implement routing and reliability

   986    management and allows existing TCP/IP-based applications to operate

   987    unmodified over a DTN-based network.

   988 

   989    When DTN is used to provide a form of tunnel encapsulation for other

   990    protocols, it can be used in constructing overlay networks comprised

   991    of application layer gateways.  The application acknowledgment

   992    capability is designed for such circumstances.  This provides a

   993    common way for remote application layer gateways to signal the

   994    success or failure of non-DTN protocol operations initiated as a

   995    result of receiving DTN ADUs.  Without this capability, such

   996    indicators would have to be implemented by applications themselves in

   997    non-standard ways.

   998 

   999 3.12.  Timestamps and Time Synchronization

  1000 

  1001    The DTN architecture depends on time synchronization among DTN nodes

  1002    (supported by external, non-DTN protocols) for four primary purposes:

  1003    bundle and fragment identification, routing with scheduled or

  1004    predicted contacts, bundle expiration time computations, and

  1005    application registration expiration.

  1006 

  1007    Bundle identification and expiration are supported by placing a

  1008    creation timestamp and an explicit expiration field (expressed in

  1009    seconds after the source timestamp) in each bundle.  The origination

  1010    timestamps on arriving bundles are made available to consuming

  1011    applications in ADUs they receive by some system interface function.

  1012    Each set of bundles corresponding to an ADU is required to contain a

  1013    timestamp unique to the sender's EID.  The EID, timestamp, and data

  1014    offset/length information together uniquely identify a bundle.

  1015    Unique bundle identification is used for a number of purposes,

  1016    including custody transfer and reassembly of bundle fragments.

  1017 

  1018    Time is also used in conjunction with application registrations.

  1019    When an application expresses its desire to receive ADUs destined for

  1020    a particular EID, this registration is only maintained for a finite

  1021    period of time, and may be specified by the application.  For

  1022    multicast registrations, an application may also specify a time range

  1023    or "interest interval" for its registration.  In this case, traffic

  1024    sent to the specified EID any time during the specified interval will

  1025    eventually be delivered to the application (unless such traffic has

  1026    expired due to the expiration time provided by the application at the

  1027    source or some other reason prevents such delivery).

  1028 

  1029 3.13.  Congestion and Flow Control at the Bundle Layer

  1030 

  1031    The subject of congestion control and flow control at the bundle

  1032    layer is one on which the authors of this document have not yet

  1033    reached complete consensus.  We have unresolved concerns about the

  1034    efficiency and efficacy of congestion and flow control schemes

  1035    implemented across long and/or highly variable delay environments,

  1036    especially with the custody transfer mechanism that may require nodes

  1037    to retain bundles for long periods of time.

  1038 

  1039    For the purposes of this document, we define "flow control" as a

  1040    means of assuring that the average rate at which a sending node

  1041    transmits data to a receiving node does not exceed the average rate

  1042    at which the receiving node is prepared to receive data from that

  1043    sender. (Note that this is a generalized notion of flow control,

  1044    rather than one that applies only to end-to-end communication.)  We

  1045    define "congestion control" as a means of assuring that the aggregate

  1046    rate at which all traffic sources inject data into a network does not

  1047 

  1048    exceed the maximum aggregate rate at which the network can deliver

  1049    data to destination nodes over time.  If flow control is propagated

  1050    backward from congested nodes toward traffic sources, then the flow

  1051    control mechanism can be used as at least a partial solution to the

  1052    problem of congestion as well.

  1053 

  1054    DTN flow control decisions must be made within the bundle layer

  1055    itself based on information about resources (in this case, primarily

  1056    persistent storage) available within the bundle node.  When storage

  1057    resources become scarce, a DTN node has only a certain degree of

  1058    freedom in handling the situation.  It can always discard bundles

  1059    which have expired -- an activity DTN nodes should perform regularly

  1060    in any case.  If it ordinarily is willing to accept custody for

  1061    bundles, it can cease doing so.  If storage resources are available

  1062    elsewhere in the network, it may be able to make use of them in some

  1063    way for bundle storage.  It can also discard bundles which have not

  1064    expired but for which it has not accepted custody.  A node must avoid

  1065    discarding bundles for which it has accepted custody, and do so only

  1066    as a last resort.  Determining when a node should engage in or cease

  1067    to engage in custody transfers is a resource allocation and

  1068    scheduling problem of current research interest.

  1069 

  1070    In addition to the bundle layer mechanisms described above, a DTN

  1071    node may be able to avail itself of support from lower-layer

  1072    protocols in affecting its own resource utilization.  For example, a

  1073    DTN node receiving a bundle using TCP/IP might intentionally slow

  1074    down its receiving rate by performing read operations less frequently

  1075    in order to reduce its offered load.  This is possible because TCP

  1076    provides its own flow control, so reducing the application data

  1077    consumption rate could effectively implement a form of hop-by-hop

  1078    flow control.  Unfortunately, it may also lead to head-of-line

  1079    blocking issues, depending on the nature of bundle multiplexing

  1080    within a TCP connection.  A protocol with more relaxed ordering

  1081    constraints (e.g. SCTP [RFC2960]) might be preferable in such

  1082    circumstances.

  1083 

  1084    Congestion control is an ongoing research topic.

  1085 

  1086 3.14.  Security

  1087 

  1088    The possibility of severe resource scarcity in some delay-tolerant

  1089    networks dictates that some form of authentication and access control

  1090    to the network itself is required in many circumstances.  It is not

  1091    acceptable for an unauthorized user to flood the network with traffic

  1092    easily, possibly denying service to authorized users.  In many cases

  1093    it is also not acceptable for unauthorized traffic to be forwarded

  1094    over certain network links at all.  This is especially true for

  1095    exotic, mission-critical links.  In light of these considerations,

  1096 

  1097    several goals are established for the security component of the DTN

  1098    architecture:

  1099 

  1100    - Promptly prevent unauthorized applications from having their data

  1101      carried through or stored in the DTN.

  1102 

  1103    - Prevent unauthorized applications from asserting control over the

  1104      DTN infrastructure.

  1105 

  1106    - Prevent otherwise authorized applications from sending bundles at a

  1107      rate or class of service for which they lack permission.

  1108 

  1109    - Promptly discard bundles that are damaged or improperly modified in

  1110      transit.

  1111 

  1112    - Promptly detect and de-authorize compromised entities.

  1113 

  1114    Many existing authentication and access control protocols designed

  1115    for operation in low-delay, connected environments may not perform

  1116    well in DTNs.  In particular, updating access control lists and

  1117    revoking ("blacklisting") credentials may be especially difficult.

  1118    Also, approaches that require frequent access to centralized servers

  1119    to complete an authentication or authorization transaction are not

  1120    attractive.  The consequences of these difficulties include delays in

  1121    the onset of communication, delays in detecting and recovering from

  1122    system compromise, and delays in completing transactions due to

  1123    inappropriate access control or authentication settings.

  1124 

  1125    To help satisfy these security requirements in light of the

  1126    challenges, the DTN architecture adopts a standard but optionally

  1127    deployed security architecture [DTNSEC] that utilizes hop-by-hop and

  1128    end-to-end authentication and integrity mechanisms.  The purpose of

  1129    using both approaches is to be able to handle access control for data

  1130    forwarding and storage separately from application-layer data

  1131    integrity.  While the end-to-end mechanism provides authentication

  1132    for a principal such as a user (of which there may be many), the hop-

  1133    by-hop mechanism is intended to authenticate DTN nodes as legitimate

  1134    transceivers of bundles to each-other.  Note that it is conceivable

  1135    to construct a DTN in which only a subset of the nodes participate in