NfV PoCs - Use Cases, Architecture Function Blocks and Reference Points.

Under the aegis of ETSI, an initiative of developing Proof of Concepts (PoCs) was started to "build industrial awareness and confidence in NFV". These demonstrations of Proof of concepts  help in verifying that the NfV concepts have the potential for real-world applications. The details can be found here.

In this blog, we do not cover the details of PoCs (Hopefully in a separate blog). However, we summarize the proposed PoCs (around 24) with respect to the the following:
1. Proposed Used-Cases
2. NfV Architecture Functional Blocs
3. NfV Architecture Reference Points.

The details of (1) can be found here, whereas the details of (2) and (3) can be found here.
For quicker-reference, we enlist the three below:

 In the below table, on Y-Axis the PoCs are enlisted, whereas the x-axis has Use-Cases (UC#), Functional Blocks (FB#) and Reference Points (RP#) .

The Plots highlighting the PoC coverage with respect to the above three concepts are shown below:

Northbound application development in SDN controllers - An APIs and SDK Perspective

SDN is the one of the emerging networking technology which has gained lot of popularity in networking domain.

SDN is the software defined networking which is trying to create/manage network through software. SDN is trying to centralize brain of network into controller applications (i.e. SDN controllers).

Even SDN makes you virtualize all the network and their networking functions through Network virtualization and Network function virtualization techniques.

SDN controller, being brain of network, manages the network switches/routers by sending intelligent rules on them through southbound APIs and allows vendor-specific/domain-specific/function-specific applications to run over with SDN controller via northbound APIs.

There are lot many networking vendors who are working on SDN at fast rate and launching their SDN controller in market.

But, SDN is not getting adopted at fast rate among network operators, service providers, network application developers, etc. To accelerate this adoption, vendors of SDN controller are exposing northbound API set to create development environment among networking community so that more and more application can be developed over such SDN controller and more use-cases of SDN can be opened up.

Few vendors have shared their SDN SDK also for rapid development of applications over their SDN controllers to gain their strong existence and popularity in SDN world.

In this blog, focus has been on research of SDKs for SDN. Research on which SDN controller vendor share SDK, what SDN SDK should contain what networking use-cases/functions can be achieved by SDN SDK.

Below is the list of SDN controllers which are researched for finding their support for APIs/SDK.

SDN Controllers	Does it support Openflow?	Does it expose Northbound APIs?	Does it share any SDK?	Is SDK Open?	Language Used for APIs/SDK
HP VAN Controller	Yes	Yes	Yes. HP SDN DeveloperKit	Open	REST and Java
Juniper Contrail	No	Yes	Yes. Junos Space SDK	Open	REST
Big Switch	Yes	Yes	No	NA	REST
Floodlight	Yes	Yes	No. But, Provides many applications in java modules	NA	REST
Ryu	Yes	Yes	No. But, It provides framework to develop SDN apps.	NA	Python
IBM Programmable Flow	Yes	Yes	No	NA	REST
NCL - Hinemos and VNC	Yes	Yes	No	NA	JAVA
Cisco APIC	Yes	Yes	No	NA	REST
Cisco XNC	Yes	Yes	Yes. Cisco Open Network Environment Platform Kit	Open	JAVA/REST
Nicira/VmWare NVP	Yes	Yes	Yes	Open	REST
Nuage VSC	Yes	Yes	No	NA	REST
Plexxi Control	No	It has 2 different API: Workload Affinity API, Network Orchestration API	No	NA	REST
Sanctum's Jupiter	Yes	No information	Yes	Closed	No information
PLVision kuFlow	Yes	It is openflow driver for SDN controllers and it is available as library.	No	NA	Python, C++
Sandvine SDE		No, But it gives you PCRF GUI to design services	No	NA	NA
Active Broadband Network's BNG	Yes	Yes. It provides web services API and message queues	No	NA	No information
NetSocket vFlow	No	Yes	No	NA	No information
Metaswitch Perimeta SBC	No	Yes	No	NA	No information
Italtel SBC	No	No	No	NA	NA

Next table talks about what should SDN SDK contain and whether these SDK contents are available in existing SDN SDKs.

SDK Contents	HP VAN SDK	Junos Space SDK	Cisco XNC OnePK SDK
GUI CLI	SDN Controller Console which is web based GUI.	Yes, provide GUI plugin for Eclipse IDE	Provides API set only.
Templates	Yes	Provides REST APIs for Config Template Management	No
Schema files (WSDL, XSD)	Supports XSD schema files	Supports generation of schema (XSD) from DTO definitions using ANT scripts.	No
Sample programs	Yes, it provides some built-in apps: Device Node Manager, Link Discovery, Topology Manager, Topology viewer, Path daemon, Path daignostics	Yes. For example, HelloSpace, WorldCities, oogleMashupApp	Yes. For example, HelloElement, HelloNetwork, SyslogMonitor
Higher order models	Yes. SDK provides models and works on MVC (Model-view-controller) architecture to develop applications.	Supports 3 application models: 1) Complete Junos Space Application. This application model contains all 3: UI + web services + business logic. 2) Web Service Junos Space Application. This application model contains: web services + business logic. 3) UI Only Junos Space Application. This application model contains only: UI app. Business logic is realized by EJB packages (i.e. server side components).	No
API Libraries	Yes. The Controller REST API is distributed across 3 distinct namespaces: (1) core (/sdn/v2.0), (2) openflow (/sdn/v2.0/of), (3) network services (/sdn/v2.0/net). Each namespace has its own JSON schema. (1) Core namespace: The core APIs provide general manageability of the controller, such as configuration, health monitoring, teaming, alerts, audit logs, support logs, etc. (2) Openflow namespace: The openflow APIs provide Openflow functionalities of the controller, including both read-only operations (such as port statistics) and modification operations (such as flowmod). The same REST API can be used on both Openflow 1.0 and Openflow 1.3 devices. However, only certain APIs (such as meters) are available when speaking to an Openflow 1.3 device, because the functionality is only available for Openflow 1.3 devices. (3) Network services namespace: The network services APIs provide basic network knowledge such as network topology information and network diagnostics.	Yes. It provides REST APIs for below services: Application Management, Audit Log Management, Configuration File Management, Configuration Management, Configuration Template Management, Debug Log Management, Device Image Management, Device Management, Fault and Performance, Info Service, Inventory Management, Job Management, Script Management, Tag Management, User Management, Well Known Service	Yes. It has various services: 1) Policy service set: allows applications to configure several features of the forwarding path, including filtering, ACLs, and QoS. 2) Routing service set: provides read access to the routing information base (RIB) and enables a developer to safely modify the routing/switching logic of the network element. 3) Element service set: consists of APIs to get and set network device and interface properties, state, and statistics. 4) discovery service set provides a mechanism for an application to discover remote or local network elements, network topology, and the network elements providing onePK services.
Binaries: installation and configuration	Yes. Configuration is done through metatype.xml and maven's pom/xml	Yes. This SDK is available as installer and provides various APIs for configuration management.	Yes
Emulator/Simulator for test and validation	Yes	Simulators, virtual machine included with the developer environment.	No
Quick start and programming guide	Yes. It provides following guides: HP VAN SDN Controller License Registration and Activation Guide, HP VAN SDN Controller Installation Guide, HP VAN SDN Controller Administrator Guide, HP VAN SDN Controller Programmer's Guide, HP VAN SDN Controller REST APIs, HP VAN SDN Controller Release Notes, HP VAN SDN Controller Open Source and Third-Party Software License Agreements	Yes. It provides: Junos Space SDK Release Notes, Junos Space API Reference Guide, Junos Space Application Developer Guide, Device Simulator Guide, Junos Space SDK Installation Guide for Windows/Linux/Mac	Yes
Authentication	Yes. HP VAN SDN controller REST APIs are secured via token based authentication scheme. Openstack keystone is used to provide token based authentication.	It is not at API level. It is at user level. Because Junos Space implements a single sign-on authentication scheme, the user name and password credentials you use to log into Junos Space also validate your use of OpenNMS. No separate authentication is needed.	Yes. It uses TLS protocol to authenticate application before accessing cisco network element and also need Cisco network element to enable OnePK and TLS before any communication with apps.
Backup and restore	Yes. A controller backup takes a snapshot of the controller state, and includes the following in a single file: Controller databases, License compliance history and metrics log data, In a teaming environment, the teaming configuration, User repository folder (for user-installed applications), Controller configuration folder	No	No
Logging support	Yes. Audit log and support logs are provided.	Yes. It provides REST APIs for audit and debug log mangement.	Yes

Next table talks about what should be use-cases which can be achieved using SDN SDK and whether these networking functions support is available in existing SDN SDKs.

SDK Categories	HP VAN SDK	Junos Space SDK	Cisco XNC OnePK SDK
Network Virtualization	This is done by the controller itself.	Yes	No. Not yet supported.
Appliance virtualization	Yes	Yes	Yes with respect to Firewall.
Service Assurance and Service Differentiation	Yes	Yes, it provides policy and QoS management.	Yes. It provides services for QoS and policy control.
Cloud-Ops	Yes	Yes	No
Legacy Control	No	Yes	Yes
Network provisioning	Yes	Yes	Yes
Network management	Yes	Yes	Yes
Network Security	Yes	Yes	Yes
Network Troubleshooting	No	Yes	Yes

This research over SDK for SDN may help in choosing available SDN SDK and it may also provide pointers to start development for any SDN SDK from the scratch.

References

5998-4920_HP_VAN_SDN_Controller_Programming_Guide.pdf
5998-4919_HP_VAN_SDN_Controller_Admin_Guide.pdf
MTOSI ADAPTER USING JUNOS SPACE SDK PDF
Junos_Space_SDK_13.1_Release_Notes.pdf
Junos_Space_SDK_13.1_Release_Notes.pdf
http://www.juniper.net/techpubs/en_US/junos-space-sdk/13.1/apiref/com.juniper.junos_space.sdk.help/Services.html
http://developer.juniper.net/shared/jdn/html/browser-help-13.3/com.juniper.junos_space.sdk.help/html/guides/appdevguide/websvcsproj.html
http://www.juniper.net/techpubs/en_US/junos-space-sdk/13.1/apiref/com.juniper.junos_space.sdk.help/Services.html
Junos_Space_SDK_13.1_Release_Notes.pdf
MTOSI ADAPTER USING JUNOS SPACE SDK PDF
Junos_Space_SDK_13.1_Release_Notes.pdf
Junos Space Virtual Control app is for managing virtual network.
JunosSpaceSDK_DataSheet.pdf
https://juniper.mwnewsroom.com/manual-releases/2009/Juniper-Launches-Open-Software-Platform-to-Acceler
http://trinetprimasolusi.blogspot.in/2011/01/junos-sdk-enables-developers-to.html
http://www.juniper.net/us/en/local/pdf/datasheets/1000297-en.pdf
https://communities.cisco.com/docs/DOC-53411#jive_content_id_Is_there_an_onePK_plugin_for_OpenDaylight_
https://communities.cisco.com/docs/DOC-53411#jive_content_id_Is_there_an_onePK_plugin_for_OpenDaylight_
https://communities.cisco.com/community/developer/networking/cisco-one/onepk/blog/2014/05/15/solving-a-network-securityusability-paradox-with-cisco-onepk--ben-story
http://www.data.proidea.org.pl/plnog/11edycja/PLNOG_11_Day_2/Track_1/Krzysztof_Konkowski_Przemek_Pisarek.pdf

Northbound applications on SDN controllers

Computer applications make our lives easy and cater to a specific task or need. In SDN's context, the applications can bring ease and comfort for the network/IT administrators. This blog post describes the northbound applications used over various SDN controllers. The applications range from network management, monitoring, security, QoS etc.

The application development on SDN controllers is taking place through multiple models. Some vendors(SDN controllers) make their own applications, some collaborate with others to create a joint solution, some just outsource it and some are putting in efforts to create an ecosystem by publishing APIs on which programmers like us can create innovative applications. Many applications are available on github as scripts for vendors like Cisco, Ryu, Floodlight etc.

After reading through a lot of controllers and northbound applications, I have tried to summarize it as given below.

HP VAN Controller

• HP Network Protector SDN Application: The Network Protector SDN Application, running on the HP Virtual Application Networks (VAN) SDN Controller, enables automated network posture assessment and real-time security across OpenFlow-enabled network devices. There is no need for dedicated appliances as the security application is deployed as software.

• HP Network Optimizer SDN Application Series: The HP Network Optimizer SDN Application for Microsoft Lync enables automated provisioning of network policy and QoS to provide an enhanced user experience.

• BlueCat DNS Director: BlueCat DNS Director provides you with programmatic control of your DNS services to prevent DNS tunneling, and secure application access for central DNS security, globally delivered.

• ECODE evolve™:  ECODE evolve™ is a suite of tools to facilitate dynamic network design, provisioning, simulation and automation leveraging the power of SDN. It empowers you with dynamic, real-time network designs. You can safely modify and test the designs, and then have it automatically deployed in a production environment.
   
• The F5 BIG DDoS Umbrella: The F5 BIG DDoS Umbrella, powered by the HP VAN SDN Controller solution allows you to implement network, application, DNS, and SSL DDoS protection near the network edge.

• GuardiCore Defense Suite: The GuardiCore Defense Suite adds a new layer of defense through automatically preventing targeted attacks from within the datacenter where it is most vulnerable.

• KEMP Adaptive Load Balancer App: Provides an end-to-end visibility of network paths for optimal routing of applications across the server and switching infrastructure.

• Hyperglance: Hyperglance is a Hybrid Cloud and SDN management platform that provides visibility of your whole topology and all flows in a scalable 3D environment to easily interrogate switches and interfaces and set up and take down flows

Juniper Contrail

• Junos Space Security Director: It helps organizations improve the reach, ease, and accuracy of security policy administration with a scalable, GUI based management application.

• Junos Space Services Activation Director: It ensures error-free service provisioning and monitoring of legacy Carrier-Ethernet and MPLS using a simple interface to design, validate and manage these services.

• Junos Space Network Director: It simplifies network operations by unifying wired and wireless management for complete life-cycle of management of campus and data center networks from a single pane of glass.

• Junos Space Service Now: It is a remote, automated trouble-shooting client that enables Juniper to quickly identify a problem in the customer's network to achieve a 40% increase in Day 1 issue resolution. Comes with the Junos Space Network Management Platform.

• Junos Space Service Insight: It reduces network downtime by delivering proactive bug notifications specific to your network configuration, and thorough automated end-of-life/support analysis where you can do complete EOL auditing across 100's of devices in seconds. Comes with the Junos Space Network Management Platform.

• Junos Space Content Director: It speeds and simplifies deployment and configuration of Junos Content Encore through the network, with a centralized caching management solution that scales to manage hundreds of caches from a single server.

• Junos Space Virtual Director: It automates instantiation of Virtual Machines for Juniper's virtual security services supporting fast and error-free service rollout.

FloodLight Controller

• Circuitpusher: It utilizes floodlight rest APIs to create a bidirectional circuit, i.e., permanent flow entry, on all switches in route between two devices based on IP addresses with specified priority.

• packetStreamerClientExample.py: Allows you to intercept packets from floodlight's packet_in processing chain and read them.

• graphDeps.py and graphTopo.py: Read the module dependencies (graphDeps.py) or the topology from the REST API and output it in the 'dot' format used by the popular graphviz (www.graphviz.org) package so that they can be visualized.

• DefenseFlow by RadWare: It programs networks for DoS security, providing network-wide attack mitigation services, providing defense against any DDoS attack.

Ryu Controller

• cbench.py: A dumb OpenFlow 1.0 responder for benchmarking the controller framework.

• simple_switch: An OpenFlow 1.0 L2 learning switch implementation.

• simple_isolation: MAC address based isolation logic.

• simple_vlan: VLAN based isolation logic.

• gre_tunnel: Flow table updater for OpenStack integration. Despite of the name, this isn’t GRE specific.

• tunnel_port_updater: This module updates OVS tunnel ports for OpenStack integration.

• rest: This module provides a basic set of REST API.

• rest_quantum: This module provides a set of REST API dedicated to OpenStack Ryu plug-in.

• rest_tunnel: Provide a set of REST API for tunnel key management. Used by OpenStack Ryu plug-in.

• quantum_adapter.py: Listen OpenFlow port status change notifications from switches. Consult ovsdb to retrieve the corresponding port uuid. Notify relevant parties, including quantum (via Ryu plug-in) and Ryu applications. (via Ryu Events)

• rest_conf_switch.py: This module provides a set of REST API for switch configuration.

• rest_qos.py: Enable queue setting to interface individually

• topology: Switch and link discovery module.

Cisco (Scripts available on github)

• NexusDash: A Django based monitoring web dashboard for Nexus machines. Simply drop-in the app and go!

• interface_rate_n7k: This script prints interface throughput/packet rate statistics in an easy to read list format

• link_monitor_nexus7000.py: Goal of this script is to monitor a set of interface status and act upon another set of interface status.

• cdp_description.py: This script add description to interfaces based on "cdp neighbors" information.

• crc_checker_n7k.py: The following python script checks for CRC errors on all interfaces.

• link-state-monitor: This Script,
• Shuts down all the interfaces mentioned in the –a options, when all the interface mentioned in –m option is down
• Brings up all the interfaces mentioned in the –a options, when at least one of the interface mentioned in –m option is back up

• ABM-Beam: It sends out Active Buffer Monitoring histogram for all the ports and the buffer-blocks over UDP.

• PyMonitor: Buffer monitoring

• hadoop-integration: Integration with hadoop

• vlan-add: This script will prompt the user to enter a VLAN ID to be created on multiple switches.

Nicira/VmWare NVP

• Security Services (Network Security, Threat Protection, Firewall, Anti-virus, IDS, IPS , Vulnerability Management, Security Operations.): Through partnership with Intel, Palo Alto Netoworks, Next Gen Security, PAN-NSX, Rapid 7, Symantec,and Trend Micro.

• Application Delivery Services(Load balancing, application delivery controllers, WAN optimization controllers): Through partnership with F5, Citrix.

• SDDC Operations and Visibility Services(Network operations, security operations, application and network performance monitoring/management, compliance management, infrastructure analytics, cloud management): Through partnership with  EMC Smarts, Riverbed Cascade, Gigamon, Tufin.

NetSocket vFlow

• vApps :Many third party products/applications are listed under vApps. 

Italtel SBC

• It is designed to support different virtualization technologies, including VMware, Linux KVM and MS System Center, and can be managed by different/multiple Cloud Orchestrators.

Open Source Software for NFV Architecture Framework

                                         

This article, which will evolve gradually in future, is focused on listing the open source software, which can be used at various layers of the NFV architecture framework.

Wikipedia defines and summarizes the history of NFV as below -

"Network Functions Virtualization (NFV) is a network architecture concept that proposes using IT virtualization related technologies, to virtualize entire classes of network node functions into building blocks that may be connected, or chained, together to create communication services"

"In October 2012, an industry specifications group, "Network Functions Virtualisation", published a white paper at a conference in Darmstadt, Germany on software-defined networking and OpenFlow. The group, part of the European Telecommunications Standards Institute (ETSI), was made up of representatives from the telecommunications industry from both Europe and beyond. Since the publication of the white paper, the group has produced several more in-depth materials, including a standard terminology definition and use cases for NFV that act as references for vendors and operators considering implementing NFV."

NFV architecture framework specification was published by ETSI in October 2013. In this document, a reference architecture was proposed, which is reproduced in the Figure 1 below.

                                                  FIGURE 1 : NFV Architecture Framework


Figure 2 below, maps the list of the open source software which can be used to realize/implement the various layers of the architecture.


                                            FIGURE 2 : OPEN SOURCE SOFTWARE IN NFV

As mentioned above, this list is not complete, and in many cases may not be 1:1 mapping. We hope that this consolidation of the information will be helpful in highlighting the OSS tools in NFV.

A presentation related to this is shared to give more detailed view. Click here to  view the details.

SDN and Abstractions

SOURCE: Scott Shenker – Professor, University of Berkeley, California.

 We know that Abstractions are keys to extracting simplicity. Classic example of abstractions in networking is LAYERS. Layers deal with the data-plane, and there is a need for ‘strong’ control-plane abstractions.

Network Control Problem:

1. Operating Without communication guarantee
2. Computing the configuration of each (physical) devices.
3. Operate within the given network protocol

The below three abstractions are based on the above ‘Decomposition’ of the ‘Network Control Problem’.

• Distributed State Abstraction – Control mechanisms should only be able to access the Network-state and it should be shielded from the ‘unexpected changes’ of the network-state. Ex: A global network view, where a well-defined network graph is exposed as an API – and control mechanisms work on (uses) these API(s).
• Specification Abstraction: Control mechanisms should just be able express desired behavior, instead of implementing that behavior on network infrastructure. Ex: Abstract view of the network, that models only enough details to specify goals – Pflow's VTN?
• Forwarding Abstraction: Should focus on freedom from dataplane limitations and vendor-specific solution. Ex: Openflow. Flexible forwarding model  - Abstractions supporting whatever forwarding behavior that is needed, and not constraining the control mechanisms. It should hide underlying hardware details – crucial to go beyond vendor-specific solutions.

SDN Definitions.

SDN has been defined by different researchers in different terms. Below we enlist a few:

1. One which is more general and inclusive one is provided by Heller, as follows “SDN is a refactoring of the relationship between network devices and the software that controls them”
2. Big Switch Open-SDN: SDN eliminates the complex and static nature of legacy distributed network architectures by using the standards-based software abstraction between the network control plane and underlying data forwarding plane. 
3. Scott Shenker: SDN is about achieving Forwarding, State Distribution and Specification abstractions at network control planes.
4. SDN adds flexibility to control-plane implementation choices. As a result, the network devices become simple packet forwarding devices (the data plane) that can be programmed via an open interface 
5. SDN includes the following (a) open/standards-based interface to hardware (b) Network operating system (c) Well-defined APIs to write various network applications 
6. SDN is about clear separation of the data and control planes of the network devices, and about having sufficient abstraction at the control plane to support the provision of novel services in the network.

About SDN Happennings

Three concepts - (a) network programmability by clear separation of data and control planes and (b) sharing of network infrastructure to provide multitenancy, including traffic and address isolation, in large data center networks and (c) replacing the functions that traditionally run on a specialized hardware, with the software-realizations that run on commodity servers - have gained lot of attention by both Industry and research-community over past few years. These three concepts are broadly referred as software defined networking (SDN), network virtualization (NV) and network functions virtualization (NFV). This blog focuses on SDN technology in general and how this technology can complement Network Virtualization and Network Function Virtualization.

Thomas S. Kuhn, in his highly-influential work ’The Structure of Scientific Revolutions’, defines the term paradigm as “universally recognized scientific achievements that, for a time, provide model problems and solutions for a community of researchers”. Going by this meaning, it would not be too off the mark to call Software Defined Networking (SDN) as a new networking paradigm. Referring again to Kuhn’s words, SDN is also “sufficiently open-ended to leave all sorts of problems for the redefined group of practitioners to resolve’.

In the words of Martin Cassado, Network virtualization and SDN are two different things and somewhat incomparable. SDN is a mechanism, whereas NV is a solution. Same applies for NfV. Hence, NV and NfV can both be seen as use-cases of SDN. In addition,SDN is not a requirement for both NV and NFV, but the technologies are complementary.

As seen from the list of the authors, this blog is an effort (sometimes combined) by bunch on sincere Engineers. We hope it will be useful to somebody, someday.

Thanks!
SDN-Happennings Team