Download ppt - DTN Things on a DSG web server

A flexible interplanetary Internet
Stephen Farrell
Trinity College Dublin, Ireland
[email protected]
Christian Jensen
Technical University of Denmark
Background
–
Work on Interplanetary Internet (IPN)
●
–
Generalised as a study of Delay tolerant
networking (DTN)
●
–
“Bundles” passed between nodes during strictly
scheduled “contacts”
– ISOC SIG: http://www.ipnsig.org
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
–
●
More flexible experiment communications
–
●
Constellations, Sensor networks, weather etc.
Data from new SC using old SC as routers
–
●
Network (more) ignorant of application
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
–
●
Inherently “bursty” experiments
–
●
Probably always inevitable
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
[email protected]
More materials near:
http://down.dsg.cs.tcd.ie/
(will include a link to latest stuff when the paper's due)
./flexi20031024-1/endrun.txt
theIPN.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.txt
theIPN.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.txt
theIPN.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.txt
theIPN.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.txt
theIPN.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)