A flexible interplanetary Internet

Stephen FarrellTrinity College Dublin, Ireland

Stephen.Farrell@cs.tcd.ie

Christian JensenTechnical University of Denmark

Background– Work on Interplanetary Internet (IPN)

● “Bundles” passed between nodes during strictly scheduled “contacts”

– ISOC SIG: http://www.ipnsig.org– Generalised as a study of Delay tolerant

networking (DTN)● E.g. Sensor networks, some application based on

1980's email– IRTF RG: http://www.dtnrg.org

– DTN vs IPN● Generally not (very) strictly scheduled● Less predictable data flows● Broader applicability

Reasons to look at this

● More direct PI control of experiments– Network (more) ignorant of application

● More flexible experiment communications– Constellations, Sensor networks, weather etc.

● Data from new SC using old SC as routers– Ubiquitous network stack including forwarding

● Ability to handle more S/C– Alleviate DSN bottleneck, improve re-scheduling– Longer mission duration (SEP)

A (Comp. Sci.) reason to look at this● Internet architecture calls for all (well, most)

intelligence to be at the network edges– Drop packets if you must– Eases new service introduction (ISPs don't care)

● Web architecture calls for accepting (as normal) unresolved links– Databases no longer require link integrity and are much

easier to start● Can an IPN take a similar approach?

– Would it be better if it did?● Maybe, but depends on the “scale” of the network

When scaling might hit...

● DSN oversubscription– Probably always inevitable

● Inherently “bursty” experiments – Perhaps space weather, GRBs (and other things

I don't understand:-)● New SC comms architectures

– Orbiter, primary lander, secondary sensor nodes each with different comms. capabilities

– Humans beyond LEO

“Flexible” IPN concept– Its a DTN which

● Meets IPN requirements to handle latency, uni-directional comms etc.

● Includes schedule generation and distribution (in a delay-tolerant fashion!)

● Allows simultaneous use of various routing topologies and forwarding schemes

– Aiming to ● Allow PIs to control their experiments from

their desktops to a much greater degree than today

● Increase the efficiency of the overall use of resources, when hit by scale factors

Flexible IPN example– PI has sensors deployed from a lander

● Sensors have settings which determine when they produce data

– PI decides to change settings● Commands (eventually) get to sensors via orbiter(s) and

lander– Orbiters may use a token ring equivalent– Lander/sensors may use (a successor to) AODV

● PI need not/cannot determine exactly when commands executed

– (Some time later) Data from sensors increases– Routers (eventually) notice this and reschedule

● Routers in sensors, lander, orbiter(s), earthstation● Schedule subject to many constraints (e.g. overall lander

data budget), maybe centrally generated

So far...– Simulations

● Based on OMNET++ discrete event simulator and JPL DE406 ephemeris (and maybe cspice if necessary)

● Routing topologies and forwarding schemes– Concept of the schedule as a data structure that is also

distributed● Similar to how train timetables worked before telegraph● Some work on schedule visualisation

● Traffic patterns– Request/response pattern– Triggered sensor pattern

Planned...

● Incorporate the scheduling and routing schemes into hardware – Lake water quality monitoring sensor network

application– H/W prototype planned for Spring '04

● Continue work on the “flexible” IPN concept and related simulations– Improve models (visibility, power, re-scheduling)– Would like to get good data against which to

compare the simulations!

Tentative conclusions

– Arguments for flexible IPN seem to be relatively convincing

● Scaling and unpredictable traffic patterns => congestion handling and all that goes with that

– Initial simulation results may support these arguments

● Very early days here● Maybe layering violations are good!

– When calculating schedules anyway, adding in the LTT's involved might help an edge node to re-calculate its scheduling without knowing much about the ephemeris

Questions?

Now, later, or tostephen.farrell@cs.tcd.ie

More materials near:http://down.dsg.cs.tcd.ie/

(will include a link to latest stuff when the paper's due)

./flexi20031024-1/endrun.txttheIPN.sinks[0] bps is: 0.57013 (total bits: 1.46619e+06, total time: 2.592e+06)theIPN.sinks[0] reporting: DIM'd 38715 messages!theIPN.sinks[1] bps is: 814.86 (total bits: 2.10884e+09, total time: 2.592e+06)theIPN.sinks[2] bps is: 121.361 (total bits: 3.14555e+08, total time: 2.592e+06)./hand20031024-1/endrun.txttheIPN.sinks[0] bps is: 17.8894 (total bits: 4.63059e+07, total time: 2.592e+06)theIPN.sinks[0] reporting: DIM'd 8087 messages!theIPN.sinks[1] bps is: 164.394 (total bits: 4.25888e+08, total time: 2.592e+06)theIPN.sinks[2] bps is: 150.411 (total bits: 3.89862e+08, total time: 2.592e+06)./hand20031024-2/endrun.txttheIPN.sinks[0] bps is: 151.734 (total bits: 3.92843e+08, total time: 2.592e+06)theIPN.sinks[0] reporting: DIM'd 16661 messages!theIPN.sinks[1] bps is: 1503.07 (total bits: 3.89393e+09, total time: 2.592e+06)theIPN.sinks[2] bps is: 139.669 (total bits: 3.62021e+08, total time: 2.592e+06)./flexi20031024-2/endrun.txttheIPN.sinks[0] bps is: 117.274 (total bits: 3.03969e+08, total time: 2.592e+06)theIPN.sinks[0] reporting: DIM'd 42463 messages!theIPN.sinks[1] bps is: 1823.34 (total bits: 4.726e+09, total time: 2.592e+06)theIPN.sinks[2] bps is: 116.137 (total bits: 3.0102e+08, total time: 2.592e+06)./filled20031030-1/endrun.txttheIPN.sinks[0] bps is: 191.537 (total bits: 4.96459e+08, total time: 2.592e+06)theIPN.sinks[0] reporting: DIM'd 15037 messages!theIPN.sinks[1] bps is: 1831.17 (total bits: 4.74637e+09, total time: 2.592e+06)theIPN.sinks[2] bps is: 288.596 (total bits: 7.48032e+08, total time: 2.592e+06)