Interplanetary Internet (IPN): An Architectural Definition

Transcription

1 Interplanetary Internet (IPN): An Architectural Definition

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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. { 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

11 IPN-REGIONS

12 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!

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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.

25 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

26 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

27 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

28 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.

29 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

30 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

31 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

32 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

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

34 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

35 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

36 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

37 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

38 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

39 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

40 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

41 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} 0x x A 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

42 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

43 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

44 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

45 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

46 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

47 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

48 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

49 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

50 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

51 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