Concepts

Algorithm

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

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

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

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'

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

Configuration file format

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

[NEBRASKA]

path1 = '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'

path2 = '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'

Currently Internet2 has a mesh with points of presence all over the US. Clients can control what their paths are to destinations through a remote API named OESS. However, before any action through the API it is important to collect information and analyze the data according to a favorable algorithm to take decisions to ensure optimal and distributed usage of the network.

The goal in this page is to document the high level requirements for this to happen.

It might happen that a proof-of-concept agent is written in Perl, but the end goal is that the OpenFlow controllers such as OLiMPS accomplish that.

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

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.

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, A <-> C 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.

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