Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
ISS Mars NASA Networking Robotics Space The Internet Hardware News

NASA DTN Protocol: How Interplanetary Internet Works 109

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.'"
This discussion has been archived. No new comments can be posted.

NASA DTN Protocol: How Interplanetary Internet Works

Comments Filter:
  • by cultiv8 ( 1660093 ) on Sunday November 11, 2012 @12:26PM (#41949939) Homepage
    sorry to hear you don't know how to use Google: http://en.wikipedia.org/wiki/Delay-tolerant_networking [wikipedia.org]
  • by AllanNienhuis ( 2772209 ) on Sunday November 11, 2012 @12:55PM (#41950115) Homepage
    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 :)
  • More like fidonet (Score:5, Informative)

    by Narrowband ( 2602733 ) on Sunday November 11, 2012 @01:20PM (#41950301)
    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.
  • by Immerman ( 2627577 ) on Sunday November 11, 2012 @01:26PM (#41950341)

    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.

  • Delays, delays (Score:5, Informative)

    by Immerman ( 2627577 ) on Sunday November 11, 2012 @01:37PM (#41950411)

    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.

  • Re:Linux (Score:4, Informative)

    by John Hasler ( 414242 ) on Sunday November 11, 2012 @04:32PM (#41951577) Homepage

    > 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/ [ohiou.edu]

These screamingly hilarious gogs ensure owners of X Ray Gogs to be the life of any party. -- X-Ray Gogs Instructions