Juniper SDN Throwdown

Group 4 - CluelessKalgi Bhatt | Keyur Golani | Kunal Goswami

IntroductionProblem at a glanceIn a volatile network, among frequently failing links, get the data across the network reliably and using minimal resources.

One Statement Solution On fail or heal event of any link smartly calculate the next best path and set it as ERO.

The SolutionThe solution basically works in 4 steps:1. Monitor link failure / heal events.

2. On each event check if the existing ERO is affected.

3. If needed calculate next best path.

4. Set ERO.

No BrainerBy Default

Smart Stuff Happens Here!

Save the recently set ERO to make least REST calls

How Stuff Works?

Authenticate

One REST Call

✓

Authenticate

Topology Info

One REST CallTwo REST Calls

✓✓

Authenticate

Topology Info

Other Topology InfoGraphLatenciesPhysical Distance

One REST CallTwo REST Calls

One REST CallTwo Redis

Store Calls

✓✓

✓ ✓

Redis

Authenticate

Topology Info

Other Topology InfoGraphLatenciesPhysical Distance

Cost All paths + costs

One REST CallTwo REST Calls

One REST CallTwo Redis

Store Calls

✓✓

✓ ✓

Redis

Authenticate

Topology Info

Other Topology InfoGraphLatenciesPhysical Distance

Cost All paths + costs

All SetOne REST

CallTwo REST Calls

One REST CallTwo Redis

Store Calls

✓✓

✓ ✓

Redis

Authenticate

Topology Info

Other Topology InfoGraphLatenciesPhysical Distance

Cost All paths + costs

All SetOne REST

CallTwo REST Calls

One REST CallTwo Redis

Store Calls

✓✓

✓ ✓The previous steps can

happen once every 5 hoursOr once every 12 hoursOr even once every day

depending on the application

Redis

Redis Channel

Redis Channel

Failed / Healed

Failed Healed

Redis Channel

Failed / Healed

Failed Healed

Set “Link = Healed”

Redis Channel

Failed / Healed

Failed Healed

Find Best ERO

Set “Link = Healed”

Redis Channel

Failed / Healed

Failed Healed

Find Best ERO

Set ERO

Set “Link = Healed”

Redis Channel

Failed / Healed

Failed Healed

Find Best ERO

Set ERO

Set “Link = Healed”

Set “Link = Failed”

Redis Channel

Failed / Healed

Failed Healed

Find Best ERO

Set ERO

Set “Link = Healed”

Link Failure ++

Set “Link = Failed”

Redis Channel

Failed / Healed

Failed Healed

Find Best ERO

Set ERO

Set “Link = Healed”

Current ERO = Failed?

Set “Link = Failed”

Link Failure ++

NOYES

Redis Channel

Failed / Healed

Failed Healed

Find Best ERO

Set ERO

Set “Link = Healed”

Current ERO = Failed?

Set “Link = Failed”

Link Failure ++

NOYES

Currently Failed Links

Redis Channel

Failed / Healed

Failed Healed

Find Best ERO

Set ERO

Set “Link = Healed”

Current ERO = Failed?

Set “Link = Failed”

Link Failure ++

NOYES

Currently Failed Links

Retain Current Best ERO

Redis Channel

Failed / Healed

Failed Healed

Find Best ERO

Set ERO

Set “Link = Healed”

Current ERO = Failed?

Set “Link = Failed”

Link Failure ++

NOYES

Currently Failed Links

Retain Current Best ERO

Redis Channel

Failed / Healed

Failed Healed

Find Best ERO

Set ERO

Set “Link = Healed”

Current ERO = Failed?

Set “Link = Failed”

Link Failure ++

NOYES

Currently Failed Links

Retain Current Best ERO

Redis Channel

Failed / Healed

Failed Healed

Find Best ERO

Set ERO

Set “Link = Healed”

Current ERO = Failed?

Set “Link = Failed”

Link Failure ++

NOYES

Currently Failed Links

Retain Current Best ERO

All paths + costs

Proposed Solution - AdoptionHow easy is it to be adopted?A python script.

Runs in background.

REST calls to gather information.

REST calls to set ERO.

Generic solution.

Proposed Solution – User Experience

Different types of traffic could use different weightage to latency, distance and failure history to provide optimized delivery for given use case.

Traffic Latency Packet LossWeb Surfing ✓ ✓

Live Streaming ✗ ✓SSH ✓ ✗

Gaming ✗ ✗

Proposed Solution – Use of Technology

• Dijkstra’s algorithm to find all available paths.

• Reward / Penalty model used for link reliability calculation.

• Caching of topology info and graph for faster recalculation.

Proposed Solution - ValueBest path is calculated

• Through link monitoring• Only when needed• Based on greedy factors• Link Latency• Physical Distance

• Based on Intuitive Insights• Link Failure History• Link Reliability

Results

30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540 570 6000

500

1000

1500

2000

2500

3000

3500

4000

1014

2112

1035

1935

970

23502318

627

1402

20111841

2170

31173038

2520

996

3368

1047

2315

3125

12 10 23 11 12 20 24 34 12 10 11 50 25 9 17 12 19 55 15 4

Packet Loss Per 30 Mins

Default Network With Solution Deployed

ConclusionCould this have been better?Of course.

Why is it worth winning?An effort in the right direction. Innovative approach and potential to become a large scale generic SDN solution.