DTN2 Draft-Implementation Neighbor Discovery
Ohio University, with the support of Verizon and NASA, is currently rewriting / developing DTN2's neighbor discovery mechanisms to conform to Jim Wyllie's draft on DTN neighbor discovery. Eventually, this code will be rolled into the main DTN2 distribution after sufficient cleaning and testing.
Code Status
The code is currently in beta: it needs a code cleaning and more testing to move beyond that status. The configuration options also need to be changed to make more sense.
Currently, the domain-independent portion of the system is feature-complete, and an experimental IP handler (similar to the current neighbor discovery implementation) is currently functioning.
The code is tested to work on Linux. This will be expanded to include all DTN2-compatible versions in the future.
Download
Latest Stable Release
The current release is version 0.1.1, released December, 2007. Bug reports, issues, and feature requests should go to jw280601 at ohiou dot edu. Instructions for installation and usage can be found below.
Source: dtn2_discovery-0.1.1.tar.bz2 -- Contains a copy of the DTN2 implementation, with our implementation changes.
Source Repository
The code is maintained in a git repository. To get a clone of the public read-only repository, enter in the following command:
- $ git clone git://korgano.eecs.ohiou.edu/jwyllie/DTN2.git
The 'master' branch is the CVS version of DTN2 off of which the discovery release is synchronized. The 'autodiscovery' branch (what is checked out without additional arguments to the above command) is the current HEAD of all autodiscovery work.
Installation
As the neighbor discovery modifications are simply patches to the existing DTN2 implementation, installation is identical to the compliation and installation instructions found with DTN2. Usage of DTN2 can be conducted normally at that point.
Using the Neighbor Discovery features
By default, the "discovery" registration (analogous to the "ping" registration) is initialized and will accept properly-formatted Discovery bundles. Therefore, with little coding, a daemon could be created which uses the DTN2 API to send manually-formatted Discovery bundles to other nodes. The API currently has no features for creating discovery bundles implicitly; it may be implemented in the future.
A domain-specific handler and agent is currently implemented. This agent sends Discovery bundles over multicast UDP to other agents. It can be configured to use UDP unicast, if desired. These bundles include a convergence layer address and port number so a convergence layer link can be set up if one does not exist.
Configuration of the IP Neighbor Discovery agent
The configuration file in daemon/dtn.conf has been updated; it currently includes verbose commenting on setting up this system of neighbor discovery. It uses nearly identical syntax as the current neighbor discovery system; exceptions are noted in the configuration file.
Example configuration
System Configuration
As most computers have no special facilities for multicast, be sure that your multicast packets are going out the proper interface. To add a route which will send all multicast out a certain interface, enter the following (as root) on all advertising systems:
# route add -net 224.0.0.0 netmask 240.0.0.0 dev NETWORK_DEVICE
where NETWORK_DEVICE is eth device out of which you would like to send multicast packets.
dtn.conf Configuration
To advertise over the default UDP multicast port, you first must initialize the UDP listener for bundles:
interface add udp0 udp
To create on-wire bundles, we have to create a "dummy" link. This link won't actually be used for anything; it will simply be used internally to format bundles over a UDP link.
link add discovery_link 239.192.0.1 ALWAYSON udp
Now, to create the agent that listens for Discovery bundles (but not advertise), you have to start the listener. This listener will create a listener on the standard IP address and port (239.192.0.1:36912; port chosen randomly) for incoming Discovery bundles. This can be configured to listen on any address and port; see daemon/dtn.conf for more details.
discovery add ip_discovery ip
To send information to any potential listeners, you have to start the agent. This agent will use the listener above (ip_discovery) and the dummy link created earlier (discovery_link), with a beacon interval of 20 seconds. It will advertise the 10.1.1.7 IP address as the link over which it can be contacted.
Other things can be specified here, such as multicast TTL, and the convergence-layer port to listen on. Again, see daemon/dtn.conf for more details.
discovery announce ip ip_discovery udp link=discovery_link interval=20 cl_addr=10.1.1.7
With these commands, an agent sending beacons should be created.
Potential Pitfalls
The beacons will be advertised starting at the current time, and extending for three minutes. The timestamps are encoded by the sender. As per the DTN specification for bundle agents, this requires global time synchronization.
If you find that your beacons aren't leaving, it probably means that multicast is either stopped by your router or going out the wrong path. Please ensure that your multicast packets are traveling on the proper interface and are reaching the destination.
Comments and Questions
If you're still not sure what to do, or have questions about the implementation, please contact Jim Wyllie at jw280601 \at/ ohiou \dot/ edu.