Tag: sdk

SDN/NFV Paradigm: Where the Industry meets the Academia

After 7 months, Service Engineering and SWITCH are back with the regular Swiss SDN workshops, this time held on 16th of June at the ZHAW premises in Winterthur. For the 6th time, the Software Defined Networking (SDN) community from Switzerland and abroad (represented by the industry and the academia), embarked on a joint SDN-NFV full-day journey to discuss SDN, present the best practices and prototypes and share the know-how and some demonstrations of their recent research activities. As a novelty this time, the SDN workshop/meetup was collocated with the Open Cloud Day, allowing for broader attendance from participants in both events. Regular attendees and new fellows could be spot on site engaged in interesting discussions. You can find the through report of the event here from our collaborator SWITCH and i leave you below the complete list of the SDN track. The complete presentations repository could be found here. Enjoy and see you in the next events!

Continue reading

Service Function Chaining using the SDK4SDN

Last week in Athens we integrated the SDK4SDN aka Netfloc in the T-Nova Pilot testbed in order to showcase service function chaining using two endpoints and two VNFs (Virtual Network Functions).

NETwork FLOws for Clouds (Netfloc) is an open source SDK for datacenter network programming developed in the ICCLab SDN initiative. It is comprised of set of tools and libraries that interoperate with the OpenDaylight controller. Netfloc exposes REST API abstractions and Java interfaces for network programmers to enable optimal integration in cloud datacenters and fully SDN-enabled end-to-end management of OpenFlow enabled switches.

Continue reading

GUI for Netfloc – An OpenSource SDK for SDN

Inside the Software Defined Networking initiative we are developing a Software Development Kit for SDN, called Netfloc.

NETwork FLOws for Clouds (Netfloc) is a programmable framework solution for software defined datacenter networks. It leverages network management by offering to the network developers a set of libraries packed as Java bundles for the OpenDaylight controller. Netfloc also exposes REST API abstractions and Java interfaces to enable optimal integration in cloud datacenters and customized end-to-end management of OpenFlow equipment. For references and current status, please feel free to visit the Github repository. We will come back with a detailed post on the SDK very soon, so stay tuned.

And yes being the networking guys, we are mainly dealing with command line management in the whole process of development and testing. But only until to date, when we realized that it is time to think as well of the UX side and start a design process for a graphical user interface (GUI) for Netfloc.

Continue reading

5th Swiss SDN Workshop highlights

Last Friday, 13th November the 5th SDN workshop took place at the SWITCH premises in Zurich. With 9 presentations covering different aspects of Software Defined Networking and around 40 attendees, we are happy to bring together the academia and industry partners on the same table in order to provide to the community a complete overview of the most recent results, products and open source SDN solutions.

 

switch_kurt

Compared with the previous workshops, talks from the industry were prevalent this time, which brought variety but most importantly an intent to close the gap between SDN research projects and grand-scale solutions based on customer use cases.

Continue reading

A Design Draft for Tenant Isolation without Tunneling in Openstack

The Problem

Cloud networking bases on tech and protocols that were not initially designed for it. This has lead to unnecessary overhead and complexity in all phases of a cloud service. Tunneling protocols generate inherent cascading and encapsulation especially in multi tenant systems. The problem increases by vendor specific configuration requirements and heterogenous architectures. This complexity leads to systems which are hard to reason about, prone to errors, energy inefficient and increases the difficulty of configuration and maintenance. Continue reading

Software Defined Networking for Clouds

Description

Software Defined Networking (SDN) is a technology that has introduced an important paradigm shift in the networking world. With the OpenFlow protocol as a main technological enabler, the essential goal is to extend the conventional network configuration approach by introducing the concept of network control and programmability.

The advances in the OpenFlow protocol and the strong community involved in the OpenDaylight (ODL) framework has significantly leveraged SDN over the past few years, which booked it a ticket as a de-facto technology in the datacenter network management journey. To follow this initiative, OpenStack has been a pioneer technology that urged to provide a direct SDN support for Neutron. Such approach has introduced new challenges arising from the direct mapping of network traffic between the physical hosts and the virtual tenant networks.

Identifying scenarios that embrace different issues to consider, has a high priority in the current SDN world. With the main focus on SDN-managed datacenter networks, this initiative will provide a technical implementation and know-how on managing cloud-based network resources in a straightforward manner.

Objectives

The “SDN for clouds at the ICCLab” mission involves: establishing use cases, revealing potential issues, analyzing alternative approaches and optimizations in order to achieve efficient networking for classical datacenters, network carriers, Internet Service Providers and Cloud providers. The tasks to achieve this include:

  • Provide on-demand, scalable, commodity deployment to facilitate SDN knowledge transfer to academia and business partners
  • Provide Network as a Service for the tenants
  • Monitor and optimize intra-cloud-traffic
  • Automate changing flows with the SDN-controller
  • Minimize complexity of the network logic
  • Efficient handling of QoS and QoE network parameters
  • Independent network-hardware vendors

Research Challenges

The on-going technology and protocols applied to cloud networking are not optimal in terms of resource usage, reliability, deployment and maintenance. For example, the current implementation of Open Stack Neutron relies on different tunnelling mechanisms in order to provide isolation and multi-tenancy support. From a network application developer point of view, this is inefficient since it injects additional overhead and impedes a transparent application development.

To address the issues in that context, we define the following research tasks:

  • Reconsider the current concepts and state of the art proposals and determine a sophisticated solution towards optimized SDN design for modern cloud architectures
  • Define competitive use cases as direct controllers and evaluators of our SDN solution
  • Provide a high level framework for management of cloud based network resources in a uniform manner

Relevance to current and future markets

Having in-house deployment implies an up and running environment prepared to leverage ideas deployed and tested over commodity-hardware. The ICCLab SDN testbed will essentially facilitate the validation of use cases towards comprehensive solutions. The high-level framework on top of the ODL controller will provide smart virtual datacenter management in OpenStack deployments, and potentially target industry partners among the content delivery network companies, like Akamai for example, IPTV and streaming service providers. We also aim to expand the cooperation by exchanging technical expertise with industry partners involved in the SDN-Cloud field.

Impact

Articles and Info

Contact Point

Irena Trajkovska – mailto:traj@zhaw.ch

 

 

Most suitable language for SDK development for SDN?

We at ICCLab are embarking upon an exciting project to make a software development kit to enable SDN researchers develop exciting products and innovative protocols overcoming the challenges and drawbacks of decades old network protocols in use today. We had a huge debate internally to decide which programming language to use for this development. Since, internally we had quite strong and vocal supporters of both Java and Python, it led to stalemate. So how did we resolve it?

Continue reading