GRC Always ON DTN Network
NASA Glenn Research Center and Ohio University have created mirrored implementations of virtualized DTN networks. Glenn Research Center's DTN network is a DTN-2 network. Ohio University has implemented an ION network. [http://www.dtnrg.org/wiki/DtnBone/ou-dtnbone (Ohio University ION DTN Network)]
The purpose of these networks is to get some "Disconnection" into the DTNbone as well as provide a place to start implementing network management.
These DTN networks have to following characteristics:
- Stable (names and topology is constant)
- Always ON (Always up and running 24/7)
- Multi-hop
- Disconnection (links will be UP for some period of time and DOWN for others.)
- Multi-Path (Bundles can reach a destination via multiple routes)
Regarding the Glenn DTN-2 Network
A dynamic, interactive network diagram showing the time-varying link states is now available. [http://grc.nasa.dtnbone.net/ (View the Network Diagram)]
Routing and Links
The routing is performed using DTN Link State Routing (DTLSR). This virtual network is a flat network. DTLSR can use bonjour to perform node discover. However, in a flat network, all machines can see each other. However, we want this to be a multi-hop network, not a mesh. Therefore, bonjour is not enabled and each node has to have static links to it's adjacent nodes in the multi-hop topology. Such a configuration enables all nodes to eventually discover each other using DTLSR. It takes a while for each node in the entire network to discover each other as there is disconnection.
The links are dynamically controlled with a cron job. [http://roland.grc.nasa.gov/~ivancic/DTN/grc-dtnbone-cronfile.txt (View the cronfile)]
The links currently do not have bit error or packet loss associated with them. They do have time delays. The multi-path subnetwork of india, juliet, kilo, lima, and mike has a total time delay on the scale of a lunar round trip time delay (when fully connected - remember, there is disconnection). One can think of juliet, kilo and lima as lunar relay satellites.
To get to any DTN bundle agent, you will need to send to "bravo" the gateway between the virtualized network and the DTNbone machines on the Internet.
Network Management
Network management is currently via a back channel (always on and not using DTN). This pull the MIBs using local SNMP and [http://www.json.org/ JSON] code. See [http://roland.grc.nasa.gov/~ivancic/DTN/Network_Management_Jim_McKim-2010-01-08.pdf Jim McKim's DTN Network Management Presentation of January 2010]
One can get to the network management scripts by pointing your browser to the following URL:
http://grc.nasa.dtnbone.net/render_dtn2.pl
This will present an entry page with links to status pages for the individual nodes. The node status pages present pretty much all the information that can be extracted from each DTN2 instance. They refresh every five minutes.
We greatly appreciate any feedback on the network management. In order to trace a bundle through the network, we suspect more will be required such as inclusion of log file or pulling and filtering of log files for particular information. Any requests for "types" of information and any "suggestions" for scripts would be greatly appreciated.
Contacts and Correspondence
It would probably me most useful to provide such feedback to the dtn-interest list so others can see and comment or provide additional input and suggestions.
For comments that would not be useful for the entire group to see, the following are suggested.
MailTo(james DOT h DOT mckim AT nasa DOT gov, Jim Mckim) - Network Management
MailTo(dennis DOT c DOT iannicca AT nasa DOT gov, Dennis Iannicca) - Network Topology, Link Configurations and Virtualization
MailTo(william DOT d DOT ivancic AT nasa DOT gov, Will Ivancic) - General comments and suggestions. If I don't know, I probably know who to talk to. I'll find the appropriate person and get an answer.
MailTo(joseph DOT a DOT ishac AT nasa DOT gov, Joseph Ishac) - General comments and suggestions.