-
Notifications
You must be signed in to change notification settings - Fork 1
VTN Wrapper
OpenDaylight is an open source SDN Platform that delivers inter-operable, programmable networks. One of it's components is VTN Manager, that manages the virtual network at VTN (Virtual Tenant Network) level. VTN is able to set traffic flow rules, that allow or prohibit communication, as well as redirect packets that meet a particular condition. It exposes its functionality through a northbound interface, implemented through a REST API, that allows controlling rules table and managing virtual network resources. In the scope of TANGO, we implemented a prototype of a WIM, used for managing the WAN between NFVI-PoPs, which is based on OpenDaylight VTN manager. Through VTN in fact, virtual bridges can be created upon physical SDN switches, allowing the forwarding scheme of each flow to be defined programmatically. By this means, the IA can control and configure the WAN to redirect traffic belonging to specific service instance through the needed NFVI-PoP, using the relevant WIM wrapper. The wrapper communicates with the VTN WIM via REST API. The routing complexity is delegated by the IA to the WIM itself since all the WAN topology and routing information are outside the IA scope. Therefore, the VTN WIM wrapper must only forge a request for the VTN WIM containing the details of the traffic flow to be diverted, and the ordered list of the NFVI-PoP to be traversed. Anyway, managing complex topology in such an abstract way brings interesting challenges. For example, one must provide an identifier for each PoP which is both part of the IA data model (i.e. IA generated UUID) and understandable by the WIM, which could be managed by a third actor with respect to the TANGO SP operator.
In order to control the WAN, we are using VTN Manager, a component of OpenDaylight, that allows us to manage the network using SDN technologies. With the VTN we are able to set traffic flow rules, controlling the network traffic, allowing, prohibiting or redirecting the packets that match the conditions applied. The VTN wrapper consists of a RESTful API, as well as a SQLite DB, that need to be located both in the same host PC that OpenDaylight+VTN Manager are installed. These parts, the API and the WIM_info DB compose the new TANGO custom WIM, catered to the projects needs. The RESTful API in practice, is integrated upon the already existent VTN REST API and acts as a wrapper for the IA component, combining multiple VTN functions in a single call. The WIM_info database provides information about the hardware configuration of the infrastructure owner. The owner needs an SDN switch that he will have configured and registered to be controlled by ODL+VTN.
This information can only be provided by the owner and as a result when the TANGO custom WIM is installed, the owner also has to populate the database with the required data. This data includes a particular segment of their deployment, the port id and virtual bridge name of where this segment is attached to the SDN switch, as well as an approximate physical location.
Below we list the REST API calls available and their functions:
Add a network traffic flow rule to our VTN-controlled WAN. The call is send along with information on the various pair-redirections we want our network traffic to have. The ingress and egress segments are defined, as well as the PoPs that we need the traffic to be redirected into. The WIM uses the database to find out to which physical ports of our SDN switch these segments and PoPs are allocated. Afterwards, the WIM sets, through the VTN, the redirection rules from the source to the PoPs and finally to the final destination. Finally the service or "flow", is saved locally.
uri: 5000/flowchart/
data: { "instance_id": String, "in_seg": String, "out_seg": String, "ports": [ { "port": String, "order": Integer } ] }
, ''int_seg'', ''out_seg'', as well as the ''port'' field identifying the NFVI-PoP, must be expressed in CIDR form (e.g. xxx.yyy.zzz.hhh/pp)
return: 200
Calls for a list of all the flows or services that have been set so far.
uri: 5000/flowchart/
data: null
return : { "flows": [] }
List a specific existing flow
uri: 5000/flowchart/instance_id_name
data: null
return: {"data": {"in_seg": String, "instance_id": String , "out_seg": String,
"ports": [{"order": Integer, "port": String}]}}
, ''int_seg'', ''out_seg'', as well as the ''port'' field identifying the NFVI-PoP, are expressed in CIDR form (e.g. xxx.yyy.zzz.hhh/pp)
Delete a specific flow, if it exists
uri: 5000/flowchart/instance_id_name
data : null
return : 200
Lists the locations available in the Database
uri: 5000/location/
data : null
return : { "locations": [] }