This page is to aggregate interesting information and documentation for the T2 SDN agent, which is a proof of concept of what we could potentially do using Internet2's OESS service. The idea is to keep it simple (as there is not a lot of time available for it) but still demonstrate that inter-site traffic can be re-routed through the controller, optimizing the mesh's occupancy in different points, redirecting traffic that is overloading paths, to other paths.

Concepts

Algorithm

The agent should be based in polling cycles. It will monitor links to site A to B, C, D, E and F. Each link A <-> B will have more than one route. The agent will analyze the multiple routes and figure out if link occupancy can be optimized to reduce load in overloaded paths and increase the load in sub-utilized paths.

Paths between site A and B will at first be set by humans. The way to do it will be in a configuration file, in the INI style of Config::Simple. The agent will then poll the different paths and run the algorithm to take decisions.

Necessary parts

• Data collection mechanism
• Path usage analysis mechanism, including decision making of optimal path
• Commit decisions to OESS

Currently, the 2 first parts are implemented, example output :

[samir@darkstar sdn-agent]$ perl -Ilib t/basic.t 
1..2
ok 1 - we have an agent instance
Ok, we have a configuration file
ok 2 - it loaded the config file
For path nebraska-southern , max occupancy is 25.708445109874 Gbps
Threshold of 9.31322574615479 Gbps is exceeded on the default path
For path nebraska-central , max occupancy is 3.40954129382968 Gbps
Path nebraska-central has not exceeded the threshold and is a good option to nebraska-southern

Link usage analysis

We will assume that whatever circuit established will be bi-directional, therefore we will use this to our advantage when calculating link occupancy, so if A <-> B is :

• A -> B - 10 Gbps
• A <- B - 15 Gbps
• Link occupancy will be considered the biggest value.

Example from the testing phase :

ok 2 - it loaded the config file
in : 4880768648.32 out : 23459754131.92 Occupancy : 23459754131.92
in : 4923468309.12 out : 23343333114.4 Occupancy : 23343333114.4
in : 4923468309.12 out : 23343333114.4 Occupancy : 23343333114.4
in : 26732614349.12 out : 6674543318.08 Occupancy : 26732614349.12
in : 25724523544.64 out : 5172133386.72 Occupancy : 25724523544.64
in : 11104883426.7378 out : 5572073934.03555 Occupancy : 11104883426.7378
in : 464418907.68 out : 1221074236.24 Occupancy : 1221074236.24
in : 3608908918.24 out : 1939667358.24 Occupancy : 3608908918.24
in : 2275492791.2 out : 3712034803.36 Occupancy : 3712034803.36

Data collection

Weathermap

This weathermap shows the live status of the networks. Reverse engineering it one can find URLs that provide the data seen on the map in the XML Format.

There is a number of different nodes and it is not clear that all interfaces are "capturable". Look for the "custom.cgi" HTTP Call on the page (from JS) and you will find what appears to be all metadata of all points in the map.

Map logical link / monitoring

Caltech <-> Nebraska [1] - southern

• LOSA <-> SALT
• LOSA <-> PHOE
• PHOE <-> TUCS
• TUCS <-> ELPA
• ELPA <-> HOUS
• HOUS <-> DALLAS ?
• DALLAS <-> TULS ?
• TULS <-> KANS

Caltech <-> Nebraska [2] - central

• LOSA == SALT
• SALT == DENV
• DENV == KANS

Generic

• SALT == SEAT
• DENV == ELPA

Configuration file format

# Simply, to which Point of Presence your site (Caltech) is connected to?
site-pop = sdn-sw.losa.net.internet2.edu

# "10 Gbps"
threshold = 1073741824

[NEBRASKA]

DEFAULT = nebraska-southern

nebraska-southern = 'sdn-sw.losa.net.internet2.edu&interfaces=100GigabitEthernet3/2', 'sdn-sw.phoe.net.internet2.edu&interfaces=et-4/0/0',  'sdn-sw.phoe.net.internet2.edu&interfaces=et-4/0/0', 'sdn-sw.elpa.net.internet2.edu&interfaces=ethernet3%2F1', 'sdn-sw.houh.net.internet2.edu&interfaces=ethernet1%2F1', 'sdn-sw.kans.net.internet2.edu&interfaces=ethernet3%2F1'

nebraska-central = 'sdn-sw.losa.net.internet2.edu&interfaces=ethernet3%2F1', 'sdn-sw.denv.net.internet2.edu&interfaces=ethernet1%2F1', 'sdn-sw.denv.net.internet2.edu&interfaces=100GigabitEthernet3/2'

[WISCONSIN]

path1 = 'a','b', 'c'

PerfSONAR

It looks like PerfSONAR will help in the future as you can query traceroutes to it. In the very beginning the best is to do the routing decisions ourselves, and not have any automatic mechanism, but for the future it is interesting to note this.

Actions - OESS

Azher deployed one OESS instance. Once the previous parts are written, a possibility is to do a small demo with the local equipment, having 2 links between 2 local servers and shifting the load between the links.

-- Main.samir - 2014-08-06