We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.I2ND.NetIC - FIWARE Forge Wiki

FIWARE.OpenSpecification.I2ND.NetIC

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.I2ND.NetIC
Chapter I2ND,
Catalogue-Link to Implementation OFNIC
Owner UNIROMA1,

Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE project.

Copyright

Copyright © 2015 UNIVERSITA' DEGLI STUDI DI ROMA "LA SAPIENZA".

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.

Overview

Network Information and Control (NetIC) is intended to provide abstract access to heterogeneous open networking devices. It exposes network status information and it enables a certain level of programmability within the network (depending on the type of network and the applicable control interface). This programmability may also enable network virtualization, i.e., the abstraction of the physical network resources as well as their control by a virtual network provider. Potential users of NetIC interfaces include network service providers or other components of FIWARE, such as cloud hosting. Network operators, virtual network operators and service providers may access (within the constraints defined by their contracts with the open network infrastructure owners) the open networks to both retrieve information and statistics (e.g. about network utilization) and also to set control policies and optimally exploit the network capabilities.

Target Usage

The Network Information and Control (NetIC) Generic Enabler provides to FIWARE chapters as well as usage area applications and services the means to optimally exploit the network capabilities via a dedicated interface and API. NetIC exposes related network state information to the user of the interface as well as offers a defined level of control and management of the network.
The beneficiaries of the interface include content providers, cloud hosting providers, context providers/brokers, and (virtual) network providers/operators, all of whom may need to understand and manipulate the network between them and their clients. They might want to set up flows/virtual networks to their clients and they may want to control such flows/virtual networks in order to respect pre-defined Service Level Agreements (SLAs), for example in terms of provided Quality of Service (QoS).
A fundamental challenge for the implementation of NetIC is that the network functionality is typically distributed over different elements potentially implemented internally in different ways (in multi-vendor environments). Also, the interfaces have to take into account the constraints of different providers (in multi-network service scenarios) as well as legal and regulatory requirements. These problems have been solved in the past by different standardized control plane solutions. This readily available functionality could be re-used by NetIC in order to provide a smooth evolution path rather than introduce a disruptive revolution. NetIC instances may be deployed by the different involved parties (e.g. virtual network providers/creators, and virtual network operators/users running a business on top).
As a consequence, several instances of NetIC with different scopes may have to work together to deal with a request from e.g. a service provider or an application. Each might cover a different part of the network, for instance in the horizontal direction (i.e., type of access, there might be TV cable networks, (V)DSL networks or even local radio networks) or in the vertical direction (i.e., ownership or virtual network structures, there might be several local networks which are integrated by an country-wide service provider).
It should be noted that the capabilities a specific NetIC implementation can offer depend on the capabilities of the underlying network.

Basic Concepts

The NetIC GE provides to users and applications/services the means to optimally exploit the network capabilities via a dedicated interface and APIs. NetIC interface exposes related network state information to the user of the interface as well as offers a defined level of control and management of the network.

Northbound Interface

The northbound interface is intended to expose network status information and to enable a certain level of programmability within the network (depending on the type of network and the applicable control interface). This programmability also enable network virtualization, i.e., the abstraction of the physical network resources as well as their control by a user or application. Depending on the purpose (e.g. only information provision or control of network) the interface will have different characteristics. It should be noted that the exposition of specific capabilities via the northbound interface depends on the capabilities and the technology of the underlying network.

Generic Architecture

The block diagram below shows the main functional modules of NetIC GE. The following sections give a brief overview on the functional modules and their interfaces.

Figure 1: NetIC GE Functional Block Diagram


NetIC API

The NetIC API is the conceptual northbound interface of the NetIC GE. It exposes the internal module interfaces to the outside world such that applications, or other GEs, can access the modules that are present in the specific NetIC instantiation.

A Reference Implementation of the NetIC GE is able to fulfill requests coming from the users of the NetIC API. In particular it is able to accomplish the following types of requests (using the mechanisms provided by the network frontend protocol):

  • Synchronize - used to retrieve available network resources.
  • Create - used to create a virtual resource based on physical or virtual network resources.
  • Destroy - allows the deletion of the virtual resources already created.
  • Monitor - provides information about current status and utilization of a given network resource.

API handler

The API handler has the role to map NetIC API commands into the OpenFlow Network Module. To this aim, it exposes a RESTful web service to the NetIC API side. NetIC commands received on the HTTP interface, are sent to specific sub-modules that effectively implement the required NetIC functionalities (synchronize, monitor, create, destroy).

Core

This module directly provides to OpenFlow Network Module components an API to exchange OpenFlow messages with the network. It also implements core features such as, network discovery, host tracker, flow programmer and statistics.

Network Controller

This module fulfils requests of creation and deletion of virtual path resources. In particular, it is able to install virtual paths between any two nodes of the network with certain bandwidth requirements. To achieve routing functionalities, this sub-module needs to be aware of the network topology, and the load of the links as well. The topology information is accessed directly from the Network Information sub-module.

Qos/QoE Controller

This module has the objective to assure the satisfaction of a certain level of personalized Quality of Experience/Service (QoE/QoS) requirements (required by the users/applications) by means of suitable dynamic resource management mechanism, such as bandwidth management and queuing.

Statistics

This module exposes monitoring functionalities. In particular it is able to estimate the level of link utilization of OpenFlow switches in the network. The link load sub-module relies on OpenFlow protocol to retrieves statistics (e.g. sent/transmitted bytes/packets). The nodes are queried by means of the functionalities provided by the core sub-module, which retrieves statistics counters of the OpenFlow switches. Information about all available nodes and the links interconnecting them is retrieved from the Network Information sub-module. The collected statistics can be accessed by the API handler when monitoring requests are received from the NetIC API layer, and is also accessed by the other sub-modules, in order to exploit statistics and monitoring data.

Network Information

This module exposes synchronization functionality. The topology discovery sub-module is in charge of discovering network links and nodes. Network entities without forwarding capabilities, (e.g. border hosts) might announce their presence in the network by periodically sending LLDP messages.

Network Frontend

The Network Frontend is the network-specific and technology-specific representation of the network interfaces accessed by the functional modules. In the considered scenario it consist in an OpenFlow-enabled Software Defined Network.

Main Interactions

Users can access the functions of NetIC by a message-based interface (request/response, REST based) that is provided by an information and control entity instance responsible for a particular network. This interface flavor will be used for detailed information gathering about network internals (like node/port status, link load, etc.) and control of network elements (e.g. activate or deactivate nodes/ports, setting up routing information). This interface is currently envisaged for NetIC implementations implementing the Virtual Network Provider, the Network Element Virtualizer or the OpenFlow Network Module.

Message-based Interface

The Message-based Interface is well-suited when accessing a controller of a well-defined network. It can expose status information from the underlying network and it enables a certain level of programmability of the underlying network. The interface is usually not directly used by applications serving end user needs but by applications acting as virtual network operators. As a consequence, only a quite limited number of users will interface to a given network at the same time. The interface permits the utilization of the network resources as services. The network physical resources are abstracted into Uniform Resource Identifiers, according to a defined hierarchy. Moreover the operations exposed by the interface permit the manipulation of such resources with the common commands defined by the RESTful paradigm based on HTTP such as GET, POST, DELETE, and PUT. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server does not send its database, but rather JSON formatted records of information. Each request sent to the Message-based Interface is self-descriptive, i.e. it contains all the information needed to process the message. The main functionalities offered by the Message-based Interface are the following:

  • Synchronization: It is used to retrieve the available network resources and also information about their configuration. The users of the interface can synchronize both physical and virtual resources. Typical HTTP verb used is GET(URI).
  • Provisioning: Allows the configuration of network resources. The configuration might comprise physical or virtual resources of the network. The corresponding HTTP verb is POST(URI,Metadata).
  • Monitoring: Allows the retrieval of monitoring information collected from the network regarding failures and performance statistics. The requested information might be gathered in near real time from the network, stored in a cache inside the controller and provided at the instant of the request. Typical HTTP verb used is GET(URI).
  • Release: Allows the release of already configured network resources, bringing them back to their default configuration. The HTTP verb utilized in these type of commands is POST(URI).
  • Create: Allows creation of virtual network resources based upon existing physical or virtual resources. Generally the URI of the new resources is decided by the server, so the HTTP verb utilized is POST(URI,Metadata). The HTTP response, upon successful creation, shall contain the URI of the created virtual resource. The virtual resources created might be further manipulated and configured with provision commands. Typical virtual resources might be new virtual paths or monitoring tasks.
  • Destroy: Allows destruction of virtual network resources. The HTTP verb adopted for these group of commands is DELETE(URI).

Applying the REST paradigm (which uses a stateless representational format) it is very difficult to implement callback events in a natural way. As a consequence, in this release the NetIC instantiations handle events via information polling. This fact does not limit the functionalities of the NetIC GE, it only shifts the callback difficulty to the client application. Other alternatives like ATOM Publishing Protocol (http://www.ietf.org/rfc/rfc5023.txt) or RSS (http://www.rssboard.org, http://www.rssboard.org/rss-specification) might be for further study in later releases. For the current release of FIWARE, NetIC will not provide a javascript library to ease potential users to access the API. Instead, certain NetIC GE instantiations (Openflow Network Module) will offer a web based GUI developed in javascript to enable users to ‘browse’ the web services offered by the related NetIC GE instantiation.

Network Information

The commands sent through the message-based interface can trigger actions that need only processing inside the NetIC sub-modules if the information requested is available locally. The diagram below depicts a sequence of messages in case of a request that needs only local information to be processed. This type of request generally concerns synchronize messages about available network resources and also monitoring commands about network statistics, which are typically stored in local caches and updated periodically. By doing so, the commands that require reading resources are processed rapidly by the NetIC instance and the responses are sent faster.

Network Information Processing Flow Diagram

Network Control

Network control functionalities trigger functions that require further exchange of messages with the managed network. The next diagram depicts a sequence of messages that involves not only NetIC local sub-modules but also messages exchange with network entities. From the diagram one can note that the network entities involved might be one or several. These interactions are typically generated by provision, release, create, and destroy commands. Depending on the number of entities involved, the rate of the communication channel with network entities and the extension of the network, these type of commands can be time consuming.

Network Control Processing Flow Diagram

Basic Design Principles

Implementations of the NetIC GE have to comply to the following basic design principles:

  • The interface provided by the Generic Enabler shall be technology and implementation independent.
  • All the provided interface have to provide defined and documented APIs.
  • As the system grows (in control traffic volume), there should be reasonable way of dealing.
  • The system needs to have a reliable and consistent behaviour.
  • The system needs to be constantly available because the uptime is a critical factor.

Rationale

The NetIC Generic Enabler will provide access to network status information to its users. Interfaces available today are already able to provide specific information, but the interface highly depends on the specific network technology. The aim of NetIC is to define a set of general functions to access network status information in a technology independent way, overcoming the heterogeneity of today’s solutions. As the NetIC API is not intended to be directly accessed by end users (for obvious security reasons, it is very unlikely that network infrastructure providers will allow end users direct access to even abstracted network resources) but for access by virtual or real network operators or service providers.

Detailed Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during final interactions of the development of a first reference implementation planned for the current Major Release of FIWARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FIWARE but they are provided for the sake of future users.

Open API Specifications

   The NetIC Open API specifications are defined at the following page:      

Re-utilised Technologies/Specifications

The message-based interface of the NetIC GE is based on RESTful Design Principles. The related technologies and specifications are:

  • RESTful web services;
  • HTTP/1.1;
  • JSON data serialization format.

Some NetIC implementations exploit the capabilities of OpenFlow:

  • OpenFlow is an open interface for remotely controlling the forwarding tables in network switches, routers, and access points. Based on this low-level interface researchers or other users can design, build and test custom networks and algorithms with innovative high level properties. For example OpenFlow enables development and testing of algorithms for energy-efficient networks, optimized resource management, new wide-area networks, etc.
  • Specifications and other informative documents such as a White Paper can be found here

Terms and definitions

Personal tools
Create a book