Tag: SDN (page 2 of 3)

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

4th SDN Workshop in Bern

Yesterday for the 4th time the ICCLab organized the SDN workshop at the University of Bern in cooperation with SWITCH. We had around 25 participants and 7 talks that tackled SDN in the world of cloud computing, NFV, IXP, video content delivery, high performance cloud, authentication request routing and access control etc. All these solutions coming from different projects from the academia and the industry.

kurt_sdn_workshopsdn_workshop

Continue reading

SDN Workshop, 11th June 2015, University of Bern

ICCLab is happy to announce the upcoming SDN Workshop, that we are co-organising with SWITCH, will take place on Thursday, 11th of June 2015 – 09:00am to 6:00pm.

Location: University of BernMain Building, HG , 1st. Floor, Room 115

The aim of this Workshop is to share knowledge, have hands on sessions/presentations on SDN/NFV, Security, Cloud Computing and Service Delivery to the end-user, students, staff and researchers, providing a complete picture with ICT approaches, industry solutions, innovation and research.

Kindly register here to confirm your participation.

Agenda of the day is: 

09:15 – Welcome and Introduction

1st Session – 4 Presentations:

1. zSDN, a lossless networking architecture for workload-driven high performance Cloud – Mitch Gusat, IBM Research Labs Zurich

2. ENDEAVOUR H2020 project, enabling next-generation programmatic network services in Internet eXchange Points (IXPs) –  Marco Canini, Université catholique de Louvain, Belgium

3. Cloud Networking, Open Daylight and OpenStack – Irena Trajkovska, ICCLab, ZHAW

4. Open Cloud Exchange – Kurt Baumann, SWITCH

Lunch Break (1 hour)

2nd Session – 4 Presentations:

5. Architecture for application-centric wireless access using SDN – Panagiotis Papadimitriou, University of Hanover

6. SDN Network at Uni. of Bern – Zhongliang Zhao, University of Bern

7. Title coming soon – Microsoft Zurich

8. Pending

Wrap-up (17:00 – 18:00) – Discussion, next steps and networking

We would like to invite you to participate and request you to register here, so that we have the exact number of participants (to estimate the lunch requirement). To kindly note, registration is mandatory. 

Thanks and see you there!

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

 

 

MCN presenting at the iJoin Winter-School – impressions and major take-aways

The iJoin-Project is organizing an 5G-Winter-School, hosted by the University of Bremen. As part of the very distinct and representative program, the ICCLab is invited to present the latest results of the Mobile-Cloud-Networking (MCN) project.

Some impressions and take-aways from the event.

Simone Redana, Nokia, Germany, 5G RAN Architecture for virtualization RAN

  • 5G not only about radio interface (in 6GHz, etc)
  • New architecture needed, generally “Multi-Radio-Cloud, Core-Cloud, using SDN-xHaul and offering API-GWs
  • 5G-RAN-Cloud-Features: multi-connectivity, central radio-resource-mgt, application aware resource scheduling
  • Core-Cloud-Features: NFV-enabled
  • 5G features network slicing, e.g. a virtual overlay over the physical infrastructure for particular services/tenants

Clare Somerville, Intel, UK, Small Cell Forum, Small Cell Forum Advances within Network Virtualization

  • Small Cell Forum (SCF) is a non-for-profit organisation fouunded in 2007, with 150+ members, current specification release is #5 (Release-5)
  • Base-line: Two BIG innovations driving mobile networks, these are HetNets and NFV
  • Can “virtualization” be applied to small cell architectures? SCF believes yes it can
  • Small Cells to out-pace Cloud-RAN (RAN virtualization) deployments by 2019
  • Major challenge is the split between the physical and virtual part of the small cell RAN
  • The functional split poses requirements on the front haul technology, currently incompatible with the Ethernet-based standard deployed currently

2015-02-24 10.09.042015-02-24 09.54.21

Prof. Dr. Hans Schotten, University of Kaiserslautern, METIS

  • Connected Car and Traffic Control Systems (ITS) an important 5G-Use-Case
  • Human-controlled Robots 5G use case too

2015-02-24 10.27.02

Ralf Irmer, Vodafone, UK

  • 5G Services for Industrial Control Systems seem to bear great potential
  • 5G Research Challenge, Reliability of 5G services not yet ready to support Industrial Control
  • 5G Use Case Tactile Internet, requires in particular very low delay

2015-02-24 11.31.47 2015-02-24 11.33.33

  •  Software Defined Architecture (TMB: Is this something new?)

 Ignacio Berberana, Telefónica I+D, Spain, iJOIN, Telefónica’s view on virtualized mobile networks

  • Telco innovation largely influenced by HW
  • While many mobile network architectures look simplified, in reality they need many supporting functions which make real networks much more complex
  • Many new technologies never tested nor evaluated in close-to-real environments
  • A combination of SDN and NFV may bring virtualization into the network/telco
  • A virtualized network will require a deep transformation of company-internal structures, which was traditionally more leaning toward silos

Comparison of Ryu and OpenDaylight Northbound APIs

For our SDK4SDN work we made a comparison between two SDN controllers: Ryu and Opendaylight. We focused on the Northbound APIs of the controllers and we compared the capabilities and ease of use of their respective REST APIs.

Both controllers support REST, which is based on a mix of HTTP, JSON and XML. In Ryu a WSGI web server is used to create the REST APIs, which link with other systems and browsers. In OpenDaylight, the Jersey library provides the REST APIs with both JSON and XML interfaces. Jersey also provides its own API to simplify RESTful services by extending the JAX-RS toolkit which is compliant with the Northbound API.

Continue reading

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

Future Internet Assembly (FIA Athens 2014)

The 11th Future Internet Assembly  will take place from 18 to 20 March 2014 in Athens, Greece.

This year the focus will be on “Reshaping the Future Internet infrastructure for innovation”.

Open call has been launched to select the best  9 FIA working sessions for the conference, selecting the proposals that cover aspects related to:

  • The new Internet technological landscape based on network/cloud integration through Software Defined Networking (SDN),  Network Functions Virtualization (NFV), and innovative software and services that enable application innovation;
  • The contribution of  the EU National Research and Education Networks (NRENs) developments in the SDN/NFV domain;
  • The role of SDN/NFV in i) building Internet applications of major impact (e.g., social networks, open data, big data analysis, etc.) with virtual services capabilities; ii) enabling  the reduction in resources used (energy efficiency, reduction of raw-materials, etc….); iii) fostering the emergence of open platforms to create downstream markets for third party developers;
  • The EU Public-Private-Partnerships (PPPs) and how they are positioned relative to these developments and relevant requirements towards demonstration and test-beds in Europe/globally.

These sessions should:

  • Contain new and forward-looking ideas;
  • Feature a diverse array of presenters and experiences;
  • Introduce visionary ideas and practices which will inspire audience;
  • Promote cross cutting approaches and technologies to attract stakeholders and entrepreneurs;
  • Deliver best practices & creative approaches towards research and technological innovations;
  • Stimulate and provoke discussion.

The working session proposals can be submitted following the template available at https://osqa.eurescom.eu  by Tuesday, 15th October 2013.

 

A learning Switch in OpenFlow 1.3

So this is our second post about a learning Switch and as promised, it covers OpenFlow 1.3. Before we go into the details, this is what you should already know about SDN and OpenFlow:

  • General SDN Paradigm, otherwise go and read this
  • A common understanding about what OpenFlow is in contrast to SDN
  • What a simple learning switch is

What we are discussing in this post is the simple switch implementation that comes out of the LINC – OpenFlow software switch project as well as some basic principals from the latest OpenFlow Protocol (OFP) specification made by the Open Networking Foundation (ONF). One of the most important things you should know about OFP 1.3.x is the so called “table pipe-lining”. In previous versions of OFP there was a FlowTable in an OpenFlow enabled switch and that table stored the logic of how traffic flows through the network. Furthermore, a SDN-Controller jumps into the game when a packet that arrives at the switch doesn’t match any of the entries in the FlowTable. If this happens, we call it a “table-miss” and the switch sends the packet to the SDN-Controller. Now consider the following: In OpenFlow 1.3.x you not only have one FlowTable in an OpenFlow enabled switch, but there are as many FlowTables as the switch supports and the process how this multiple FlowTables are handled by OpenFlow is called the “table pipe-lining”. The inital behaviour isn’t that much different. If the packet arrives at the switch, the packet is always compared to the FlowTableEntries in the first the – table-0.

Continue reading

« Older posts Newer posts »