A flexible interplanetary Internet Stephen Farrell Trinity College Dublin, Ireland Christian Jensen Technical University of Denmark

Background – Work on Interplanetary Internet (IPN) ● “Bundles” passed between nodes during strictly scheduled “contacts” – ISOC SIG: – Generalised as a study of Delay tolerant networking (DTN) ● E.g. Sensor networks, some application based on 1980's – IRTF RG: – 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 to More materials near: (will include a link to latest stuff when the paper's due)

./flexi /endrun.txt theIPN.sinks[0] bps is: (total bits: e+06, total time: 2.592e+06) theIPN.sinks[0] reporting: DIM'd messages! theIPN.sinks[1] bps is: (total bits: e+09, total time: 2.592e+06) theIPN.sinks[2] bps is: (total bits: e+08, total time: 2.592e+06)./hand /endrun.txt theIPN.sinks[0] bps is: (total bits: e+07, total time: 2.592e+06) theIPN.sinks[0] reporting: DIM'd 8087 messages! theIPN.sinks[1] bps is: (total bits: e+08, total time: 2.592e+06) theIPN.sinks[2] bps is: (total bits: e+08, total time: 2.592e+06)./hand /endrun.txt theIPN.sinks[0] bps is: (total bits: e+08, total time: 2.592e+06) theIPN.sinks[0] reporting: DIM'd messages! theIPN.sinks[1] bps is: (total bits: e+09, total time: 2.592e+06) theIPN.sinks[2] bps is: (total bits: e+08, total time: 2.592e+06)./flexi /endrun.txt theIPN.sinks[0] bps is: (total bits: e+08, total time: 2.592e+06) theIPN.sinks[0] reporting: DIM'd messages! theIPN.sinks[1] bps is: (total bits: 4.726e+09, total time: 2.592e+06) theIPN.sinks[2] bps is: (total bits: e+08, total time: 2.592e+06)./filled /endrun.txt theIPN.sinks[0] bps is: (total bits: e+08, total time: 2.592e+06) theIPN.sinks[0] reporting: DIM'd messages! theIPN.sinks[1] bps is: (total bits: e+09, total time: 2.592e+06) theIPN.sinks[2] bps is: (total bits: e+08, total time: 2.592e+06)