diff -r 000000000000 -r 2b3e5ec03512 STATUS
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/STATUS	Thu Apr 21 14:57:45 2011 +0100
@@ -0,0 +1,164 @@
+
+	     Status of the DTN2 Reference Implementation
+	     ===========================================
+
+This document describes the high-level features of version 2.4.0 of
+the DTN2 reference 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 DTN2 code is based on RFC 4838 on the
+Delay-Tolerant Networking Architecture, and the Bundle Protocol
+Specification Internet Draft version 9. The TCP convergence layer is
+based on the Delay Tolerant Networking TCP Convergence Layer Protocol
+draft version 0.
+
+A copy of these documents are included in the doc/ directory and can
+be obtained from the ietf.org web site.
+
+
+			 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 (reactive)
+- Bundle fragment reassembly
+- Custody Transfer
+- Bundle Status Reports:
+  - Received
+  - Forwarded 
+  - Delivered
+  - Deleted
+  - Custody Acceptance
+- Extension blocks
+
+
+The features that are not yet implemented include:
+
+- Bundle Status Reports:
+  - Acknowledged by Application 
+- Bundle Security blocks
+- Proactive Fragmentation
+
+
+			  Convergence Layers
+			  ------------------
+
+The following Convergence Layers have been implemented. 
+
+-- TCP Convergence Layer
+
+An internet draft (draft-dtnrg-tcp-clayer-00.txt) has been published
+describing the TCP convergence layer protocol.
+
+The TCP convergence layer offers a reliable communication channel
+between DTN nodes. All bundle communication is bidirectional. 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.
+
+-- 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 convergence layer 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. 
+
+This release includes two dynamic routing implementations: DTLSR
+(Delay-Tolerant Link State Routing) and Prophet. Additional routing
+implementations can also be integrated using an external API.
+
+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 18, 2006