netgroup-polito / frog4-sdn-do Goto Github PK

FROG4 - SDN Domain Orchestrator submodule

Python 98.39% Shell 1.61%

domain-orchestrator openflow openflow-domain nfv sdn

frog4-sdn-do's Introduction

FROG4 SDN Domain Orchestrator

This orchestrator supervises an SDN based domain (e.g., OpenFlow devices managed by an ONOS Controller) - constituited only by several switches - and provides traffic steering capabilities between its endpoints. It always affors the possibility to insert simple NFs (such as a NAT) on the flow path (the proper bundle shuld be installed on the SDN Controller)

Traffic Steering

This domain expects to receive endpoint-to-endpoint flowules must be compliant with OpenFlow1.0.

Every flowrule must have one entry endpoint and only one output endpoint (multiple output are not supported!); a flowrule is instantiated into every switch belonging the path between the two endpoints.

Every flow is internally distinguished by a vlan id, in order to avoid ambiguities, duplicities, and other similar troubles into the involved switches.

The "Big Switch"

This domain hides the internal details (switches and the links between them), so it advertises itself as a 'big switch' with several well-defined endpoints.

In particular, as you can see in ./config/ResourceDescription.example.json, for each endpoint we can specify:

if it is enabled to be used as "entry endpoint";
all the entry vlan ids, used to match the incoming packets.

A domain administrator has to add and configure the endpoints editing the file ./config/ResourceDescription.json. The final json should be compliant against this YANG data model.

Network Functions

The SDN domain orchestrator also provide the possibility to deploy some NFs (implemented with an SDN application) between endpoints. The SDN application must allow a fine configuration in order to properly set physical interface with which interact. A supported application is this ONOS NAT bundle.

Currently just chains (endpoint to endpoint paths) with up to one NF are supported.

SDN Controllers

This project leans on a SDN controller to have some network informations and for each openflow-based operation (e.g. create and delete flow rules).

Currently, the DO supports ONOS (>= 1.5.0 "Falcon")

Support for OpenDayLight has been deprecated.

DoubleDecker and ResourceDescription.json

To advertise the features and the capabilities of this domain, we use DoubleDecker messaging systems.

In particular, the file ./config/ResourceDescription.json is published under the topic "NF-FG", both at the start of the domain orchestrator and after any database change.

Note: set the appropriate broker address in ./config/default-config.ini.

NF-FG

All the graphs sended via REST API must respect the NF-FG json schema.

Pay specifical attention to the information that are not supported by this domain orchestrator:

NF to NF links;
Remote endpoints;
"TTL" field of the endpoints;
Flowrule actions with multiple outputs, "output_to_controller" or "output_to_queue".

Note: the nf-fg library is a sub-module of this repository.

Flows priorities:

Due to default Flow rules that are deployed at the ONOS boot with a priority of 40000, if you use ONOS as controller the NFFGs to deploy must have flows with a priority greater or equal than 40001.

REST APIs

A global orchestrator should communicate through the REST APIs provided by this domain orchestrator.

REST interface provides several urls to authenticate, to send/get/delete a graph, to get the status of a graph.

In order to discover which REST calls are supported you can see the API documentation at the URL {do-address:do-port}/api_docs once the domain orchestrator is installed and running (e.g., 127.0.0.1:10000/api_docs).

Use cases

Use cases examples are in the use_cases folder. There, for each use case you can find configuration scripts, NF-FGs and more.

frog4-sdn-do's People

Stargazers

Watchers

frog4-sdn-do's Issues

Possible race condition?

According to @DavideXX92 , sometimes, when the SDN-DO tries to configure an ONOS-application just activated, it seems that the application is not yet activated.

This may be fixed by querying (to ONOS?) the status of the application before pushing the configuration.

This description is a bit generic, because no further analysis about the bug has been done so far.

No error returned when links are down

I'm trying to deploy a graph on a network consisting by two switches directly connected s1<->s2.
The switches are up, but the link between them is down.

In fact, in the log of the SDN-DO, I see the message cannot find a link between S1 and S2.
However, the SDN-DO returns 202 - Graph correctly deployed, as everything was fine.

sdn-do does not manage VLAN endpoints if they are connected to a NF

The new code allows to implement NF by exploiting onos applications. However, in the case of a path containing a NF, flow-rules instantiation are demanded to the application itself, so the old code that manages vlan endpoints at the begining/end of the path is not used.

nffg deploy error

On master
https://github.com/netgroup-polito/frog4-sdn-do/blob/master/do_core/do.py#L514
It does not require any input but it given on
https://github.com/netgroup-polito/frog4-sdn-do/blob/master/do_core/do.py#L75
https://github.com/netgroup-polito/frog4-sdn-do/blob/master/do_core/do.py#L140

Useless code in the SDN-DO

@gabrielecastellano , according to @farmanullahcs there is some code that is useless.
Can he remove this code? Of course, he works in a branch; the merge into the master will be done only after that we checked that everything still works fine.

MySQL database

Why do we need the tenant field in the database https://github.com/netgroup-polito/frog4-sdn-do/blob/master/README_INSTALL.md#create-the-sql-database ?

Is it necessary or can we remove it?

@farmanullahcs changed (alredy in the master repositories) the API, then the domain orchestrator does not receive anymore the tenant parameter.

Then I think that the database could be simplified without this field.

Change in API

The northbound API should be changed so that it is the same of the northbound API of the FROG orchestrator.

@gabrielecastellano Farman will take care of this, although it is possible that he well have some questions for you.

Documentation about priorities to be used

The documentation should say that, in the NFFG, priorities higher than 40000 must be used.

JOLNET information in the configuration file

I propose a [jolnet] section, which contains the following fields:

jolnet = false (true)
available_ids = 280-289,62,737,90-95,290-299,13-56,92,57-82

This last field is currently in the [vlan] section, which would disappear.

I think that this organization, which puts togeter all the information related to the jolnet, is more clear.

Missing update for exported resources

Currently the openflow-DO reads the local file that tells which resources are available.
However, if those resources change (e.g., a VLAN is used in an endpoint), their description is not updated and re-sent to the message broker.
This creates troubles for the upper layer orchestrator, as it cannot know which resources have already been consumed, hence some decisions may be wrong.

Missing documentation on ONOS setup

Missing documentation when using functional capabilities on ONOS where it is needed to install an additional application on the controller

Log initialization

After this commit 62f83d6 the sdn-do is not able to create and initialize a log file. I tried to move the load_configuration() method back to the config.py and it worked.

README_LAUNCH_VNF

The repository should contain a file like this one https://github.com/netgroup-polito/frog4-openstack-do/blob/master/README_LAUNCH_VNF.md (it refers to the OpenStack domain orchestrator), which describes all the steps needed to deploy a VNF in the SDN domain.

Better documentation for the config file

Specify the allowed options in the following items:
controller_name = ...
odl_version= ...

Document more the following items:

What does "oo" mean in the command "oo_console_print"? Which console are we referring to?

Rename following item:

dump_file ==> database_name

Problems in script to add users in the DB

The script expects a username, a password and a tenant ID.
The tenant ID should be a number that corresponds to a tenant already added in the Tenants table.
In my opinion, the script should expect a name as tenant. Then, if this tenant does not exist in the Tenants table, it adds it and assigns to this tenant an internal ID.

Then, I would like to use a command like
python3 -m scripts.add_user ivano-usr ivano-pwd -t myBeatiful-tenant -m [email protected]

Then it is the scripts that inserts myBeatiful-tenant in the tenants table.

This is how the add user scripts work in the OS-DO and in the FROG orcehstrator.

How to create a new user

Please, write a script to create a new user, then add the proper documentation here https://github.com/netgroup-polito/frog4-sdn-do/blob/master/README_INSTALL.md#how-to-create-new-user

northbound API

The northbound API should use POST for the creation of a graph, PUT for the update

Debug and detached mode

Modify config file as follow:
log_level= [SET OF LEVELS THAT CAN BE USED to log things; such as "debug", "info", "warning"]
detached_mode= true/false [if true, REST commands are printed on screen and are not actually passed down to the underlying orchestrator]

In the JOLNET it must be false, while on a mininet setup it must be true.