OpenDaylight Documentation
Nitrogen
This document describes, from a user’s or application’s perspective, how to use the Fabric As A Service (FaaS) feature in OpenDaylight. This document contains configuration, administration, and management sections for the FaaS feature.
Currently network applications and network administrators mostly rely on lower level interfaces such as CLI, SNMP, OVSDB, NETCONF or OpenFlow to directly configure individual device for network service provisioning. In general, those interfaces are:
To address the gap between application needs and network interface, there are a few application centric language proposed in OpenDaylight including Group Based Policy (GBP), Network Intent Composition (NIC), and NEtwork MOdeling (NEMO) trying to replace traditional southbound interface to application. Those languages are top-down abstractions and model application requirements in a more application-oriented way.
After being involved with GBP development for a while, we feel the top down model still has a quite gap between the model and the underneath network since the existing interfaces to network devices lack of abstraction makes it very hard to map high level abstractions to the physical network. Often the applications built with these low level interfaces are coupled tightly with underneath technology and make the application’s architecture monolithic, error prone and hard to maintain.
We think a bottom-up abstraction of network can simplify, reduce the gap, and make it easy to implement the application centric model. Moreover in some uses cases, an interface with network service oriented are still desired for example from network monitoring/troubleshooting perspective. That’s where the Fabric as a Service comes in.
FaaS Provides two layers API:
Through these constructs, a logical network can be described without users knowing too much details about the physical network device and technology, i.e. users’ network services is decoupled from underneath physical infrastructure. This decoupling brought the benefit that the users defined service is not locked in with any specific technology or physical devices. FaaS maps the logical network to the physical network configuration automatically which in maximum eliminates the manual provisioning work. As a result, human error is avoided and OPEX for network operators is massively reduced. Moreover migration from one technology to another is much easier to do and transparent to users’ services.
This document is focused on the top layer API. For how to use second level API operation, please refer to FaaS developer guide for more details.
Note
that for any JSON data or link not described here, please go to http://${ipaddress}:8181/apidoc/explorer/index.htm for details or clarification.
The FaaS Resource Management API provides services to allocate and reclaim the network resources provided by Fabric object. Those APIs can be accessed via RESTCONF rendered from YANG in MD-SAL.
To install FaaS, download OpenDaylight and use the Karaf console to install the following feature: odl-restconf odl-faas-all odl-groupbasedpolicy-faas (if needs to use FaaS to render GBP)
This section gives details about the configuration settings for various components in FaaS.
The FaaS configuration files for the Karaf distribution are located in distribution/karaf/target/assembly/etc/faas
Start opendaylight karaf distribution
After installing features above, users can manage Fabric resource and FaaS logical network channels from the APIDOCS explorer via RESTCONF
Go to http://${ipaddress}:8181/apidoc/explorer/index.html, sign in, and expand the FaaS panel. From there, users can execute various API calls to test their FaaS deployment such as create virtual container, create fabric, delete fabric, create/edit logical network elements.
Below are tutorials for 4 major use cases.
This tutorial walks users through the process of create a Fabric object
A set of virtual switches (OVS) have to be registered or discovered by ODL. Mininet is recommended to create a OVS network. After an OVS network is created, set up the controller IP pointing to ODL IP address in each of the OVS. From ODL, a physical topology can be viewed via ODL DLUX UI or retrieved via RESTCONF API.
The purpose of this tutorial is to allocate network resources to a tenant
This tutorial walks users through the process of create a Fabric
1 or more fabric objects have been created.
After a virtual container is created, fabric resource and appliance resource can be assigned to the container object via the following RESTConf API.
This tutorial walks users through the process of create a logical network for a tenant
a virtual container has been created and assigned to the tenant
Currently there are two ways to create a logical network.
To create a logical switch
This tutorial walks users through the process of registering an End Point to a logical device either logical switch or router. The purpose of this API is to inform the FaaS where an endpoint physically attach. The location information consists of the binding information between physical port identifier and logical port information. The logical port is indicated by the endpoint either Layer 2 attribute(MAC address) or Layer 3 attribute (IP address) and logical network ID (VLAN ID). The logical network ID is indirectly indicated the tenant ID since it is mutual exclusive resource allocated to a tenant.
The logical switch to which those end points are attached has to be created beforehand. and the identifier of the logical switch is required for the following RESTCONF calls.