1 / 26

Disruption Tolerant Networking (DTN) Program: Phase 1 and Phase 2/3 Program

DTN is a technology that provides network services in the face of disruption, reducing demands on network resources by integrating storage. This program aims to develop and demonstrate the effectiveness of DTN in disrupted areas.

mgillis
Download Presentation

Disruption Tolerant Networking (DTN) Program: Phase 1 and Phase 2/3 Program

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Disruption Tolerant Networking (DTN) Program Phase 1 And Phase 2/3 Program 23 March 2006 Preston Marshal, Program Manager Preston.marshall@darpa.mil 703-696-5273

  2. source disrupted areas Disruption Closes Connection Packet traverses net until blocked by a disruption destination Disruption Tolerant When disruption clears, packet traverses remainder of route Packet arrives at destination. In an IP network, packet wouldnever have left source Disruption Tolerant Networking (DTN)Program Concept Custodian-to-custodian connections isolate disrupted regions End-to-end severely disrupted by one bad link DTN’s Goal is to is to develop and demonstrate technology that will provide network services in the face of disruption and massive differences in delay and bandwidth; and to reduce demands on network resources by integrating storage into the network

  3. Military Need FCS Vehicle, Ft. Benning 2006 • FCS Communications Position Reports Used as Measure • Highly Favorable Metric Used • Loss of 2 Successive (1 Sec Interval) Reports Considered as Disconnected Wireless networks can be good for local connect, but often can’t reach back to infrastructure Local storage – caching – can create access to information after infrastructure connectivity loss. Relying on IP for tactical military networks is dangerous • Episodically connected military MANETs see rapid topology changes • Tactical radios know names, not destination addresses • Tactical/edge military networks may be a mix of IP and non-IP radios

  4. All Bandwidth is Not Equally Important • Networks are not hierarchies of bandwidth, they are islands • Bandwidth within islands not as important as bandwidth between islands • DTN augmentation within islands provides major performance benefits between islands • Nodes can use local bandwidth to obtain DTN services, even if not on own node • Similar to DARPA • Highly reliable, high speed (1 Gigabit) from servers on campus • Several Megabits in and out to Internet Bandwidth/Reliability 64 Kilobps Episodic Connectivity GIG Fiber Core Distance 10 Gigabps Highly Reliable Connectivity DTN Can Augment Existing Networks without Being Inserted into Topology 10 Megabps Highly Reliable Connectivity Wireless Enclaves

  5. Data only decrypted for access Data decrypted at end system DTN Current DTN Network Persistence Can Solve Fundamental Internet Application Shortfalls • DTN makes applications over disrupted networks robust • DTN is also an Opportunity to solve Fundamental Problems we’ve never before had a handle on, using Network-Managed Persistence • Access information by content or type rather than by network address • “I want maps for my area” instead of “I want to ftp to 192.168.4.17” • Retrieve once, provide to local users as requested • Learn from actual network usage • Exploit in-network storage/caches and pub/sub protocols to create a dynamic and self-forming “Akamai” • Use temporal security rather than physical security Temporal Security Model Time

  6. Subsequent requests for same data consume as much band-width with as much delay as the first request. Resources Used to Get Data ··· 1st 2nd 3rd Requests for same data Today’s Network: Push or Pull, Neither Optimal Conventional Pull: Copies to every requestor Only those who ask, get; but with delay; N requests use N times the bandwidth Multicast Push: Data goes to everyone I need a map I need a map I need a map I need a map I need a map Connected Network I need a map Connected Network I need a map I need a map I need a map I need a map I need a map Only one transfer, but data flows to everyone in the multicast group, not necessarily when / where the data is needed I need a map DTN Resolves Both Inefficiencies.. Pulls One Time, Distributes Locally To Requestors

  7. DTN Phase 1 Results • Demonstrated DTN v TCP with typical USMC wireless connectivity patterns (MITRE/CONDOR) • Demonstrated Network Delivery (BBN) • Demonstrated Trusted Delivery & Resistance to DDoS (Lehigh) • Designed architecture – intrinsic ability of DTN to operate to the extremes of the network without segmenting to match network characteristics – meta-architecture (MITRE/JPL) • Potential to move this extensible framework to other building blocks of the network • Have to adapt Cisco/Nortel/Lucent/Juniper behaviors • Implemented Experimental Operating Wireless DTN (GaTech/UMass)

  8. Demonstrated DTN v. TCP with USMC Wireless Connectivity Patterns INMARSAT terminal Cisco 2811 KG-250 DTN 10 KByte File Transfers in 24 hours Abandoned 10-KByte File Transfers in 24 hours 4000 140 user Cisco 3725 EPLRS 3500 120 HTTP HTTP 3000 CONDOR Gateway cable map DTN 100 DTN 2500 80 2000 3580 .. DTN Is A Deployable Technology With Massive Performance Benefits for DoD 115 60 1500 1000 40 500 20 368 0 0 0 Completed Abandoned Demonstrated that DTN is Useful & Feasible, and that DTN can be Transitioned to COTS-based Military Systems

  9.   Go/NoGo criterion metfor reliable delivery Phase 1 Go/NoGo Metric: Demonstrate DTN Network Performance in Disrupted Network & Evaluation PlatformHardware in the loop emulation of actual DTN nodes • 100% Reliable Delivery with • 80% Utilization over • 20% Available Links ACHIEVED • Link characteristics • capacity: 19.2 kb/s • delay: 5 ms • MTU: 1480 bytes • Bundle traffic • size: 2800 bytes • total originated: 264 • Network Transit time >620ms • Link StateTransit time 4.3s • Mean time between link transitions ~5s • Run time: 3600 s DTN would have delivered all traffic given enough time For random link dynamics, at most 16 (out of 31) bi-directional links were up at any time Network changes faster than it updates.. never static. IP would never have correct topology.. would fail in a conventional MANET

  10. Delivered Bundles Vs. Path DistanceRun at 20% Target Availability: Random Link Dynamics • Opportunistic Routing Found Ways to Deliver All Traffic, Regardless of Hops • TCP (End to End) Could Not Find Opportunities • End to End requires Complete Path be Available • End to End is Fundamentally Unsuited for Military Operations • 80% Links are only 20% Network Connected at 7 Hops • 20% Links are 0.001% Network Connected at 7 Hops • End to End IP (Without TCP) Shares All these Issues Delivery Performance for DTN and TCP DTN TCP End to End Transfer

  11. Delivery Ratio: Worst Case DynamicsDTN versus End-to-End (E2E) Baseline • DTN Accomplished All Deliveries for Availabilities Above Go/NoGo Criteria • Would Complete All if Longer Duration created Opportunities • End to End Could Not Find Sufficient Opportunities in Any Disrupted Scenario • Failed Completely Below 50% Availability DTN End to End

  12. Link Utilization Using DTN • DTN Effectively Used All Available Link Capacity • Network Was So Dynamic that End to End Would not be Aware of Opportunities to Use • Efficiency Decreases at High Availability, as More Overhead, and Early Completion of Transfers • Phase 2 Will Develop Technology to Adapt and Use both End to End and DTN Based on Which Would be Most Effective

  13. Trusted Delivery GNG Metric: ACHIEVED • Demonstrate rejection of message from unauthenticated sender • Demonstrate authentication and forwarding of message from trusted sender • Demonstrate payload data encryption Phase 1 Go/No Go: “Demonstrate Trusted Delivery”    DTN will not propagate Distributed Denial-of-Service Attack DTN will Detect & Reject Fraudulent (Forged Address) Messages

  14. Trusted Delivery GNG Metric: ACHIEVEDDemonstrate rejection of message from unauthenticated sender • Two sending nodes - one legitimate, one malicious - attempt to send a bundle in a network with the BAH feature enabled • The malicious node (M1) sends a bundle without the appropriate BAH to the forwarding node (N2) • Result: N2 rejects the bundle - ACHIEVED • The legitimate sender (N1) sends a bundle with the appropriate BAH, allowing for successful authentication • Result: N2 forwards the bundle to the destination (N3) BAH: Bundle Authentication Header Security Perimeter N1 N2 N3 M1 Should have been part of the Internet from the beginning

  15. Trusted Delivery GNG Metric: ACHIEVEDDemonstrate: 1.) Authentication and Forwarding of Message From Trusted Sender and 2.) Payload Data Encryption • N1 sends a bundle to N4 (thru N2) with only the BAH activated • The link between N2 and N3 is insecure, so policy at N2 requires payload data encryption • N2 encrypts the payload, adds the PSH, and becomes the PSH-source, with destination N4 the PSH-destination for the bundle • N4 receives the encrypted bundle from N3 (thru N2) and decrypts the message: ACHIEVED N3 N1 N2 N4 PSH-Source PSH-Destination BAH: Bundle Authentication Header PSH: Payload Security Header Red: Cleartext Black: Ciphertext DTN Enables Security Partitioning Based on Traffic Policies Rather than Physical Topology

  16. DTN System Architecture Bundle Engine API Legend Protocol Composition API Management API Autoconfiguration/ Neighbor Discovery Bundle Custody Transfer Bundle Encryption Bundle Flow/Congestion Ctl. Bundle End-to-end Reliability Bundle TBD Services DTN Policy/Management “DARPA” Routing Protocol Environmental Awareness “DTNRG” Routing Protocol Other Routing Protocol RoutingAPI Configuration API EnvironmentalAwareness API Convergence Layer Plug-ins/DLLs Process Rendezvous Single DTN Standard Will Be Extensible for Commercial or Uniquely Structured Military Apps Such As UAV Overflight, Sensor Nets, Tactical Disruption …

  17. Technology for a Common Routing Structure with Mission-Unique Algorithms Wireless networks need diverse routing behaviors: “Open Biggest Battery First” (Battery-powered systems) “Use Advantaged Node Last” (Transient aircraft nodes) “Open Least Tx Energy Path First” (Energy-starved systems) “Open Least Used Reasonable Path First” (Fairness) Extend - don’t replace - COTS products Commercial World DoD Infrastructure DoD Sensor Field minimal protocol set Core/Interoperable Core/Interoperable Core/Interoperable GIG-unique routing algo. battery-aware routing algo. UAV flight schedule UAV flight schedule Core/Interoperable vendor-unique extension Buy commercial, specialize to military Color Legend: Commercial DTN Extension IRG DTN Network Standard Core Military DTN Extensions

  18. DieselNetInitial Deployment May 2004 • University DTN testbeds (GaTech/UMass) urban ops experiment with multipath and rapid topology change (route breakage) • Long-term 24/7 Experiment at Low Cost with Mobile nodes, sensors, and throwboxes – analogs of tactical military wireless networks – urban+rural – manned & vehicular DieselNet: routers in 40 busses in Amherst

  19. simulation time simulation time no resource management virtual infrastructure delivery rate delivery rate Factor 2-3 Increase simulation time simulation time AODV signaling overhead Factor 2-10 Reduction delivery rate Factor 5-6 Increase AODV simulation time scenario size Algorithmic Results • Knowledge management: Uniform information dissem-ination and improvement of buffer usage • Resource management: Virtual infrastructure with transport frames improves delivery rate in bottleneck scenarios • Opportunistic Routing: SCaTR framework improves delivery rate and reduces signaling overhead • Reflective Route Planning: First DTN routing algorithm based on formal reasoning technology • Flexible network simulation models with user-defined physical resource schedules

  20. DTN Progressive Maturity • Integrate Push and Pull Metaphors • Cognitive Caching • Information Addressing (not Network Addressing) • Multiple Native Networks (JTIDS, IP, EPLRS, …) • Initial Demo Board Implementation Protected, High Performance DTN for Static Applications with Store and Forward Phase 1 • Self-Organizing in Response to Network needs • Large Scale • Red/Black Management of Persistent Data Phase 1 + Protected, DTN for Medium Scale, Static Applications with Caching and Distributed Query Phase 2 Dynamically Self-Organized Organized, Secure Local Store, Application Linkages, Proven • Demo in Military Scenario to Assess Utility • Implement in Longer term, non-Military Application for Operational Experience Progressive Technology Development Resulting in Proven and Deployable Product Phase 3 • Integrate into Military Networks • Implement in Longer term non-Military Application to Acquire Experience

  21. Merging Information and Networking Policy & reasoning enable sophisticated queries over the network • “I don’t know exactly what I’m looking for, but I know how to describe it” Late binding as a way of describing information • Don’t have to know where information resides – Google as a metaphor, not an overlay • Late binding can occur in the information domain, not only the addressing domain Want to build a formal structure for persistence and networking, a structure for solving tactical problems • Analogous to akamai, but akamai is static.. In tactical networks must build our persistence architecture on the fly

  22. Adaptation to Reflect Network Dynamics DTN networks adapt to changing network topologies • Storage configures itself around paths thru the (intermittent) network • Self-forming Akamais for content distribution in response to network demands • Caching as a result of delay-bandwidth product discontinuities Military Utility – Reduce (eliminate?) burden of planning network deployment with unit deployment • Planning costs currently comparable to or greater than people and equipment costs • Network planning creates inertia/delay in deploying forces and reacting to unanticipated changes in the theatre • Avoid the Comms planning cycle!

  23. Content-based Networking Support push from core, pull from edge, and meet-in-the-middle content-based networking Steinbet: “Users will pull data as needed instead of having massive amounts of information pushed to them regularly – regardless of whether it is needed. .. a key tenet of net-centric warfare is that the consumers of information are smarter than their sources about what is needed operationally right now, and that they should be able to pull those data when they need it. Enable users to subscribe to or query useful information services, and have data returned when there’s a new event or query match Edge networks can push data up into the network Source analysis systems can query DTN storage for Wolfpack systems – enables heterogeneous sensor data fusion Distribute policies with bundles – much of the flexibility of Active Networks without as much risk .. Update rules of engagement by disseminating policies thru DTN nets

  24. Benefits of unifying networking and storage • Request information by content/type rather than by network address • “I want weather for my area” instead of “I want to ftp to 192.168.4.17” • Ability to cache rather than waste wireless bandwidth • It’s way cheaper to store data rather than to transmit it again • Integrating push-pull metaphor • Pushing sends to everyone and wastes bandwidth, can pre-place data • Pulling serves a single user, same data requested multiple times wastes bandwidth, incurs large delays delays in disrupted networks • Akamai uses static caches in a wired network to mitigate bandwidth wastage and delay • DTN Push/Pull exploits DTN in-network storage (persistent caches) and pub/sub protocols to create a dynamic and self-forming “akamai” • Temporal security • Show the data as encrypted/unencryptd

  25. Data only decrypted for access Data decrypted at end system DTN Current A New Security Model Red-black separation derives from the philosophy that the control center is protected – once in the black, info is physically safe With low-cost devices like WNaN, no longer true • How to deal with the loss of equipment at the tactical edge? • Information on this equipment is compromised with the equipment How to change the security model to deal with equipment that can’t be physically secured?? Rather than view red-black as physical separation, think temporal separation! Keep data encrypted unless the application is processing it! Encrypted data lives in local cache or edge network cache, decrypted by app Use a DTN security “convergence layer shim” for apps .. Withdraw access by app by revoking cert or similar action. DTN mechanism protects information “keyboard to eyeball” Protection from app to app, not from node to node Temporal Security Model Time

  26. Summary • Bigger Challenge! • Larger Funding! • Massive Need!

More Related