Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Piggybacking (Internet access) wikipedia , lookup
Network tap wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Serial port wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Automated airport weather station wikipedia , lookup
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)