Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 28 million developers.Sign up
Download and installation instructions: http://ravel-net.org/download
- Fixed the bug that the orch app would crash when unloading all orchestrated apps.
Multiple violation views
In Ravel, an orchestration protocol mediates multiple applications whose database modifications affect each other. The protocol assumes a simple conflict resolution strategy — an ordering of view constraints where lower-ranked constraints yield to the higher ranked. For more details about the orchestration, please refer to Ravel's publication Ravel: A Database-Defined Network.
The orchestration protocol is running by a core app named orch. By default, the orch app requires that each application under orchestration should define a single violation view named as app_violation. To enable multiple violation views, insert a tuple ('app', 'violation name') into app_violation table.
All the violation views of the same application are supposed to be independent. That means repairing one violation should not introduce new entries in other violation views of the same application.
For example, suppose application test_app has two violation views name as
violation2. To enable the orch app to handle the two violation views, add the following sql sentence to test_app.sql:
INSERT INTO app_violation VALUES ('test_app', 'violation1'), ('test_app', 'violation2');
The topomanager only works in onlydb mode. It allows user to load new topology in Ravel's console without restarting Ravel (the whole environment, however, is reinitialized under the hood). To load a new topology, use command
topomanager loadtp <topology> in Ravel's console, where the parameter
topology could be any topology supported by Ravel. Please refer to the next sections for all available topology.
For example, to switch to a fat tree toplogy that has 4 pods:
ravel> load topomanager ravel> topomanager loadtp fattree,4
New topology options
Fat tree topology and ISP topology are introduced in this release.
To load a fat tree topology, pass parameter
--topo=fattree,<k> when starting Ravel, where k is the number of pods and k should be an even number. Since the number of nodes in a fat tree increases exponentially, and the Mininet in a personal computer is unlikely to be able to handle even a fat tree with a small pod number, it is suggested that the fat tree topology should be used in onlydb mode.
For example, use the following command to start Ravel in onlydb mode with a fat tree topology that has 4 pods:
$ sudo ./ravel.py --onlydb --topo=fattree,4
To load a ISP topology, pass parameter
--topo=isp, <AS number> when starting Ravel, where AS number is the identification number for the ISP. Please refer to ravel/topo/ISP_topo/stat.txt for available AS numbers. Please note that ISP topology should be used in onlydb mode, as a normal computer is unable to simulate a real word ISP topology which could have hundreds or even thousands of nodes.
For example, use the following command to start Ravel in onlydb mode with the ISP topology identified by the AS number 1221:
$ sudo ./ravel.py --onlydb --topo=isp,1221
Below is a list of all supported topology:
- Minimal topology
A minimal topology that has a single switch connected to two hosts. Use parameter
--topo=minimalto load a minimal topology.
- Single switch topology
Star structured topology with a single switch connected to k hosts. Use parameter
--topo=single,kto lad a single switch topology that has k hosts.
- Linear topology
Linear structured topology with all switches connected linearly and each switch also connected to a host. Use parameter
--topo=linear,kto load a linear topology that k switches and k hosts.
- Tree topology
Topology for a tree network with a given depth and fanout. Use parameter
--topo=tree,d,fto load a tree topology with depth = d and fanout = f.
- ISP topology
- Fat tree topology
The new release also allows user to start Ravel without specifying the topology, and load a topology later when Ravel is up using the topomanager or other apps. This option is provided for the convenient of experiment purpose, and is suggested to be used with
For example, to start Ravel without specifying topology in onlydb mode:
$ sudo ./ravel.py --onlydb