Download (DTN) Program

Disruption Tolerant Networking (DTN) Program
Phase 1
And
Phase 2/3 Program
23 March 2006
Preston Marshal, Program Manager
[email protected]
703-696-5273
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
Disruption Tolerant Networking (DTN)
Program Concept
source
disrupted areas
Disruption Closes Connection
Packet traverses net until
blocked by a disruption
Custodian-to-custodian
connections isolate
disrupted regions
destination
End-to-end
severely disrupted
by one bad link
Disruption Tolerant
When disruption clears, packet
traverses remainder of route
Packet arrives at destination.
In an IP network, packet
wouldnever have left source
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 Distribution
on network
resources
integrating
storage
Statement:
Distribution by
Limited
to DoD and DoD
Contractorsinto
Only the network
2
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
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
3
All Bandwidth is Not Equally Important
• Similar to DARPA
• Nodes can use local bandwidth to obtain DTN
services, even if not on own node
64 Kilobps Episodic
Connectivity
GIG Fiber Core
10 Gigabps Highly
Reliable Connectivity
10 Megabps Highly
Reliable Connectivity
• Highly reliable, high speed (1 Gigabit) from
servers on campus
• Several Megabits in and out to Internet
Bandwidth/Reliability
• 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
Distance
DTN Can Augment Existing
Networks without Being
Inserted into Topology
Wireless Enclaves
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
4
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
Current
Temporal Security Model
Data decrypted at end system
Data only decrypted for access
DTN
• 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
Time
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
5
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
Connected
Network
I need a
map
I need
a map
Connected
Network
need
a map
I
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
I need
a map
DTN Resolves Both Inefficiencies.. Pulls One
Time, Distributes Locally To Requestors
I need
a map
Resources Used to
Get Data
I need
a map
1st
Subsequent requests for same
data consume as much bandwidth with as much delay as
the first request.
2nd
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
3rd
···
Requests for
same data
6
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)
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
7
Demonstrated DTN v. TCP with USMC
Wireless Connectivity Patterns
Consecutive 10-KByte File Retrievals over 24 hours, using HTTP and
DTN
4000
INMARSAT
terminal
Number of File Transfers
3500
3000
2500
HTTP
DTN
2000
Cisco 2811
1500
1000
KG-250
500
29
0
27
0
25
0
23
0
21
0
19
0
17
0
15
0
13
0
11
0
90
70
50
30
10
0
DT
N
File Retrieval Time (seconds)
10 KByte File Transfers in 24 hours
4000
Abandoned 10-KByte File Transfers in 24 hours
140
user
3500
3000
120
HTTP
DTN
100
DTN
2500
EPLRS
CONDOR Gateway cable map
80
2000
3580
..
1500
60
1000
40
500
20
0
Cisco 3725
HTTP
115
368
Completed
0
0
Abandoned
Demonstrated that DTN is Useful & Feasible, and that DTN
can be Transitioned to COTS-based Military Systems
DTN Is A Deployable
Technology With
Massive Performance
Benefits for DoD
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
8
Phase 1 Go/NoGo Metric: Demonstrate DTN Network
Performance in Disrupted Network & Evaluation Platform
Hardware in the loop emulation of actual DTN nodes
• 100% Reliable Delivery with
• 80% Utilization over
• 20% Available Links
• Link characteristics
• capacity:
• delay:
• MTU:
19.2 kb/s
5 ms
1480 bytes
• Bundle traffic



Go/NoGo criterion met
for reliable delivery
DTN would have
delivered all traffic
given enough time
• 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
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
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
9
Delivered Bundles Vs. Path Distance
Run at 20% Target Availability: Random Link Dynamics
75
• Opportunistic Routing Found
Ways to Deliver All Traffic,
Regardless of Hops
• TCP (End to End) Could Not
Find Opportunities
50
• End to End requires Complete
Path be Available
Delivery Performance for DTN and TCP
100
Percent Bundels Delivered
DTN
• End to End is Fundamentally
Unsuited for Military
Operations
25
0
3
4
5
Num ber Hops
6
7
• 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
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
10
Delivery Ratio: Worst Case Dynamics
DTN versus End-to-End (E2E) Baseline
• 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
100
DTN
% Bundle Delivered
• DTN Accomplished All
Deliveries for
Availabilities Above
Go/NoGo Criteria
75
50
25
0
0
25
50
75
100
Average link Availability
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
11
Link Utilization Using DTN
• DTN Effectively Used All
Available Link Capacity
1
0.95
• Network Was So
Dynamic that End to End 0.9
Would not be Aware of
0.85
Opportunities to Use
Link Utilization
• Efficiency Decreases at 0.8
High Availability, as More
0.75
Overhead, and Early
Completion of Transfers 0.7
• Phase 2 Will Develop
0.65
Technology to Adapt and
Use both End to End and0.6
DTN Based on Which
0.55
Would be Most Effective
0.5
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
Link Availability
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
12
Trusted Delivery GNG Metric: ACHIEVED
Phase 1 Go/No Go: “Demonstrate Trusted Delivery”
• Demonstrate rejection of message from
unauthenticated sender
• Demonstrate authentication and forwarding
of message from trusted sender
• Demonstrate payload data encryption



DTN will not propagate Distributed
Denial-of-Service Attack
DTN will Detect & Reject Fraudulent
(Forged Address) Messages
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
13
Trusted Delivery GNG Metric: ACHIEVED
Demonstrate 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
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
14
Trusted Delivery GNG Metric: ACHIEVED
Demonstrate: 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 PSHsource, with destination N4 the PSH-destination for the bundle
• N4 receives the encrypted bundle from N3 (thru N2) and decrypts
the message: ACHIEVED
N1
N2
PSH-Source
DTN Enables Security Partitioning Based on Traffic
Policies Rather than Physical Topology
N3
N4
PSH-Destination
BAH: Bundle Authentication Header
PSH: Payload Security Header
Red: Cleartext
Black: Ciphertext
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
15
DTN System Architecture
Bundle Engine
Protocol
Composition API
Bundle
TBD Services
Bundle
Encryption
Bundle
Flow/Congestion Ctl.
Bundle End-to-end
Reliability
Bundle
Custody Transfer
DTN Policy/Management
“DARPA” Routing Protocol
“DTNRG” Routing Protocol
Other Routing Protocol
Autoconfiguration/
Neighbor Discovery
Environmental Awareness
API Legend
Management
API
Routing
API
Configuration
API
Environmental
Awareness API
Convergence Layer
Process Rendezvous
Plug-ins/DLLs
Single DTN Standard Will Be Extensible for Commercial or Uniquely Structured
Military Apps Such As UAV Overflight, Sensor Nets, Tactical Disruption …
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
16
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
Core/Interoperable
DoD Infrastructure
minimal protocol set
DoD Sensor Field
Core/Interoperable
GIG-unique
routing algo.
Core/Interoperable
battery-aware
routing algo.
UAV flight
schedule
UAV flight
schedule
Core/Interoperable
vendor-unique
extension
Color
Legend:
Buy commercial, specialize to military
IRG DTN Network
Standard Core
Commercial
DTN Extension
Military DTN
Extensions
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
17
DieselNet
Initial 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
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
18
Algorithmic Results
simulation time
simulation time
• Resource management: Virtual
infrastructure with transport
frames improves delivery rate
in bottleneck scenarios
• Flexible network simulation
models with user-defined
physical resource schedules
simulation time
AODV
Factor 2-10
Reduction
Factor 5-6
Increase
AODV
simulation time
delivery rate
• Reflective Route Planning:
First DTN routing algorithm
based on formal reasoning
technology
simulation time
signaling overhead
• Opportunistic Routing: SCaTR
framework improves delivery
rate and reduces signaling
overhead
virtual infrastructure
delivery rate
no resource management
delivery rate
• Knowledge management:
Uniform information dissemination and improvement of
buffer usage
scenario size
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
19
DTN Progressive Maturity
Protected, High
Performance DTN for
Static Applications with
Store and Forward
Phase 1
•
•
•
•
•
Integrate Push and Pull Metaphors
Cognitive Caching
Information Addressing (not Network Addressing)
Multiple Native Networks (JTIDS, IP, EPLRS, …)
Initial Demo Board Implementation
Phase 1 + Protected, DTN
for Medium Scale, Static
Applications with Caching
and Distributed Query
Phase 2
Progressive
Technology
Development
Resulting in Proven
and Deployable
Product
• Demo in Military Scenario to
Assess Utility
• Implement in Longer term, nonMilitary Application for
Operational Experience
• Self-Organizing in Response to
Network needs
• Large Scale
• Red/Black Management of
Persistent Data
Dynamically Self-Organized
Organized, Secure Local
Store, Application Linkages,
Proven
Phase 3
• Integrate into Military Networks
• Implement in Longer term nonMilitary Application to Acquire
Experience
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
20
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
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
21
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!
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
22
Content-based Networking
Support push from core, pull from edge, and meet-in-themiddle 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
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
23
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
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
24
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??
Current
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.
Temporal Security Model
DTN mechanism protects information “keyboard to
eyeball”
Data decrypted at end system
Protection from app to app, not from node to node
DTN
Data only decrypted for access
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
Time
25
Summary
•Bigger Challenge!
•Larger Funding!
•Massive Need!
Distribution Statement: Distribution Limited to DoD and DoD Contractors Only
26