This post is part of a series called "Route Around ISPs - Altnet". Below is a list of previous posts.
Delay Tolerant Networking
In the sneakernet thread, k00b pointed out that TCP may not be the right protocol to use for some of these transport methods. I agreed, but said I wanted to work through the various transport methods before thinking about interoperability between them. In the dronenet thread, I was pointed in the right direction; delay tolerant networking. As it turns out, the guys at NASA also thought that TCP was not the right protocol for giving commands or retrieving data like pictures from their satellites and rovers. The moon might block a connection from one relay to another, a relay might be on the other side of the planet from the moon, and so on and so forth. So they implemented their iteration of DTNs called ION.
The idea behind DTNs, not just ION, is that every relay stores the packets being transmitted until the next relay confirms delivery at which point it is safe to clear the data on that relay. It uses what was described as "4th dimensional networking". The 4th dimension being time. It has its own set of protocols and has a concept of "convergence layers". That is to say, it has a method for routing packets over TCP networks, but when packets need routed beyond a TCP compatible network, the packets are more than happy to return to LTP (a DTN native protocol).
DTNs are standardized by IETF (Internet Engineering Task Force) in RFC 4838 and the Consultative Committee for Space Data Systems (CCSDS) in 734.1-B-1 and 734.2-B-2
I have watched this thrilling video series on ION
https://www.nasa.gov/technology/space-comms/delay-disruption-tolerant-networking-overview/
This article is mostly notes I took while watching. The highlights if you will.
Implementations
ION is not the only implementation, although it is the one I'll be focusing on for this article. Some other DTN implementations you should look into are as follows:
DTN2 (C and C++) reference implementation of BP (bundle protocol) (RFC 5050), LTP (Licklider Transmission Protocol)
Used in "Networking for Communications Challenged Communities" (N4C) platform and project
DTN2 platform applications
DTNmailex
HTML requester
PyMail
Postellation
Runs on client systems like Windows MacOS, Linux, BSD, and RTEMS
IBR-DTN
Designed for embedded systems using OpenWrt
Tested on x86, MIPS, Raspberry Pi, BeagleBone, and various ARM platforms as x86/x64 Linux distros (Debian and Ubuntu)
DTNME
Mostly C++ and C
ION
Written in C
Portable POSIX (Supported OS include RTOS, Linux, Windows, Android, Solaris, OS/X, RTEMS, VxWorks, FreeBSD
I also found this repo for ION: https://github.com/NASAHackTO/ion-dtn which seems pretty good for resources and the like, but NASA did say in the sourceforge comments that they plan to move to Github themselves, so I'd like to link to their repo at some point.
ION DTN Stack
BP (bundle protocol)
LTP (Licklider Transmission Protocol)
DGR (Datagram Retransmission)
ICI (Interplanetary Communication Infrastructure)
CFDP (CCSDS File Delivery Protocol)
AMS (Asynchronous Message Service)
BSS (Bundle Streaming Service)
Unlike LTP, DGR is designed to operate responsibly on the internet.
file2dgr and dgr2file good testing executables
The DTN protocol stack
Bundle Protocol
So this entire architecture sends packets in bundles rather through a connection. RFC 9171 is an update to the bundle protocol. You see it has these things like bundle age and timeouts. Timeouts? I thought this was delay tolerant why do we have timeouts? So its basically because this entire thing is actually very mindful of time. We will get into contact plans in a moment, but if one contact plan doesn't work out, then the packets need to switch to a different contact plan to route for the current scheduled time that specific routes are available. This will make more sense in contact graph routing.
This protocol is also very metadata heavy, and metadata is a bitch
"We kill people based on metadata"
https://www.youtube.com/watch?v=tL8_caB35Pg
A little pictorial shotgun for a moment
This is the ION DTN design overview
This is ION flow control
This is main line data flow
This is the ION software structure
ION runs on top of this other program called "core"
Contact Graph Routing
So instead of BGP, we have contact graph routing. Routes are optimized by which contacts are available for receiving data at a given time. Availability times and distance in seconds (time delay for data to reach its destination) are mapped in a series of graphs that allow for as efficient as possible path mapping.
Pulling from the tutorial html file in that non-official ION repo, an example contact would look like this in the configuration file:
a range +1 +3600 1 1 1
a: adds this entry in the configuration table.
range: declares that what follows is a distance between two nodes.
+1: is the relative start window for this contact (relative to the time s was issued).
+3600: is the relative end window for this contact (relative to the time s was issued).
1: is the source node IPN element number.
1: is the destination node IPN element number.
1: is the one-way speed of light time (here, one second is the minimum).
There's more to these configurations, but I hope this gives you an idea of what its like to configure it. There's more located here: https://github.com/NASAHackTO/ion-dtn/blob/master/ion-open-source/tutorial.html under "The Ion Configuration File"
So ION, is looking for "light time" what that really means is, how long will light take to get to the satellite or put another way, how long will it take for data to get to its destination if we were to apply this to our other transport methods.
Debugging
When using ION, these letters might pop up, those are error codes to show you what's going on.
Address Schemes
Bundle Protocol uses Endpoint IDs instead of IPs
Relies on URIs rather than DNS (although functions in a similar way)
scheme_name:scheme_specific_port
ex: dtn://topquark.caltech.edu/mail
IPN (alternative to DTN)
ipn:node_number.service_number
This way of doing things works when every relay in the DTN network knows about every relay in the network and have their ID in their contact graph route. It fails to work when names are not known or no route in the contact graph route can be found. I do think this scheme would need to be extended if it were to scale, and I can see exactly how you would extend it already so I'm not too worried about it.
How would I extend it? Basically subdomains based on region a lot like post office addresses actually. So, dtn://hemisphere.timezone.nerd2ninja.com and that would just help with routing so global routing gateways could get packets to a regional gateways that has gateways with contact plans for that area instead of having every gateway have contact plans for the whole world.
Licklider Transmission Protocol
Licklider Transmission Protocol also known as LTP is basically our stand-in replacement for TCP in a DTN network. Its actually for the convergence layer aka its for when your DTN hits IANA ISP routes to find its way to the next DTN node. It does not have negotiation or handshakes, but it does have acknowledgement and receipt reporting. It does not specify any flow control or congestion control and so ISPs don't support it natively. Instead, LTP is recognized by DTN noes, but ISPs see UDP packets. So the LTP packet is inside of UDP packets.
An LTP packet
Bit 0 1 2 3 4 5 6 7 ^ +-----+-----+-----+-----+-----+-----+-----+-----+ | | Version number | Segment Type Flags | Control | +-----------------------+-----------------------+ -byte | | | | / Session ID
| \ / Header +-----------------------+-----------------------+ | | Header Extension Cnt. | Trailer Extension Cnt.| Extensions | +-----------------------+-----------------------+ | | | | / Header Extensions
| \ / V +-----------------------------------------------+ | | | | | | | Segment Content | /
\ / | | | | | | ^ +-----------------------------------------------+ | | | Trailer / Trailer Extensions
| \ / V +-----------------------------------------------+
Converging network interoperability
Conclusion
DTN networking is almost a complete set of tools needed for our altnet methods mentioned previously and likely into the future to work and interoperate. With the concept of convergent networks, even otherwise incompatible protocols such as Post Office addressing can be interoperable. It wouldn't be LTP, but it could be a protocol with its own spec that we could extend this DTN stack with if so desired.
If you're interested in starting a Bitcoiner (and who knows what else otherwise) DTN network, let me know. I'm considering starting a public Discord server given the interest is there.