The document presents a solution for reliable data transmission in networks with frequent link failures by using an event-driven approach to calculate the best path efficiently. It involves monitoring link status, evaluating the affected paths, and adjusting the established path (ERO) as needed, employing technologies like Dijkstra's algorithm and caching for optimization. The proposed solution is adaptable for various traffic types and aims to improve network performance through intelligent link management.

1. Juniper SDN Throwdown
Group 4 - Clueless
Kalgi Bhatt | Keyur Golani | Kunal Goswami

2. Introduction
Problem at a glance
In 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.

3. The Solution
The 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 Brainer
By Default
Smart Stuff
Happens Here!
Save the recently set
ERO to make least
REST calls

4. How Stuff Works?

5. Authenticate
One REST
Call
✓

6. Authenticate
Topology Info
One REST
Call
Two REST
Calls
✓
✓

7. Authenticate
Topology Info
Other Topology InfoGraphLatenciesPhysical Distance
One REST
Call
Two REST
Calls
One REST
Call
Two Redis
Store Calls
✓
✓
✓ ✓
Redis

8. Authenticate
Topology Info
Other Topology InfoGraphLatenciesPhysical Distance
Cost All paths + costs
One REST
Call
Two REST
Calls
One REST
Call
Two Redis
Store Calls
✓
✓
✓ ✓
Redis

9. Authenticate
Topology Info
Other Topology InfoGraphLatenciesPhysical Distance
Cost All paths + costs
All Set
One REST
Call
Two REST
Calls
One REST
Call
Two Redis
Store Calls
✓
✓
✓ ✓
Redis

10. Authenticate
Topology Info
Other Topology InfoGraphLatenciesPhysical Distance
Cost All paths + costs
All Set
One REST
Call
Two REST
Calls
One REST
Call
Two Redis
Store Calls
✓
✓
✓ ✓
The previous steps can happen
once every 5 hours
Or once every 12 hours
Or even once every day
depending on the application
Redis

11. Redis Channel

12. Redis Channel
Failed / Healed
Failed Healed

13. Redis Channel
Failed / Healed
Failed Healed
Set “Link = Healed”

14. Redis Channel
Failed / Healed
Failed Healed
Find Best ERO
Set “Link = Healed”

15. Redis Channel
Failed / Healed
Failed Healed
Find Best ERO
Set ERO
Set “Link = Healed”

16. Redis Channel
Failed / Healed
Failed Healed
Find Best ERO
Set ERO
Set “Link = Healed”Set “Link = Failed”

17. Redis Channel
Failed / Healed
Failed Healed
Find Best ERO
Set ERO
Set “Link = Healed”
Link Failure ++
Set “Link = Failed”

18. Redis Channel
Failed / Healed
Failed Healed
Find Best ERO
Set ERO
Set “Link = Healed”
Current ERO = Failed?
Set “Link = Failed”
Link Failure ++
NOYES

19. 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

20. 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

21. 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

22. 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

23. 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

24. Proposed Solution - Adoption
How easy is it to be adopted?
A python script.
Runs in background.
REST calls to gather information.
REST calls to set ERO.
Generic solution.

25. 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 Loss
Web Surfing ✓ ✓
Live Streaming ✗ ✓
SSH ✓ ✗
Gaming ✗ ✗

26. 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.

27. Proposed Solution - Value
Best 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

28. Results
1014
2112
1035
1935
970
2350 2318
627
1402
2011
1841
2170
3117 3038
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 40
500
1000
1500
2000
2500
3000
3500
4000
30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540 570 600
Packet Loss Per 30 Mins
Default Network With Solution Deployed

29. Conclusion
Could 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.