NETWORK-CENTRIC APPLICATIONS AND TACTICAL NETWORKS

21
NETWORK-CENTRIC APPLICATIONS AND TACTICAL NETWORKS Mr. Timothy Krout Vice President Engineering, CenGen Inc. 5356 High Tor Hill Columbia, MD 21045 [email protected] (410) 715 1300 Mr. Steven Durbano Sr. Network Engineer, CenGen Inc. [email protected] Ms. Ruth Shearer Enabling Capability Manager, Littoral Combat & Power Projection Future Naval Capability Office of Naval Research Ballston Center Tower 3, Suite 623 Arlington, VA 22217 [email protected] (703) 696-1358 Wayne Mandak Sr. Engineer CenGen Inc. [email protected] 410 715 1300 8th International Command and Control Research and Technology Symposium 17-19 June 2003 Washington, DC

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

02/24/2000WaveLAN TestingRacetrackBot 4 Patch, 9,000 ft, 62M

Figure 5

Figure 6

Ramp, 1000 byte Pkts, Air 20 nm, Partial Build, 62-500 Pkts/sec

Figure 7

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