Interplanetary Internet (IPN): An Architectural Definition

1. Introduction 2. Inter-Internet Dialogs 3. Building a stable Backbone for the IPN 4. IPN Nodes 5. Security in the IPN 6. Deployed Internets in the IPN 7. Working Conclusions

1. Introduction Introduction (1) TCP/IP works well in terrestrial communication TCP/IP will also work well on other planets, on moons and in space crafts Reason: similiar propagation delay, bit error rate and bandwidth like on earth

1. Introduction Introduction (2) Differences between intraplanetary and interplanetary Internet: Propagation delay Low and asymmetric bandwidth Intermittent connectivity High bit error rate Problems with permanent power supply

1. Introduction Introduction (3) Chatty protocols like TCP/IP are relatively unattractive for an Interplanetary Internet IPNSIG was formed to develop protocols for an Interplanetary Internet

2. Inter-Internet Dialogs Inter-Internet Dialogs 1 Principles of Design 2 The center of the IPN: the Bundle Layer Concept (store-and-forward overlay network) Reliability at the Bundle Layer 3 Bandwidth Allocation via Market Mechanisms: Starbucks

2. Inter-Internet Dialogs Principles of Design - Name Tuples Consisting of Administrative and Routing Parts Internet on Earth: Hierarchical Name Space: host name, [subdomain]+, top level domain, root e.g. www7.informatik. uni-wuerzburg.de Top Level Domains (TLD) geographic split (e.g. de, fr,...) organisational split (e.g. com, org, net, edu,...) Domain Name System (DNS) used mostly to translate between domain names and IP addresses

2. Inter-Internet Dialogs Principles of Design - Name Tuples Consisting of Administrative and Routing Parts Problems at the IPN: distributed nature of the DNS database zone transfers solutions?.sol with topological significance.com means.com ON EARTH

2. Inter-Internet Dialogs Principles of Design - Name Tuples Consisting of Administrative and Routing Parts Names in the IPN should consist of a tuple: {administrative part, routing part} e.g. {www.ipnsig.org, earth.sol} routing part serves purpose of new TLD Advantages: only the routing part must be resolvable everywhere routing part identifies Internet as IPN-Region e.g. earth.sol would be an IPN-Region including the entire Earth administrative part must only be resolvable at the corresponding IPN-Region

IPN-REGIONS

2. Inter-Internet Dialogs The center of the IPN: the Bundle Layer - Concept (store- and- forward overlay network) 1 Problem: intermittent connectivity reasons: physical, schedule-related, administrative 2 Problem: high priority interrupt traffic 3 Problem: varying communication environments including different transport protocols Information has to be stored for an indefinite period!

2. Inter-Internet Dialogs The center of the IPN: the Bundle Layer - Concept (store- and- forward overlay network) Possible solution: BUNDLE LAYER IPN-Nodes terminate the transport-layer protocols in the respective IPN-regions Informations should be stored at a higher layer before forwarded Bundle protocol store-and-forward overlay network

2. Inter-Internet Dialogs The center of the IPN: the Bundle Layer - Concept (store- and- forward overlay network) Concept: atomic bundle in the IPN it is the Bundle Layer operates end-to-end, not the transport layer protocol terminating the transport protocols at the IPN nodes, decouples the Internets in different IPN regions ADVANTAGE: modularity & extension aspects

2. Inter-Internet Dialogs The center of the IPN: the Bundle Layer - Concept (store- and- forward overlay network) An Example An Internet IPN-Backbone An Internet A B* C* D* E * = Custody Transfers Return Receipt

2. Inter-Internet Dialogs The center of the IPN: the Bundle Layer - Concept (store- and- forward overlay network) The Bundle Layer provides a lot of services to applications using it: late binding of destination name s administrative part to an address transmission of user s specification for reliability quality of service security provide error recovery mechanisms

2. Inter-Internet Dialogs The center of the IPN: the Bundle Layer - Reliability at the Bundle Layer End-to-end reliability can only be assured at the Bundle Layer each Bundle Layer entity is confident, that the transport layer operates successfully if failures occur: the prior custodian-node re-transmit any missing data Highly optimistic timers (minimize unnecessary Bundle Layer retransmission): give the Transport protocols every opportunity to complete reliable transmission

2. Inter-Internet Dialogs Bandwidth Allocation via Market Mechanisms: Starbucks To promote the performance of the IPN some sophisticated and adaptable bandwidth allocation system are required Idea: fare-paying packets source application (bundle sender) specifies total funds allocated, getting the bundle delivered to the destination

3. Building a stable Backbone Building a stable Backbone for the IPN 1 Common things of IPN & terrestrial Backbones 2 Differences between interplanetary & terrestrial Backbones 3 Backbone Design Considerations

3. Building a stable Backbone Common things of IPN & terrestrial Backbones Terrestrial and extraterrestrial Internet: performance and capability are determined by capacity and stability of its backbone backbone links are between the highactivity subnets e.g. on Earth: between Chicago and Houston in the IPN: between Earth and Mars

3. Building a stable Backbone Differences between interplanetary & terrestrial Backbones different transmission medias: on earth: copper respectively optical fiber at the IPN: radiation - RF or optical different mode of connectivity between backbone POPs: on earth: connectivity structural & static at the IPN: connectivity operational, directed & highly dynamic

3. Building a stable Backbone Differences between interplanetary & terrestrial Backbones much higher costs of deploying, repairing and upgrading infrastructure at the IPN - Backbone higher costs of configuring, operating & managing the IPN - Backbone shortage and costs of electrical power speed of light is the most important constraint on IPN - Backbone operations

3. Building a stable Backbone Backbone Design Considerations 2 general constraints on the design of the IPN - Backbone: Bandwidth is not free, or even cheap. Interactive protocols don t work, at least not well.

3. Building a stable Backbone Backbone Design Considerations Design constraints must be accomodated at 4 layers of the protocol stack: physical layer: physical infrastructure of the IPN-Backbone consists mainly of antennas problems: accuracy in pointing & transmission scheduling at the backbones antennas all elements of the IPN-Backbone infrastructure must have in common: (a) one another s orbital dynamics (b) current time

3. Building a stable Backbone Backbone Design Considerations link layer: link protocols that minimizes overhead CCSDS protocol standards network layer: no interplanetary backbone functionality will be required at this layer transport layer: as discussed before: TCP will not be suitable! But: the Bundle Protocol residing just above the transport layer

3. Building a stable Backbone Backbone Design Considerations Bundle Protocol: relatively optimistic about transmission success but it must have transport-layer-like properties: recover from transmission failure at lower layers capacity for timeout detection and custodian-to-custodian retransmission

3. Building a stable Backbone Backbone Design Considerations Bundle Protocol: optimism results from the general trustworthiness of lower layers: When the Bundle Protocol runs over TCP in a deployed Internet, TCP s own retransmission regime automatically recovers from errors in the network and link layers, and only a failure in TCP itself will trigger retransmission at the bundle layer.

4. IPN-Nodes IPN-Nodes - Types of IPN Nodes - Backbone Connectivity - IPN Gateway Routing - The Contact Scheduler - The Route Evaluation - The Dispatcher Algorithm - Example: end-to-end transfer - Possible Errors - Support of existing applications

4. IPN-Nodes Types of IPN Nodes Three types of IPN Nodes: - All nodes are bundle agents - Some bundle agents are able to act as IPN Relays - Some IPN Relays are also able to act as IPN Gateways

4. IPN-Nodes Backbone Connectivity IPN long-haul communication links are directional, mobile and highly scheduled When a bundle arrives at an IPN Gateway, some or all outbound routes may be down Interplanetary Internet should use store-andforward mechanisms to route bundles

4. IPN-Nodes IPN Gateway Routing Routing in IPN Gateways has three distinct parts: - The contact scheduler - The route evaluation algorithm - The dispatcher algorithm

4. IPN-Nodes IPN Gateway Routing- The contact scheduler Input: orbital mechanics, resources management Output: schedule for next-hop communication (planned contacts, duration, expected data rate) First centralized, later distributed contact scheduling algorithm

4. IPN-Nodes IPN Gateway Routing- The route evaluation Exchange of information with first-hop neighbors to build a picture of the IPN beyond first-hop neighbors Goal: distance-vector representation for routing Metrics are still in development

4. IPN-Nodes IPN Gateway Routing- The dispatcher algorithm Input: contact schedule, routing information, policy information, specifications provided by the bundle transport layer Output: Manifest for each next-hop contact

4. IPN-Nodes Summary of gateway routing Contact scheduler Policy information Bundle arrives Bundle send to next hop Routing Function Request Transmisson time Dispatcher Manifest

4. IPN-Nodes - Example: end-to-end transfer SRC Earth s IPN Region: earth.sol DNS 1 GW 1 DNS2 The Backbone IPN Region: ipn.sol GW 3 GW 4 GW 2 Venus IPN Region: venus.sol Jupiter s IPN Region: jupiter.sol DNS 3 DST Mars IPN Region: mars.sol

4. IPN-Nodes Example: end-to-end transfer Host IPN Regions Host name Tuples SRC earth.sol {src.jpl.nasa.gov, earth.sol} IPN GW1 IPN GW 2 earth.sol ipn.sol ipn.sol mars.sol {ipngw1.jpl.nasa.gov, earth.sol} {ipngw1.jpl.nasa.gov, ipn.sol} {ipngw2.nasa.mars.org, ipn.sol} {ipngw2.nasa.mars.org, mars.sol} DST mars.sol {dst.jpl.nasa.gov, mars.sol} Table 1: Host name Tuples

4. IPN-Nodes Example: end-to-end transfer Step 1: Bundle creation and first-hop transmission - Source host on earth has data that it wants to send to a destination host to mars - Bundle agent creates a bundle and stores it in persistent storage - Information in Bundle header: Bundle Idendifier, Source Host name Tuple, Custodian name Tuple, Time to live

4. IPN-Nodes Example: end-to-end transfer Item Value Description Destination Host name Destination application instance handle Source application instance handle Handling instructions Data {dst.jpl.nasa.gov, mars.sol} 0x0000008 0x1763421A Reliable delivery, priority IPN Name tuple of the destination Similiar to port number used to identify the source application instance for response processing The services requested from the bundle Table 2: Information passed from source application to bundle agent

4. IPN-Nodes Example: end-to-end transfer - Dispatcher finds, that next-hop neighbor is {ipngw1.jpl.nasa.com, earth.sol} - Bundle is sent via TCP

4. IPN-Nodes Example: end-to-end transfer Step 2: Bundle processing at first-hop destination: - IPN Gateway receives bundle via TCP and stores it in persistent storage - Bundle agent accepts custody of bundle, updates the bundleheader and informs the source - Source bundle agent deletes its copy of the bundle

4. IPN-Nodes Example: end-to-end transfer - Dispatcher checks time to live in the bundle - Dispatcher finds that next-hop neighbor is in the ipn.sol region {ipngw2.nasa.mars.org, ipn.sol} - Dispatcher provides time at which the bundle should be send to ipngw2 via Long Haul Transport Protocol (LTP) - Bundle is transmitted at the given time

4. IPN-Nodes Example: end-to-end transfer Step 3: Bundle processing at gateway to destination IPN region - Mars gateway receives bundle via LTP - Mars gateway stores bundle on persistant storage, accepts custody of the bundle and signalises success back to earth - Dispatcher returns, that the next-hop is the destination, that the proper protocol is TCP and that the destination is accessible immediately - Mars gateway forwards bundle to destination

4. IPN-Nodes Example: end-to-end transfer Step 4: Bundle processing at destination - Destination bundle agent receives bundle via TCP, stores it in persistant storage and accepts the custody of the bundle from ipngw2 - Bundle agent awakens destination application process identified by the Destination Application Instance Handle - Bundleagent deletesthe copy of the bundlewhen the application received it

4. IPN-Nodes - Possible Errors Possible Errors Unknowndestination region Invalid Source Application Bundle Parameter Syntax Error Bundle Parameter Semantic Error Invalid Node Name Insufficient buffer space DNS unreachable

4. IPN-Nodes - Possible Errors Possible Errors Time exceeded Source Entity Access denied Invalid Administrative Destination Name Invalid Destination Application End-to-end Access denied

4. IPN-Nodes - Support of existing applications Support of existing applications There is no clean way to support applications in the IPN SMTP is perhaps the only application that could possibly be tuned to work over interplanetary distances