InterPlaNetary Internet Vint Cerf DARPA Proposer’s Day 21 January 2004
Acknowledgments • The IPN Team: • • • • • • •
Juan Alonso - SICS Adrian Hooke, Scott Burleigh, Leigh Torgerson – JPL Eric Travis – GST Bob Durst, Keith Scott – MITRE Howard Weiss – SPARTA Kevin Fall – Intel/UC Berkeley Vint Cerf - MCI
Pathfinder Mission: Sojourner 1997 on Mars
2003-2004 Missions to Mars • Spirit – launched 6/10/2003 1:58 PM EDT – arrives Jan 4, 2004 – Gusev Crater in Gusev Plain
• Opportunity – Launched 7/7/2003 – arrives Jan 25, 2004 about 9:05 pm PST – Meridiani Planum
Deploy standard internets in low latency remote environments 1 (e.g., on other planets)
The three building blocks of the IPN Architecture
Connect distributed 2 internets via an interplanetary backbone
Support dialog across a network of Internets 3
The Basic IPN Concept: construct a “Network of Internets”
Deploy standard The IPN is a internets in low “network of latency remote environments internets” (e.g., on other planets)
Operations driven by power, weight, volume
High value data, finite buffers
Long propagation delays
Connect distributed Transaction internets via an sizes are small compared to interplanetary backbone
bandwidth-delay product
Support dialog Backbone contact periods: across a network • short relative to delay of Internets
• possibly one-way • possibly separated by days, weeks The Basic IPN Concept: • cannot guarantee construct an a end-to-end path “Network of Internets”
The Internet is a connected, chatty ‘network of networks’ based on a wired backbone with negligible delay and errors (with untethered “edges” emerging) The InterPlaNetary Internet is a disconnected, store-and forward ‘network of Internets’ based on a wireless backbone with huge delays and error prone links
Some of the Hard Problems • • • • • •
Time synchronization/scheduling Antenna pointing(note optical) Routing Flow Control Error handling, retransmission, reassembly Persistent communication over operation system reboots • Mobile robot control in high delay/uncertainty cases • Naming conventions (DNS doesn’t work: tuples!) • Mobile spacecraft with multiple “named” processes
Deploy standard The IPN is a internets in low “network of latency remote environments internets” (e.g., on other planets)
Connect distributed internets via an interplanetary backbone
to
ay dialog Support w l era across a network n e n a la i y g e a t e of Internets a d d c e i
ne mun long e W com ted, c ent e m n on viron c s di en
So does of this Thehow Basic IPNall Concept: relate to the construct a “Network of Internets” Interplanetary Internet?
IP: the “Thin Waist” of the Earth’s Internet App App
App App
App
Transport TCP Network IP
App
Transport TCP Network IP
Network IP
Network IP
Link 1
Link 1
Link 2
Link 2
Link 3
Link 3
Phys 1
Phys 1
Phys 2
Phys 2
Phys 3
Phys 3
Subnet 1
Subnet 2
Subnet 3
Internet: a Network of Connected Sub-Networks
Bundles: A Store and Forward Overlay
The “Thin Waist” of the Interplanetary Internet App App
App App
App
Internet a
Transport a
Network a
Internet b
Bundle
Bundle
Network a
App
Bundle
Transport a
Transport b
Transport b
Network a
Network b
Network b
Link 1
Link 1
Link 2
Link 2
Link 3
Link 3
Phys 1
Phys 1
Phys 2
Phys 2
Phys 3
Phys 3
Network of internets spanning dissimilar environments
Sensor Webs
Current View: The IPN is a member of a family of emerging “Delay Tolerant Networks” Delay can be introduced by, e.g., Propagation at c Lack of connectivity Lack of resources (power, buffers) Simplex or asymmetric channels
Interplanetary network
Stressed tactical communications
Delay/Disruption Tolerant Networking (“DTN”)
The Problem • Mobile communication systems are adopting and depending upon Internet technologies to enable combined voice/data communications • Commercial Internet technologies generally rely on a benign communications environment, assuming: – An end-to-end path exists and the nodes are always on. – Power, bandwidth, storage, network access are readily available. – Dialogue is always possible, interactivity is “free.”
• Untethered edges of the internet cannot rely on these assumptions, and they do not always hold for spacebased systems or terrestrial systems in stressed environments.
• Some of these challenges have been met through “hacks” rather than best of breed architecture. – Results tend to be “brittle” and purpose-built
Key DTN Architectural Concepts Routing Across Network Disruption
Message Oriented: Minimal interactivity
• On-demand connections
Instead of
• Scheduled connections • Predicted connections • Opportunistic (unexpected) connections
Store-and-Forward Operation A
A B
A B
Dst
Dst
Src
Src C
Overlay Network Operates above transport Uses available xport/net technologies
B
Dst
Src C
C Application
Bundle
Transport Network
Bundle
Transport Network
Bundle
Transport Network
Application
Bundle
Transport Network
Key DTN Architectural Concepts (Continued) • Regions aggregate nodes – Aggregation based on technology, policy, proximity, etc. – Gateways between regions provide control points, store-and-forward resources, active transcoding, opportunities for protocol translation (e.g., IPv4/IPv6 and non-IP systems)
• Infrastructure protection – – – –
Authenticated application registration Signed exchanges among routers S/MIME-like (no Diffie-Hellman exchange) Public keys may or may not (more likely) accompany the bundle
Src App
Dst App
Source Authentication
Optional Security Boundary
Src Bundle Node Fwd Auth
Fwd Auth
Dst Bundle Node
Fwd Auth
Key Architectural Concepts (Continued) • Routing across disconnection – Cognizant of path entropy • • • •
Persistent links Scheduled connectivity Predicted contacts Opportunistic contacts
– Selection based on path characteristics – Replication on multiple paths for robustness – Enables “fire-and-forget” networks robust against disruption
Key Architectural Concepts (Continued) • Late binding of names to addresses – Name tuple carries destination region and administrative name – Alleviates need for universal nameto-address binding database – Implicitly supports role-based addressing
• Class of Service similar to postal system – Types: Priority, regular, bulk – Options: send notification, keep delivery record, inform on delivery – Helps to optimize resource use
Key Architectural Concepts (Continued)
• Application multiplexing/demultiplexing – Demultiplexing based on administrative name, syntax defined by application – Provides a new general-purpose network delivery service
File Xfer
SA
WWW API
Bundle
Transport Network
• Process persistence/reanimation – Useful in embedded systems that are resource poor (e.g. sensor nets) – Upon bundle arrival, application and relevant state are reinstantiated – Allows operation across (planned or unplanned) power cycles, software, OS upgrades – Supports process migration to alternate hosts
C2
Voice Msg
DTN vs End-to-End Internet Operation Link is “up” S
TCP/UDP Latency
D
Link is “up” S
D
DTN Latency DTN Throughput
TCP/UDP Throughput
Current development activities • Improve robustness of current code base – Testing: MITRE, JPL, Intel-Research – Static Analysis: MITRE – Regression Test Development: MITRE, JPL
• Routing across intermittently-connected mobile ad hoc networks – MITRE – Examining alternative link availability and connectivity degree metrics – Alternate forwarding criteria under consideration: • Route on all paths that have availability > p • Route on the best paths until the sum of the metrics for those paths is > n
• Integrate Digital Fountain erasure coding software into DTN code base – MITRE – Highly efficient forward error correction coding – Complementary to forwarding over multiple paths, above
Prototype Implementation Structure Bundle App
Bundle Agent Libdtn (RPC)
Libdtn (RPC)
Bundle Forwarding TCP Convergence Layer
SensorNet Convergence Layer
[Long-Haul Net [Tactical Database Convergence Convergence Support Layer] Layer] (sleepycat)
sockets TCP
File Store
Sensor Network
IP
Protocols
[LongHaul Network Protocols]
802.3
802.11
[…] = not yet built
[Tactical Network Protocols]
File Store
Current DTN Implementation Limitations • No interregion multicast support yet – Can depend on IP-layer multicasting within a region, but DTN does not form trees at its own layer – Demultiplexing to multiple destinations within a node is supported
• Erasure-coding based reliability optimized for 10KB+ transfers – Digital Fountain coding imposes 5% overhead for messages >= this size, larger overhead for smaller messages
• Need to develop routing strategies for different interregional conditions – DTN forwarding decisions based on current connectivity and probability of future connectivity (calculated based on availability history of each link)
Relevant Documents • Internet Research Task Force Research Group (DTNRG) web site: www.dtnrg.org • Relevant Internet Drafts: DTN Architecture Document: draft-irtf-dtnrg-arch-01.txt DTN Bundle Protocol Spec: draft-irtf-dtnrg-bundle-spec-01
For Further Information: Robert C. Durst/Keith Scott The MITRE Corporation 7515 Colshire Drive M/S H300 McLean, VA 22102
[email protected],
[email protected] 703 883-7535, 703-883-6547 DARPA PM: Preston Marshall 703 696-5723
[email protected]
