Status of the DTN2 Reference Implementation
	     ===========================================

This document describes the general features of this implementation
and summarizes the relationship between the implementation and the
various Internet Drafts that describe Delay Tolerant Networking, the
Bundle Protocol, and other related protocols.

The current version of the code is based on the Bundle Protocol
Specification Internet Draft version 4, and the Delay Tolerant
Networking Architecture Internet Draft version 4, both released in
December of 2005.

A copy of these documents can be obtained from:
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-spec-04.txt
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-04.txt


			 The Bundle Protocol
			 -------------------

The features described in the bundle protocol specification that are
implemented include the following:

- The Basic Bundle Protocol
- Self Describing Numeric Values
- Endpoint Identifiers (more information below)
- Bundle expirations (based on timers)
- Registrations (with expiration timers)
- Persistent storage of bundles
- Bundle fragmentation (proactive and reactive)
- Bundle fragment reassembly
- Bundle Status Reports:
  - Received
  - Forwarded 
  - Delivered
  - Deleted

The features that are not yet implemented include:

- Custody Transfer
- Bundle Status Reports:
  - Acknowledged by Application 
  - Custody Acceptance

Unfortunately, this particular document went through some late changes
after the bulk of this implementation was completed, so there are some
minor discrepancies between the specification and qthe code. This
shortcoming will be addressed in the next release.


			  Convergence Layers
			  ------------------

The following Convergence Layers have been implemented. As of yet
there are no Internet Drafts or other specification documents that
describe these protocols. 

-- TCP Convergence Layer

The TCP convergence layer offers a reliable communication channel
between DTN nodes. All bundle communication is unidirectional, thus
two neighboring nodes will need to maintain two TCP connections, one
in each direction) to exchange bundle data.

The protocol returns an acknowledgement message when part or all of
the bundle is received. These acknowledgements allowing the sender
side to determine whether or not the bundle can be removed from the
data store. Also, the partial acknowledgements are used to implement
reactive fragmentation.

The protocol has (newly added) support for pipelining bundles, that
is, having more than one bundle being sent over the wire at a given
time. This support aims to address problems on long-delay links.

The protocol also has support for connection by the receiver side.
This is intended for situations where one of a pair of DTN nodes is
sitting behind a firewall or NAT box such that the other side cannot
initiate a connection to the node.

-- UDP Convergence Layer

The UDP convergence layer offers a simple, unreliable channel. A
single bundle is sent in each UDP datagram, thus only bundles that are
smaller than the 64KB maximum datagram size can be sent. It is assumed
that configuration will be put in place to proactively fragment large
bundles before sending them over this type of link.

-- Ethernet Convergence Layer

This convergence layer sends bundles over raw ethernet frames, using
an invented ethernet type code (0xd710). As with the UDP CL, there is
a maximum size of bundles that can be sent over this type of link,
in this case 1518 bytes.

This convergence layer also includes support for neighbor discovery
through the use of periodic beacon packets.

** Note -- this support is currently disabled for lack of testing. It
   is intended to be re-enabled in a future release.
   

			 Link / Contact Types
			 --------------------

As described by the DTN architecture document, there are four general
types of links:

-- Always On

These links are opened immediatly on configuration, and underlying
transport connections (if any) are maintained open whenever possible.

-- On Demand

These links are opened when there is a bundle (or bundles) that the
router determines should be sent over the link. There is a
configurable idle timer that closes the link after a period of
inactivity.

-- Opportunistic

These links are only opened in response to some external event, such
as detection of a nearby node. Currently, there is only limited
support for neighbor discovery.

-- Scheduled

No support for scheduled links is yet implemented.


			       Routing
			       -------

The implementation offers an interface by which new routing algorithms
and modules can be easily added to the system. To date, however, the
only fully implemented algorithm is a simple static router that
requires manual configuration of routes. 

We intend for this to be an area of future development, with more
routing frameworks added in upcoming release(s).


			 Endpoint Identifiers
			 --------------------

This implementation contains a rich framework for naming based on URI
schemes. The following schemes are supported:

-- DTN scheme

We currently implement a (unspecified) scheme of "dtn". This scheme
offers support for internet hostname style node specifications, along
with URI path style demultiplexers, as well as simple pattern matching
for route entries.

An example DTN uri is dtn://thing1.dtnrg.org.dtn/mail

-- String scheme

A simple scheme used for testing allows any ASCII string to be encoded
in a URI. An example is str:my_name_is_mike

-- Ethernet scheme

This scheme encodes ethernet addresses in a URI format. An example
ethernet scheme URI is eth://01:23:45:ab:cd:ef


======================================================================

Last updated: December 16, 2005