Tb2948 kabel architecting applications centric networks with f5_final
NETWORK-CENTRIC APPLICATIONS AND TACTICAL NETWORKS
Transcript of NETWORK-CENTRIC APPLICATIONS AND TACTICAL NETWORKS
NETWORK-CENTRIC APPLICATIONSAND TACTICAL NETWORKS
Mr. Timothy KroutVice President Engineering, CenGen Inc.5356 High Tor HillColumbia, MD [email protected](410) 715 1300
Mr. Steven DurbanoSr. Network Engineer,CenGen [email protected]
Ms. Ruth ShearerEnabling Capability Manager,Littoral Combat & Power
Projection Future Naval CapabilityOffice of Naval ResearchBallston Center Tower 3, Suite 623Arlington, VA [email protected](703) 696-1358
Wayne MandakSr. EngineerCenGen [email protected] 715 1300
8th International Command and Control Research and Technology Symposium17-19 June 2003Washington, DC
Tactical Networks
• If you have ever worked with Tactical networks– Quickly realize
• Do not match wired networks in– Throughput– Reliability / packet delivery (loss) / connectivity– Are highly mobile
– They are the mainstay of warfighter connectivity• Recent experience shows the benefits, and cost, of having (or
not having) reliable tactical networks– Knowing where your friends are is very important in fast paced
hostile environments» Prevents you from being fired on, allow you to fire / react
more quickly
• Nearly unimaginable we would consider a fast paced large or medium scale military action without the deployment of tactical data networks– They are, to an every increasing degree, becoming a
critical part of modern warfare
Tactical Networks
• Mostly discussing mobile networks used by warfighters on the pointy end of the spear– Wireless, mobile, ad hoc, often air borne relay
based, on-the-move, over-the-horizon• Not discussing Command Post large scale
SATCOM type configurations– If it arrives on 10s of trucks and takes days to
establish, it doesn’t meet the threshold for this discussion
Tactical C2 Apps• Are the critical component that bring functionality to the
applications– No one cares about communications without C2– However, you can’t “command and control” without
communications• At user (warfighter) level these systems have always been
linked• GCCS, C2PC, FBCB2, AFADTS
– Well know “C2” applications in “common” use by warfighters• All used in Iraq Freedom
– None define a communication path– All are intended to operate over “network of opportunity”
• In many cases, they simply don’t– Or at least have lots of room for improvement
Network & Applications
• System approach – combination of Apps and network is the “problem”– To date we (developers of apps and networks) have
done poor job of recognizing and adapting to limitations of the other
– Result has been rather marginal performance of these systems
• Rarely do warfighters believe C2 systems meet their requirements
• Even when they believe C2 systems meets requirements – they “blame” comms system for poor performance and resultant poor C2
Network & Applications
• “We” must advance the current state of the art• Next big strides will be made when application
developers accept and compensate for “deficiencies” in tactical comms
• Tactical comms will improve, but – They will never be ubiquitous
• There will be total comms outages and sometime they will last for minutes or 10s minutes
– They will never have enough throughput– They will never have packet delivery approaching wired
networks
Network & Applications
• Tactical networks currently have and will (likely) evolve to support– Packet loss on the order of 20-40%
• Over a several minute average– Throughput on the order of 10s Kbps to/from each
“major” node• Some key nodes will be higher, perhaps much higher, but C2
apps should be designed for the lower end, not the extremes – Total comms outages from few minutes to 10s minutes
pretty “routinely”– Be very heterogeneous in nature
• Don’t try to model any one radio / network approach it isn’t necessary
• Instead, focus on basic “services” network provides – Build C2 applications tolerant of the services that can be provided
We Are Comms Guys
• Realize some in comms community disagree with our summary performance assessment, however
• We have lots of data to suggest we are “reasonably” accurate
• See no major “break through” in technology that will substantially change them
• Believe them reasonable enough to encourage their use by application developers– Guarantee they are much closer to reality (past,
present, future) then developing on a wired Ethernet
ELB ACTD Architecture
Multicast VRC-99 / NTDR Subnet
Multicast VRC-99 / NTDR Subnet
High Data-Rate Backbone(TCDL)
High Data-Rate Backbone(TCDL)
Multicast VRC-99 /NTDR Subnet
Multicast VRC-99 /NTDR Subnet
LPD / LPI /LPD / LPI /
TCDL
(2)
(100)
ArmyInteroperability
San Onofre
UOCSUV
HMMWV-MCH46-D
Coronado
HMMWV-A
NFN
SUV
(2)EUT
EUT Collector
Demo Control(MCTSSA)
Figure 1
ELB ACTD Technical ArchitectureJOA 200nm x 100nm
Coronado
Ship
Ship Ship
CV
HeloA/c
A/c
CV
CV CV
CV
CVCV
CV
CV Tier 1 – Wavelan“subnet”
Tier 2 – VRC-99NTDR
Tier 2 “subnet”
Tier 3 – TCDL(pt. pt. link)
•Seamlessly interconnected via Routers
•All nodes highly mobile•Network dynamically reconfigures in
real-time
A/c
10-80nm
10-50nm
10-30nm
10-30nm
10-30nm
<15nm
Figure 2
June 19, SYSCON truck to 79N
15:00:00 18:00:00 21:00:00 00:00:000
5
10
15
20
25
Time
Ran
ge (n
mi)
15:00:00 18:00:00 21:00:00 00:00:000
20
40
60
80
100
Pkt
Los
s R
ate
(%)
15:00:00 18:00:00 21:00:00 00:00:000
72
144
216
288
360
Time
Bear
ing
(deg
rees
)
Bearing
15:00:00 18:00:00 21:00:00 00:00:000
20
40
60
80
100
Pkt
Los
s R
ate
(%)
Packet Loss (%)
Range (nm)
Packet Loss (%)
Bearing (deg)
0800 1100 1400 1700Time
0800 1100 1400 1700Time
Overall packet loss 27%. Figure 3
JUNE 21, 62M to the SIL
15:00:00 18:00:00 21:00:0030
40
50
Time
Ran
ge (n
mi)
15:00:00 18:00:00 21:00:000
20
40
60
80
100
Pkt
Los
s R
ate
(%)
15:00:00 18:00:00 21:00:000
72
144
216
288
360
Time
Bear
ing
(deg
rees
)
Bearing
15:00:00 18:00:00 21:00:000
20
40
60
80
100
Pkt
Los
s R
ate
(%)
Packet Loss (%)
Range (nm)
Packet Loss (%)
Bearing (deg)
0800 1100 1400Time
0800 1100 1400Time
overall packet loss 13%Figure 4
Numerous Results
• Numerous demonstrations / test support basic network performance numbers
• Army / DARPA Future Combat System Lead System Integrator Scalable Mobile Network– Winter 2003– New Jersey
• Ongoing testing by ONR (LC FNC) at MCTSSA
• Data in paper
Recommendations
• Build applications on networks “comparable” to tactical networks
• Use simulators all the time in application labs• Remain aware of “trends” in tactical networking that could
change the “guidance”• Do not attempt to account for every minor nuisance in radio
/ network performance– Build to the general performance characteristics of a
heterogeneous network– NOT to the specifics of any one approach
• Radio / networks and applications should develop utilization abstraction
• Expect radio / network protocol to change and evolve• Should not adversely impact applications
– If it does it was a poorly designed application
ELB Application Test Network
Bldg 40
SharenetServer
SLL-SNOIS172.20.144.132
SD
Cisco 1720
BRIS/T
CONSOLE
AUXWIC 0 OK
OK
B2B1
WIC 1 OK
DSUCPU
LNK100FDX
S3
LOOP
LP
LFOCRouter
SD
OK1
OK2
PS1
PS2TEMP
100/15,230v~20/30Hz, 8.0/1.75 A
BANK11x 2x 3x 4x
5x 6x 7x 8x
BANK21x 2x 3x 4x
5x 6x 7x 8x
1
5
2
6
3
7
4
8
BANK21
5
2
6
3
7
4
8
BANK1
CONSOLE Packeteer172.20.144.148
SD
1100CAT5MODULARJACKPANEL
Lucent
1 2 3 4
25 26 27 28
5 6
29 30
7 8 9 10
31 32 33 34
11 12
35 36
13 14 15 16
37 38 39 40
17 18
41 42
19 20 21 22
43 44 45 46
23 24
47 48
Hub
SD
1100CAT5MODULARJACKPANEL
Lucent
1 2 3 4
25 26 27 28
5 6
29 30
7 8 9 10
31 32 33 34
11 12
35 36
13 14 15 16
37 38 39 40
17 18
41 42
19 20 21 22
43 44 45 46
23 24
47 48
Hub
HP OpenviewSniffer Pro Network StatusPanel
Sniffer Pro172.20.129.22
Sniffer Pro172.20.144.138
SLL-LAWS172.20.144.140
SLL-SNSERV172.20.144.135
SLL-AGENTS172.20.144.137
172.10.65.1
172.10.144.129 172.10.129.15
SD
Catalyst8500
Power Supply 0CISCO YSTEMSS Power Supply 1
SwitchProcessor
SERIES
Cisco 5505
SLL-MCSIT172.20.144.135
Network StatusPanel
172.20.129.26
Win2000Cloud
Two Clouds Running in Parallel
Win2000Cloud
Router
MCTSSA
SD
1100CAT5MODULARJACKPANEL
Lucent
1 2 3 4
25 26 27 28
5 6
29 30
7 8 9 10
31 32 33 34
11 12
35 36
13 14 15 16
37 38 39 40
17 18
41 42
19 20 21 22
43 44 45 46
23 24
47 48
Hub
HP OpenviewSniffer Pro Network StatusPanel
AP
EUT EUT
AP
EUT EUT
SD
Cisco 1720
BRIS/T
CONSOLE
AUXWIC 0 OK
OK
B2B1
WIC 1 OK
DSUCPU
LNK100FDX
S3
LOOP
LP
CV NodeRouter
Figure 8
ELB (and other)
• To large extent single biggest contributing factor to success of ELB was “forcing” application developers to develop / test using network simulators
• Application developers rarely had access to “real” network– Proved not to be a limiting factor– Was not needed – simulators proved to be
wholly adequate and allowed applications and network to develop in parallel
ELB (and other) Settings
Cloud Settings
10% loss30% loss20% lossPacket Loss – Random Loss
Avg. Freq of occurrence = 10 minRange of disconnect time = 5 sec –
20 sec
Avg. Freq of occurrence = 10 minRange of disconnect time = 30 sec –
5 min
Avg. Freq of occurrence = 10 minRange of disconnect time = 20 sec
- 1 min
Link Fault – Network Disconnection
10E-710E-710E-7Link Fault – BER
Avg = 1000 msecStd Dev = +- 50 msec
Avg = 2000 msecStd Dev = +- 1000 msec
Avg = 1000 msecStd Dev = +- 50 msec
Latency – normal distribution (end-to-end)
240 kbps80 kbps80 kbpsBandwidth Limit – end-to-end (across Simulator, no limits on AP to EUT connection)
GoalWorst CaseBaselineCloud Parameter
Figure 9
Summary
• Warfighter advances require the closer connection of C2 and comms for next big advance
• Don’t develop for or in “perfect” comms environment– Comms guys can not now nor ever be able to deliver it
• Develop using network performance specs, not particular radio / network types
• Data does exist to help develop a reasonable set of performance metrics to develop too