Slashdot Mirror
NASA DTN Protocol: How Interplanetary Internet Works
First time accepted submitter GinaSmith888 writes "This is a deep dive in the BP protocol Vint Cerf developed that is the heart of NASA's Delay-Tolerant Networking, better known as DTN. From the article: 'The big difference between BP and IP is that, while IP assumes a more or less smooth pathway for packets going from start to end point, BP allows for disconnections, glitches and other problems you see commonly in deep space, Younes said. Basically, a BP network — the one that will the Interplanetary Internet possible — moves data packets in bursts from node to node, so that it can check when the next node is available or up.'"
The main problem is the long delay at light speed.
:( :( :(
I thought something like this already existed. And it worked pretty well at the time.
http://en.wikipedia.org/wiki/UUCP
The only problem with the BP protocol is the data mining rigs that burst and spread raw SQL queries all over the coast of Amazon.com and then wonder why people are pissed that they can't buy or sell from that site until its cleaned up!
This is where you're completely wrong. Having a network infrastructure that extends outside of our planet (an extranet if I ever heard one!) is a requirement for being able to do things like set up bases and control robotic devices remotely. What we're doing is setting the groundwork for more than one user or group to both control and receive the telemetry from whatever mechanized device we send outside of our own atmosphere! This is huge!
Consider this: We send a basic construction rover and a 3D printer to Mars. Both are controlled by DTN/BP. We can send the 3D printer blueprints for parts and assembly instructions to the construction rover. That would allow us to build up an infrastructure before we even get there and monitor it by adding parts on an as-needed basis. It would allow us to do so cheaper as well, as things can be sent in smaller chunks, and some of it could be manufactured on the fly on site. Doing this using any of the older protocols or even proprietary mechanisms could make things much more complicated, especially if you decide to handover control or add members to a project you've already started.
Reminds me of the problems the old FidoNet had to deal with - nodes not being available, or only available for short times, poor quality connections, low speed, etc. It worked remarkably well for all of those conditions I thought :)
Don't judge me based on my high slashdot user id!
While on the subject, when are we going to establish repeater stations around the solar system so that space probes don't need massive transceivers and line-of-sight to communicate with the Earth?
Actually it sounds more like fidonet. Store and forward networking just like early infrastructure that let email from dial up bbs nodes eventually reach a destination.
You mean the same way private industry invented the current internet protocols? Hint - they didn't. I think the point is while we don't have people out beyond the moon we do have an ever-increasing number of *machines* out there, every one of them equipped with a custom communication mechanism rendering them incapable of communicating with each other. If we work out a nice robust, standardized protocol now then not only do future probe developers (also mostly government funded) not need to spend time and money developing a new communication protocol, but future probes have the potential to intercommunicate with each other as well. One obvious application would be using "healthy" probes to act as relay stations for probes whose antennas or power supplies have degraded to the point that they no longer have the necessary gain to reliably communicate with Earth, but are otherwise operational. Or to route signals along clean signal paths where much lower transmission power is necessary - for example if a probe is in conjunction with Jupiter, the sun, or some other powerful radio source it is presumably much more difficult for Earth to receive a clean signal directly from it (or contrariwise if it was Earth in conjunction from the probe's perspective) Beyond that, who knows? Certainly few people envisioned most of the current uses of the internet when the protocols were being developed.
Oh, and we have plenty of mechanisms to get people past the moon, just getting into high orbit puts us half way to anywhere in the solar system, and it's actually easier to reach Earth's L3- and L4-point asteroid fields than it is to reach the Moon, we just haven't really had the motivation to do so yet. We could even get to Mars pretty easily with current technology if we wanted to, though arranging a return trip complicates things a little since we'd be down at the bottom of a gravity well again - i.e we'd need to either carry a staggering amount of extra fuel along, or establish a refueling base there. There'd be no shortage of volunteers for a one-way trip though, *especially* if the plan was to set up a sustainable base which would eventually (after years/decades) enable round trips to begin.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
The problem is most any terrestrial network protocol expects a minimal signal-response delay between nodes, whereas even a perfectly functioning terabit/s Earth-Mars link would still have between a 6 and 40 minute delay due to the speed of light.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
I am running a test: still waiting on a result:
ping -W 118000 voyager1.nasa.gov
> when will Linux support it?
Package: ion
Version: 3.0.1~dfsg1-1
Installed-Size: 2618
Maintainer: Leo Iannacone
Architecture: amd64
Depends: libion0 (= 3.0.1~dfsg1-1), libc6 (>= 2.7), libexpat1 (>= 2.0.1)
Suggests: ion-doc
Description-en: NASA implementation of Delay-Tolerant Networking (DTN)
Interplanetary Overlay Network (ION) software distribution
is an implementation of Delay-Tolerant Networking (DTN)
architecture as described in Internet RFC 4838.
.
This is a suite of communication protocol implementations designed
to support mission operation communications across an end-to-end
interplanetary network, which might include on-board (flight) subnets,
in-situ planetary or lunar networks, proximity links,
deep space links, and terrestrial internets.
.
Included in the ION software distribution are the following packages:
* ici (interplanetary communication infrastructure) a set of libraries
that provide flight-software-compatible support for functions on
which the other packages rely
* bp (bundle protocol), an implementation of the Delay-Tolerant
Networking (DTN) architecture's Bundle Protocol.
* dgr (datagram retransmission), a UDP reliability system that implements
congestion control and is designed for relatively high performance.
* ltp (licklider transmission protocol), a DTN convergence layer for reliable
transmission over links characterized by long or highly variable delay.
* ams - an implementation of the CCSDS Asynchronous Message Service.
* cfdp - a class-1 (Unacknowledged) implementation of the CCSDS File
Delivery Protocol.
.
This package contains the binary files.
Homepage: https://ion.ocp.ohiou.edu/
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Better anticipate on the things you want to do on Mars, than to send over raw materials and a 3D printer, and think... "gosh, what shall we put together today?"
It's more like "gosh, what broke today?"
Assuming a 3D printer could work on Mars (no idea if that's possible), you could use it to greatly increase efficiency. Instead of sending over 2 or 3 of every possible item that might break or wear out, you could just send over 2 or 3 3D printers, and use them to replace broken tools as necessary. (Including, of course, worn-out 3D printers ;^))
I don't care if it's 90,000 hectares. That lake was not my doing.
...something amateur ("ham") radio operators have been using since the 1980's...
-allen
KC2KLC
I am not a number - I am a free man!
Remember modem connections and 'feeds' for news and email? When most links were offline most of the time? Yep, networking before 'up all the time' connections were available to most of the world.
I had a Linux (and before that a Mark Williams 'Coherent' UNIX like) computer that ran UUCP, and did dial on-demand connections. I had it download email and subscribed usenet 'news feeds' nightly from a local university that had 'free' connections for members of the local UNIX computer users group.
It worked. It was solid once I got all the config's right.
Not long ago I saw some articles on the wide area network wireless internet in Africa uses these techniques even today to get connectivity 'out there' without having to have 'up all the time' servers in remote communities.
Usenet newsgroup and email server software are still there and available if anyone wants to use them. Actually, I should look into that for my local use too!
I would like to see the new BP protocol implemented and distributed with Linux. It could be great for implementing 'automotive node' networks (put a BP node in your car, and it could communicate whenever it found a un-secured WIFI connection as you drive down the road!
Dreaming... Life goes on.
... "When you pry the source from my cold dead hands."