DTN Research Group Robert C. Durst
INTERNET-DRAFT The MITRE Corporation
<draft-irtf-dtnrg-ipn-bundle-xfer-01.txt>
October 2003
Expires April 2004
Delay-Tolerant Networking:
An Example Interplanetary Internet Bundle Transfer
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document presents an example data transfer in a delay tolerant
network. The particular delay tolerant network is the Interplanetary
Internet, and the purpose of this document is to illustrate the key
concepts in the Delay Tolerant Network architecture [DTNRG03]. The
document describes the network and follows the progress of a bundle
as it is transferred through that network.
Durst Expires September 2003 [Page 1]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................2
Copyright Notice...................................................2
1 Introduction................................................3
2 Rules for forming tuples in the example network.............3
2.1 Region identification..................................3
2.2 Intra-region identification............................3
3 Example Network Topology at the Region Level................5
4 DTN Gateway routing.........................................6
5 Systems participating in example bundle data transfer.......7
6 End-to-end Transfer.........................................9
6.1 Step 0: Application instance registration.............9
6.2 Step 1: Bundle creation and first-hop transmission....9
6.3 Step 2: Bundle processing at first-hop destination...10
6.4 Step 3: Bundle processing at gateway to destination IPN
Region................................................11
6.5 Step 4: Bundle processing at destination.............11
7 Error Conditions at the Bundle Layer.......................11
8 Normative References.......................................14
9 Security Considerations....................................14
10 Author's Address...........................................15
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Acknowledgments
John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe
Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen
Farrell and Craig Partridge all contributed useful thoughts and
criticisms to the DTN Architecture. 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.
Durst Expires September 2003 [Page 2]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
1 Introduction
This document is a companion to the Delay Tolerant Networking
architecture definition [DTNRG03]. The article "Delay-Tolerant
Networking: An Approach to Interplanetary Internet" [IEEE] considers
the application of the DTN approach with one based on adaptations of
existing Internet infrastructure.
We provide the following example of an end-to-end bundle transfer
across a Delay-Tolerant Network. This particular example is based on
the Interplanetary Internet: A host on Earth sends a bundle to a
destination on Mars. Figure 1 illustrates the network that is the
subject of this example û the Interplanetary Internet in this example
has five distinct regions interconnected by four DTN Gateways. This
example highlights the actions taken by the bundle layer and its
interactions with applications and underlying transport protocols.
2 Rules for forming tuples in the example network
Per the DTN architecture [DTNRG03], application instance ID tuples
consist of two parts: a region ID, and a Universal Resource
Identifier (URI) [RFC3305]. Each DTN region has a URI space shared by
all DTN nodes within that region. Each DTN region has a unique
identifier that is known (or discernable) by all regions in the DTN.
This particular delay-tolerant network is the Interplanetary
Internet. In this section we will establish the naming rules that
permit interoperation within this network. Note that this is only an
example, and that not all DTNs must use this particular region
identifier space.
2.1 Region identification
All regions in *this* DTN (the example Interplanetary Internet) must
share a region identifier space. The DTN region *name* space is
hierarchical, dot-separated text, structured such that left to right
is leaf-to-root in the tree. The *identifier* space may be exactly
this name space, or a DTN may define a translation from the name to a
particular identifier, in the same way that names in the DNS may be
translated to Internet addresses. For this example, we will use the
*names* as the *identifiers*.
The DTN region name space is shown in Figure 2.
2.2 Intra-region identification
For simplicity in this example, we will assume that all regions use a
well-known TCP port in combination with DNS host names as the portion
of their entity identifier that locates the application providing the
bundle service. The bundle layer application resides above this
well-known port (which we arbitrarily choose to be TCP port 6769, a
currently unassigned port in the registered port space). The
Durst Expires September 2003 [Page 3]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
interplanetary backbone region, labeled "ipn" in Figure 2, will
certainly NOT use TCP as its underlying transport protocol. For the
sake of simplicity in this example, let us assume that the protocol
used within the interplanetary backbone region uses the same entity
identifier space (IP addresses and port numbers) that the remainder
of the network uses.
+-------------------------+
| Earth's Internet |
| DTN Region: earth.sol |
| +---+ |
+-----------/ /|--------+
+---+ |
|G/W| +
+----------| 1 |/---------+
| +---+ |
| The "Backbone" |
| DTN Region: ipn.sol |
+---+ +---+ +---+
/ /|------/ /|-------/ /|
+---+ | +---+ | +---+ |
|G/W| + |G/W| + |G/W| +
+----------------| 3 |/ +---| 4 |/-----+ | 2 |/-------------------+
| +---+ | +---+ | +---+ |
| Venus's Internet | | Jupiter's | | Mars's Internet |
| DTN Region | | Internet | | DTN region: |
| venus.sol | | DTN Region | | mars.sol |
+------------------+ | jupiter.sol | +----------------------+
+--------------+
Figure 1. An Interplanetary Internet of Five IPN Regions
Root .
|
The Interplanetary Internet int
|
The Solar System sol
+-----+-----+-+---+-----+
| | | | |
Region jupiter mars earth venus ipn
Figure 2. An Example Interplanetary Internet Region Name Space
The mechanism used to demultiplex bundles received by a bundle node
is entity-specific, but must be represented in the region-specific
URI. For the sake of simplicity, we will assume that this is a
Durst Expires September 2003 [Page 4]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
process ID that has been incorporated into the URI. [Note: this is
a simple, but quite limiting decision, as it has implications on
process reinstantiation and process portability/migration from one
entity to the next. We choose it only for simplicity.]
3 Example Network Topology at the Region Level
It is important to have some understanding of the routing that is
required at the DTN Gateways, so it is important to understand the
topology of the network at the region level. Unlike typical
terrestrial communications, the Interplanetary Internet's (IPN's)
*long-haul* communication links are directional, mobile, and highly
scheduled. This is important, because directionality combined with
mobility means that a transmitter and receiver must track each other
in order to establish and maintain a communication link. In the IPN,
much of the mobility is due to orbital mechanics and is therefore
relatively predictable. However, this means that nodes that we would
normally consider to be fixed, such as antennas on the surface of the
Earth, are actually highly mobile as a result of the Earth's rotation
and its revolution around the Sun. (In this example, we confine
ourselves to our local solar system, and do not consider the motion
of our sun relative to celestial bodies outside our solar system.)
We can describe the predictable aspects of node mobility with an
ephemeris, a table of the positions of celestial bodies at specified
intervals of time. Both a directional sender and receiver must each
know the other's position in order to establish a link between the
pair.
In addition, these communication resources are highly scheduled. It
is not sufficient for a receiver to point at a prospective target and
just wait û for example, a terrestrial node will typically have to
point at several targets sequentially, and an interplanetary node
will typically not have enough power to just wait for incoming
messages. Rather, a schedule of communication *opportunities* must
be calculated and then refined with planned communication *contacts*.
A communication opportunity establishes that the endpoints could
establish a link if they were pointing at each other at the proper
times. We refer to a planned communication contact as an agreement
(although not irrevocable) between the two parties to establish
contact and communicate for a defined period of time.
The protocols for establishing the schedule of communication contacts
between all pairs of possible communicants will evolve -- from
something primarily done manually to something more automated as the
real Interplanetary Internet grows.
The scheduled nature of connectivity in the Interplanetary Internet,
particularly across the deep-space links, means that at the time of a
bundle's arrival at a DTN Gateway, some or all of the possible
outbound routes may be "down." The gateway must store the bundle
Durst Expires September 2003 [Page 5]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
until the appropriate link is available and then transmit the bundle
over that link. One of the fundamental differences between the
Interplanetary Internet and the terrestrial Internet is this inherent
use of store-and-forward mechanisms in routing bundles. With that
in mind, let us consider the routing decisions made at some of the
DTN Gateways in Figure 3.
4 DTN Gateway routing
Bundle routing at a DTN gateway will typically have to deal with a
mix of continuously available links and intermittently available
links. Routing across a continuously available link is a relatively
straightforward activity. Routing in the presence of intermittently
available links can be significantly more complex, as the gateway
will need to decide not only the next hop destination but also the
time at which to send the bundle. Conditions elsewhere in the
network may make it more desirable to send a bundle to a next-hop
destination that is not yet accessible, even when an alternative
route is currently available.
The intermittent links in this example provide connectivity among the
DTN Gateways that are part of the ipn.sol.int region. The contacts
among gateways in this region are scheduled. As is currently the
case, Gateway 1 (the Earth gateway) has scheduled contacts with each
of the other DTN gateways in the ipn.sol.int region (the "backbone"),
but there is no direct contact among any of the DTN gateways on
Venus, Jupiter, or Mars. Recall that this communication uses
directional antennas, so it is generally not possible to communicate
with two different entities at once unless they are in the same field
of view. Power availability on the remote planets is an issue, so
transmitters and receivers are turned on only during a contact.
Further, the speed of light delays are nontrivial, skewing transmit
and receive times between remote gateways. Table 1 presents a
schedule of contacts that is used in the example. All times are
referenced to Gateway 1, and that nodes remote to Gateway 1 (that is,
Gateways 2, 3, and 4) are not scheduled to turn on their transmitters
until they receive a transmission from Gateway 1. The information in
this table is completely hypothetical, and the speed of light delays
are plausible, but completely back-of-the-envelope. One-way light
times between Gateway 1 and Gateways 3, 4, and 2 are 4 minutes, 32
minutes, and 10 minutes, respectively. Those details are perhaps
interesting but not the point of the example.
Note that any bundles sent by GW3 after 1156 GW1 time cannot be
acknowledged before the next contact, because the bundle will arrive
at GW1 after the end of GW1's transmission time (1200). Since the
next contact between GW1 and GW3 might be the subsequent Monday, the
acknowledgement delay might be VERY long. Bundles sent by GW4 after
1358 cannot be acknowledged during the current contact, because they
will not be received before GW1's transmission time ends at 1430.
Durst Expires September 2003 [Page 6]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
Similarly, bundles sent by GW2 after 1150 cannot be acknowledged
during the contact.
Table 1. Contact schedule for Gateway 1.
+---------+------------+-----------+-------------+------------------+
| Day |Destination | GW1 Send | GW1 Receive | Destination Send |
| | | Time | Time | /Receive Time |
+---------+------------+-----------+-------------+------------------+
| Monday | GW3 | 0900-1200 | 0908-1208 | 0904-1204 |
+---------+------------+-----------+-------------+------------------+
| Tuesday | GW4 | 1300-1430 | 1404-1534 | 1332-1502 |
+---------+------------+-----------+-------------+------------------+
|Wednesday| GW2 | 1000-1200 | 1020-1220 | 1010-1210 |
+---------+------------+-----------+-------------+------------------+
DTN Gateways 2, 3, and 4 have entries in their contact schedules for
the contacts with Gateway 1.
5 Systems participating in example bundle data transfer
Figure 3 is a revision of Figure 1 that highlights those portions of
the Interplanetary Internet that participate directly in the bundle
transfer example. Also shown in Figure 3 are the source and
destination for the transfer and the Domain Name System equivalents
in the terrestrial Internet (DNS 1), in the IPN "Backbone" (DNS 2),
and in the Mars Internet (DNS 3). This figure will serve as the
basis for the bundle data transfer example.
Table 2 provides the full host names of each of the primary elements
in Figure 3. For this example, we hypothesize a URI scheme named
"tcp" that is used to identify the Internet namespace, and a scheme
named "dsn" that is used to identify a Deep Space Network namespace.
Recall that in this example all bundle layer applications reside on
TCP port 6769. The portion of the entity identifier used to
demultiplex to the application using the bundle service has been
omitted until the applications are discussed in section 6.1. Host
name tuples are in the form {region, administrative part}.
Durst Expires September 2003 [Page 7]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
+---+
/ /|
+------------------------+---+ |
+---+ Earth's Internet |DNS| +
/ /|IPN Region: earth.sol| 1 |/
+---+ | +---+ +---+
|SRC| +---------/ /|--------+
| |/ +---+ |
+---+ |G/W| +
+----------| 1 |/---------+
| +---+ |
| The "Backbone" |
| IPN Region: ipn.sol |
+---+ +---+ +---+
/ /|-------------------/ /| / /|
+---+ | +---+ | +---+ |
|DNS| + |G/W| + |DST| +
| 2 |/ | 2 |/-------------| |/+
+---+ +---+ +---+ |
| Mars's Internet |
+---+ IPN region: |
/ /| mars.sol |
+---+ |---------------------+
|DNS| +
| 3 |/
+---+
Figure 3. Interplanetary Internet showing principal systems.
Table 2. Host name tuples (entity ID demultiplexing info omitted).
+------------+------------------+---------------------------+
| Host | IPN Regions | Host name tuples |
+------------+------------------+---------------------------+
| SRC | earth.sol |{earth.sol, tcp://src.jpl. |
| | | nasa.gov:6769} |
+------------+------------------+---------------------------+
| IPN G/W1 | earth.sol |{earth.sol, tcp://ipngw1. |
| | | jpl.nasa.gov:6769} |
| | ipn.sol |{ipn.sol, dsn://ipngw1. |
| | | jpl.nasa.gov:6769 |
+------------+------------------+---------------------------+
| IPN G/W2 | ipn.sol |{ipn.sol, dsn://ipngw2. |
| | | nasa.mars.org:6769} |
| | mars.sol |{mars.sol, tcp://ipngw2. |
| | | nasa.mars.org:6769} |
+------------+------------------+---------------------------+
| DST | mars.sol |{mars.sol, tcp://dst.jpl. |
| | | nasa.gov:6769} |
+------------+------------------+---------------------------+
Durst Expires September 2003 [Page 8]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
6 End-to-end Transfer
6.1 Step 0: Application instance registration
Before the beginning of this example, all of the bundle nodes in the
network exchange their signed key material and credentials with next
hop neighbors. These materials are cached for subsequent use. The
applications at the source and destination register with their local
bundle layers, providing similar key material and credentials to the
bundle layer, and receiving in return their application instance
identifiers. The destination has registered its IPN-standardized
well-known demultiplexing id of "8," which becomes part of the entity
ID used to refer to this particular application. The source has
registered a demultiplexing identifier "0x1763421A" (a hexadecimal
number) that (arbitrarily) corresponds to its process ID.
6.2 Step 1: Bundle creation and first-hop transmission
The application on the source host in Figure 3 has data that it
wishes to send to the destination on Mars. The exact content of this
data is opaque to the bundle transfer, but assume that it contains
all of the information necessary to accomplish some desired function.
That is, assume that application-specific instruction for storage,
handling, error processing, and disposal accompanies whatever data
object is to be operated upon. The application invokes the bundle
layer, supplying it the information shown in Table 3.
The bundle agent verifies the signature, then creates a bundle and
stores it in persistent storage (on disk or other non-volatile
memory). There are some fields of the bundle header that the bundle
agent must supply: the Sending Timestamp, the Source Host name tuple,
the Custodian name tuple, and the time to live. (The application may
state a time after which the data are obsolete, but the actual time-
to-live field in the bundle header uses the application's data in
combination with network restrictions on time-to-live to initialize
this field properly.) The bundle layer consults routing tables and
notes that its next-hop destination to reach the mars.ipn.sol region
within the earth.ipn.sol region is tcp://ipngw1.jpl.nasa.gov:6769.
(Since a host may reside in multiple IPN Regions, the source host
name tuple is a function of the outbound route selected. The bundle
layer uses this information to complete the Source Host and Custodian
name tuples prior to transmission.) Having verified the
application's signature, it incorporates this into the authentication
information of the bundle header and appends its own credentials. It
further notes that it has a continuous connection to that gateway,
and transmits the bundle to it, retaining a copy for custodial
storage. The bundle layer starts a retransmission timer for the
bundle and awaits a custodial transfer acknowledgment.
Durst Expires September 2003 [Page 9]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
Table 3. Information supplied by source application.
+-------------+---------------------+------------------------------+
| Item | Value | Description |
+-------------+---------------------+------------------------------+
| Destination | {mars.sol, | IPN Name tuple of the |
| DTN | tcp://dst.jpl.nasa | destination. Note that appl.|
| tuple | .gov:6769/8} | demuxing ID 8 is supplied. |
+-------------+---------------------+------------------------------+
| Source | 0x1763421A | Value used to identify the |
| application | | appropriate instance of the |
| demultiplex | | source application for |
| identifier | | response processing (becomes |
| | | part of the source tuple) |
+-------------+---------------------+------------------------------+
| Class of | Custodial delivery, | The services requested from |
| service | normal priority, | the bundle layer. |
| | data obsolete in 36 | |
| | hours. | |
+-------------+---------------------+------------------------------+
| Signature | Opaque | Digital signature of the |
| | | app.-supplied information |
+-------------+---------------------+------------------------------+
| User data | N/A | |
+-------------+---------------------+------------------------------+
6.3 Step 2: Bundle processing at first-hop destination
When the IPN Gateway {ipngw1.jpl.nasa.gov, earth.sol} receives the
bundle via TCP, it checks the signature of the previous router and
determines that the bundle has been forwarded by a legitimate source.
Further, since this is the security boundary for the Interplanetary
Internet, it verifies the signature of the sending application,
requesting a copy of the application's public key from a secure
distribution service if it does not already have one cached. Having
verified that the application is authorized to access the deep-space
portion of the Interplanetary Internet, the bundle layer replaces the
signature block of the bundle layer entity with its own, leaving the
application's signature block intact. It stores the received bundle
on persistent storage (disk). The bundle layer consults the contact
schedule and determines that the appropriate next-hop destination is
in the "ipn.sol" IPN Region: {ipn.sol,
dsn://ipngw2.nasa.mars.org:6769}, and that the next contact is the
following Wednesday. The bundle layer manifests the bundle on the
contact for that Wednesday.
In considering alternative contacts for the bundle, the dispatcher
checks the time-to-live in the bundle, which was 36 hours from the
time of initial submission to the bundle agent at the source, to
Durst Expires September 2003 [Page 10]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
ensure that the route selected is consistent with the time-to-live
requirements of the bundle. The bundle transport functionality of
the bundle agent in ipngw1 accepts custody of the bundle, updates
this information in the bundle header, and informs the source that
has done so. The sources bundle agent deletes its custodial copy of
the bundle. When the time arrives for contact with the
ipngw2.nasa.mars.org DTN gateway to be established, the convergence
layer establishes that contact via a protocol suited for reliable
transfer across very long distances, referred to here as the Long
Haul Transport Protocol (LTP). When informed that the contact is
available, the bundle layer posts its bundles to the convergence
layer for transmission via LTP.
6.4 Step 3: Bundle processing at gateway to destination IPN Region
The Mars gateway, {mars.sol, dsn://ipngw2.nasa.mars.org:6769},
receives the bundle from the Earth gateway via LTP. It verifies the
signature block of the Earth gateway, then replaces that signature
block with its own. It stores the bundle in persistent storage and
accepts custody of the bundle, signaling back to the Earth gateway
that it has done so. When the notification of acceptance reaches the
Earth gateway, ipngw1 deletes its custodial copy. The Mars gateway
consults its routing tables to find an outbound contact to forward
the bundle over. It determines that the appropriate next hop is the
destination itself, that the proper transport protocol is TCP, and
that the destination is accessible immediately. The gateway verifies
that the time-to-live has not expired, and forwards the bundle to the
destination.
6.5 Step 4: Bundle processing at destination
The bundle layer at the destination entity receives the bundle via
TCP, verifies the signature block of the IPN G/W2, stores it on its
own persistent storage, and accepts custody of the bundle from IPN
G/W2. The bundle agent "awakens" the destination application process
identified by the Destination Application demultiplexing portion of
the entity ID. This may involve creating a new instance of a server
from a daemon process, signaling an idle running process, or
reinstantiating a process that has been suspended with its state
stored on persistent storage. The bundle agent deletes the copy of
the bundle from persistent storage when the application has received
it. The destination application may generate an application-layer
acknowledgment in a new bundle and send it to the source.
7 Error Conditions at the Bundle Layer
This section describes the error conditions that may arise at the
bundle layer during bundle creation and transport. When these errors
occur within the sender's DTN region, it may be possible to conduct a
near-real-time dialog to correct them before the bundle is forwarded.
We say 'may be possible' because even if two nodes are in the same
Durst Expires September 2003 [Page 11]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
IPN domain, they may not have real-time connectivity. An example of
such a situation would be if a lander were on the opposite side of
the planet from its DTN gateway, and used bundles to communicate with
the gateway through a low altitude orbiter, with the orbiter itself
serving as a bundle agent.
Table 4: Error conditions at the bundle layer.
+-------+---------------------------+------------------------------+
| Error | Description | Places where Error can Occur |
+-------+---------------------------+------------------------------+
| 1* | Unknown destination region| Source Bundle Node |
+-------+---------------------------+------------------------------+
| 2* | Invalid Source App. | Source Bundle Node |
+-------+---------------------------+------------------------------+
| 3* | Bundle Parameter Syntax | Source Bundle Node |
| | Error | |
+-------+---------------------------+------------------------------+
| 4* | Bundle Parameter Semantic | Source Bundle Node |
| | Error | |
+-------+---------------------------+------------------------------+
| 5 | Insufficient buffer space | Any bundle node |
+-------+---------------------------+------------------------------+
| 6* | Time exceeded | Any bundle node other than |
| | | the source |
+-------+---------------------------+------------------------------+
| 7* | Source Entity Access | Any bundle node other than |
| | Denied | the source |
+-------+---------------------------+------------------------------+
| 8* | Invalid Entity ID in | IPN gateway serving |
| | Destination Name | destination DTN region |
+-------+---------------------------+------------------------------+
| 9* | Invalid Destination App. | Destination |
+-------+---------------------------+------------------------------+
| 10* | End-to-end Access Denied | Destination |
+-------+---------------------------+------------------------------+
The errors that can occur at the bundle layer are shown in Table 4.
Error numbers marked with an asterisk (*) are reported back to the
sending application (or to the location specified in the reply-to
field of the bundle header, if it differs from the sending
application).
* Unknown Destination Region: This error occurs when the source
bundle node is directed to create a bundle destined for a DTN
Region that is not recognized. Note that only the DTN Region part
of the destination name has to be interpretable outside the
destination's DTN Region. In particular, the entity identifier of
the destination name need not be interpretable to the source
(assuming the source and destination are in different DTN
Regions), so it cannot necessarily be checked when the bundle is
created. (It is possible in the case of a mis-configured DTN
Durst Expires September 2003 [Page 12]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
router that this error might occur at a location other than the
Source Bundle Node. However, this is an error condition within
the bundle router that should be corrected and the bundle routed,
rather than an error that should be reported to the sending
application.)
* Invalid Source Application: If the source authentication
information fails, the source bundle layer responds with an
Invalid Source Application error.
* Bundle Parameter Syntax Error: The source bundle layer may check
the syntax of some of the bundle-creation parameters (i.e. it may
ensure that the end-to-end and DTN access security certificates
are well-formed, etc.) If a parameter is found to be
syntactically incorrect or obviously and definitely erroneous, the
bundle layer will report a Bundle Parameter Syntax Error back to
the source that includes, at a minimum, the parameter that caused
the error.
* Bundle Parameter Semantic Error: If the source bundle layer can
identify a particular bundle creation parameter as being well-
formed but unserviceable, it will report a Bundle Parameter
Semantic Error to the source application that includes, at a
minimum, the parameter that caused the error.
* Insufficient Buffer Space: If a bundle node does not have
sufficient buffer space to accept a bundle, it drops the bundle
and generates an Insufficient Buffer Space error. Note that a
bundle node may choose to drop lower priority bundles in order to
make room for higher priority ones. This error is not propagated
back to the source.
* Time Exceeded: If the time-to-live field (either the source-
provided TTL or the internal bundle TTL) expires, the source is
notified with a Time Exceeded message. These errors are
propagated to the source application.
* Source Entity Access Denied: This error indicates that the source
entity does not have access to a needed resource at a DTN node.
The source might not be authorized to use the node at all, or it
might not have authorization to use a particular interface
required by the bundle. Source Entity Access Denied errors
indicate that the source is not *authorized* to use a particular
resource; other errors (e.g. Insufficient Buffer Space) indicate
that a particular resource is *unavailable* to a bundle. For
example, an entity on the surface of a planet might be authorized
to communicate, using the bundle protocol, with another entity on
the other side of the planet via a low-altitude orbiter that is
also an IPN gateway. The sender might not, however, be authorized
to send bundles across interplanetary space. In this case bundles
sent to the orbiter destined for the other side of the planet
would not cause errors, while any bundles with off-planet
destination addresses would. Source Entity Access Denied errors
are propagated back to the source application.
* Invalid Entity ID in Destination Name: Once a bundle has reached
its destination DTN Region, the Entity ID part of the destination
name can be parsed. If the Entity ID of the destination name is
Durst Expires September 2003 [Page 13]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
not valid, the source is notified with an Invalid Administrative
Destination Name error message.
* Invalid Destination Application: If the destination bundle layer
cannot instantiate the destination application (based on the
demultiplexing information the region-specific entity ID of the
bundle), it notifies the source application with an Invalid
Destination Application error message.
* End-to-End Access Denied: If the bundle destination does not
accept the bundle due to an authentication or access-control
error, the source is notified with an End-to-End Access Denied
Message.
8 Normative References
[DTNRG03] Cerf et al, "Delay-Tolerant Network Architecture," (draft-
irtf-dtnrg-arch-03.txt), October 2003. Available from
http://www.dtnrg.org.
9 Informative References
[IEEE] Burleigh et al, "Delay-Tolerant Networking: An Approach to
Interplanetary Internet," IEEE Communications Magazine, June 2003, pp
128-136. Available from http://www.dtnrg.org.
10 Security Considerations
Security is an integral concern of the Delay Tolerant Network
Architecture. The infrastructure protection elements of the Delay
Tolerant Network Architecture are still evolving, and this example
tracks the state of the security architecture in [DTNRG03].
11 Acknowledgments
The author gratefully acknowledges the contributions of the following
individuals, who either helped to walk through this example on
various whiteboards or assisted in making the documentation of it
more readable: Scott Burleigh, Jet Propulsion Laboratory; Vint Cerf,
Worldcom; Keith Scott, MITRE; Kevin Fall, Intel Corporation; Howard
Weiss, SPARTA, Inc.; and Leigh Torgerson and Adrian Hooke, both of
the Jet Propulsion Laboratory.
Durst Expires September 2003 [Page 14]
Internet Draft draft-irtf-dtnrg-ipn-bundle-xfer-00.txt March 2003
12 Author's Address
Robert C. Durst
The MITRE Corporation
7515 Colshire Drive M/S H300
McLean, VA 22102
Telephone +1 (703) 883-7535
FAX +1 (703) 883-7142
Email durst@mitre.org
Please refer comments to dtn-interest@mailman.dtnrg.org
Durst Expires September 2003 [Page 15]
