Participated in Juniper's SDN Automation Throwdown competition and created a dynamic module to adapt with different SDN controllers and smartly choose the right routing path based on different greedy parameters as well as intuitive parameters.
Literal Parameters:
* Link Latency
* Physical Distance
* Link Saturation
Intuitive Parameters:
* Link Failure History
* Link Down Time
* Router Port Failure History
* Router Port Down Time
Used Reward and Penalty model inspired by Reinforcement Learning model in Artificial Intelligence to determine the reliability of a link and calculate the overall reliability of the whole path.
Used Python and REST APIs in a real world environment provided in OpenLab from Juniper and developed a flexible and adaptable smart solution that could serve potentially any SDN controller in making smart routing decisions.
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
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
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
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.
