A Note from Neela Jacques

By | Blog

A Note from Neela Jacques

It is with mixed emotions that I am leaving my role as Executive Director of the OpenDaylight Project to join Bain Capital Ventures as an Entrepreneur in Residence. I’m excited by this next opportunity to pursue my entrepreneurial passions, but sad to leave such a great community that has been at the forefront of open source and SDN. I am so proud of what we have achieved together over the past 3+ years.

When I joined OpenDaylight as the Executive Director in 2013, our work was cut out for us. We all knew that SDN was necessary and would happen, but there were significant challenges to overcome. Could we get the networking industry to work together and build an open platform that everyone would agree on? Could we build a strong community that developers would want to be a part of? And most importantly, would end users deploy it and embrace open source at the heart of their networks?

Our goal was to unify the industry by building an open source platform for programmable, software-defined networks platform that could be broadly adopted. While there is still more work to be done, I’m proud of the progress and achievements that we have made over the past four years. We brought together service providers, enterprises, vendors, systems integrators, users and app developers to create the largest open SDN project to date. We’ve established a mature governance where people can disagree but still work together to build an even better solution. Our developer community is active and strong; more than 900 developers contributed to the five releases of the OpenDaylight platform.

Most importantly, OpenDaylight has proved to the networking industry that open source can serve as the foundation of their production infrastructures. AT&T, Verizon, Comcast, Bell and Canada in North America, Orange and Telefonica in Europe and China Telecom, China Mobile and China Unicom, Baidu, Alibaba and Tencent in China are members and/or users of OpenDaylight. We’ve seen large-scale production deployments by numerous major organizations including Tencent, CERN’s Large Hadron Collider project and AT&T, and OpenDaylight is the basis for solutions from Brocade, Ericsson, HPE and Red Hat among others.

On a more personal level, it is hard for me to express how much of a privilege it has been for me to lead this community over the past 3+ years. This role has given me a chance to get to know so many incredible engineers, technical and business leaders, and develop relationships across countries and cultures. I have been personally enriched by our interactions and proud of what we have been able to build, against steep odds, together.

I’m so proud to have been a part of the OpenDaylight community and grateful that you’ve trusted me to lead the project and serve as the voice for all of your hard work. I believe in this community, and I expect to stay engaged as I continue working with The Linux Foundation and the OpenDaylight Project as an advisor. I have full confidence in Phil Robb, our Board of Directors, TSC and technical leaders to be able to take the project to even greater heights. I look forward to cheering from the stands as OpenDaylight gets ever more deployed as the industry’s de-facto standard SDN platform.

Three Chinese Carriers in OpenDaylight City Tour

By | Blog

Three Chinese Carriers in OpenDaylight City Tour

Blog by George Zhao, originally posted here.

On Dec. 12-16, the ODL city tour workshop was sponsored by OpenDaylight,  China Open SDN Committee (COS), ZTE, Huawei, H3C, Cisco, VCMY and Raysystem, and hosted by Baidu, Tencent, Tethrnet and SDNLAB. It was held in four cities of China: Nanjing, Beijing, Shenzhen and Shanghai, all are within a week.

People from many technology companies joined and shared their experience in using ODL, the following slide is from Neela’s keynote, Neela listed top three companies for Internet, Telco and ICT vendors in China.  Internet companies, a.k.a BAT in China, are all members of COS and members of OpenDaylight, Tencent and Baidu are two of the four city hosts. All three Telco companies participated in ODL city tour and gave presentations. All the three ICT vendors were sponsors for this event. This shows a big enthusiasm for OpenDaylight in China.

neela-1

Let’s take a closer look at the three Telco’s  approaches of SDN controller.

 

China Mobile

According to China Mobile, after deploy SDN, the network is expected to be more open, more flexible and more efficient , it is true for the latter two, however, compare to traditional network, to many people’s surprise,  today’s SDN deployment makes network less open.

In traditional networking, following IP standards, gateway, switch, firewall can come from different vendors, but for today’s SDN to work properly,  equipment needs to be from the same vendor as SDN controller. China Mobile’s solution to prevent vendor lock in is to develop SDN controller by themselves.  The best way to build a SDN controller is based on open source,  China Mobile selected OpenDaylight platform to develop their own SDN controller – AERO.

china-mobile

It is hard to ignore the gap between open source community release and commercial product release, China Mobile summarized three key areas for open source SDN controller:

  1. Clustering: high performance, high available and flexible clustering is the key.
  2. Model: common abstract model for apps and network equipment
  3. Exception handling: how to make sure data consistence during exception handling.

China Telecom

China Telecom gave a couple of use cases of how they leveraged OpenDaylight in their SDN controller; IP SDN & NFV on WAN and unified control/management for cloud/WAN.

CT-uc1

 

ct-uc2

While China Mobile is emphasized on southbound, China Telecom concentrates on northbound service plugin and Yang model, they would like northbound to be more abstracted, and they would like to have Yang model to be standardized and more mature in ODL. Their expectations of OpenDaylight are not very different than most of others, enhance core, cluster and performance.

CT-exp

 

China Unicom

Fast and automatic deployment is the main motivation for China Unicom to adapt SDN/NFV. At Shanghai, China Unicom gave an presentation of  SDN requirements from China Unicom and Practice of ODL through A-Network.

cu-cover

China unicom divided the controller into two layers, one is very like domain controller, it is vendor specific, the other is like super controller, it is ODL based and controls domain controllers.

cu-1

The controller in red box is Huawei controller and in blue box is Cisco controller, both controllers connects to their own equipment as well as other vendors equipment through Netconf/PCE/BGP-LS protocols. On top of vendor specific controllers, there is one control system, which controls controllers.

Summary

Clustering, YANG modeling, performance and stability are the common interests of almost everyone who participated the ODL city tour, we should combine the strength of community and members, to build a robust HA open source SDN platform that can be leveraged by many many companies and people.

At last, thanks again for organizers and sponsors for this ODL city tour event, it has been a huge success and we keep the momentum for fast SDN deployment.

Three Chinese Carriers in OpenDaylight City Tour

By | Blog

Blog by George Zhao, originally posted here.

On Dec. 12-16, the ODL city tour workshop was sponsored by OpenDaylight,  China Open SDN Committee (COS), ZTE, Huawei, H3C, Cisco, VCMY and Raysystem, and hosted by Baidu, Tencent, Tethrnet and SDNLAB. It was held in four cities of China: Nanjing, Beijing, Shenzhen and Shanghai, all are within a week.

People from many technology companies joined and shared their experience in using ODL, the following slide is from Neela’s keynote, Neela listed top three companies for Internet, Telco and ICT vendors in China.  Internet companies, a.k.a BAT in China, are all members of COS and members of OpenDaylight, Tencent and Baidu are two of the four city hosts. All three Telco companies participated in ODL city tour and gave presentations. All the three ICT vendors were sponsors for this event. This shows a big enthusiasm for OpenDaylight in China.

Let’s take a closer look at the three Telco’s  approaches of SDN controller.

China Mobile

According to China Mobile, after deploy SDN, the network is expected to be more open, more flexible and more efficient , it is true for the latter two, however, compare to traditional network, to many people’s surprise,  today’s SDN deployment makes network less open.

In traditional networking, following IP standards, gateway, switch, firewall can come from different vendors, but for today’s SDN to work properly,  equipment needs to be from the same vendor as SDN controller. China Mobile’s solution to prevent vendor lock in is to develop SDN controller by themselves.  The best way to build a SDN controller is based on open source,  China Mobile selected OpenDaylight platform to develop their own SDN controller – AERO.

It is hard to ignore the gap between open source community release and commercial product release, China Mobile summarized three key areas for open source SDN controller:

  1. Clustering: high performance, high available and flexible clustering is the key.
  2. Model: common abstract model for apps and network equipment
  3. Exception handling: how to make sure data consistence during exception handling.

China Telecom

China Telecom gave a couple of use cases of how they leveraged OpenDaylight in their SDN controller; IP SDN & NFV on WAN and unified control/management for cloud/WAN.

While China Mobile is emphasized on southbound, China Telecom concentrates on northbound service plugin and Yang model, they would like northbound to be more abstracted, and they would like to have Yang model to be standardized and more mature in ODL. Their expectations of OpenDaylight are not very different than most of others, enhance core, cluster and performance.

China Unicom

Fast and automatic deployment is the main motivation for China Unicom to adapt SDN/NFV. At Shanghai, China Unicom gave an presentation of  SDN requirements from China Unicom and Practice of ODL through A-Network.

China unicom divided the controller into two layers, one is very like domain controller, it is vendor specific, the other is like super controller, it is ODL based and controls domain controllers.

The controller in red box is Huawei controller and in blue box is Cisco controller, both controllers connects to their own equipment as well as other vendors equipment through Netconf/PCE/BGP-LS protocols. On top of vendor specific controllers, there is one control system, which controls controllers.

Summary

Clustering, YANG modeling, performance and stability are the common interests of almost everyone who participated the ODL city tour, we should combine the strength of community and members, to build a robust HA open source SDN platform that can be leveraged by many many companies and people.

At last, thanks again for organizers and sponsors for this ODL city tour event, it has been a huge success and we keep the momentum for fast SDN deployment.

Software Defined Networking Fundamentals Part 1: Intro to Networking Planes

By | Blog

Software Defined Networking Fundamentals Part 1: Intro to Networking Planes

Article originally posted on Linux.com, see original post here:

Join us in this three-part weekly blog series to get a sneak peek at The Linux Foundation’s Software Defined Networking Fundamentals (LFS265) self-paced, online course.

Virtualization, which includes Software Defined Networking (SDN) and Network Function Virtualization (NFV) is changing the entire networking ecosystem. Virtualization is an innovation wave that cannot be ignored. The value proposition is too compelling for anyone operating a network (Enterprises and Service Providers) to ignore. All participants in this ecosystem must adapt, or they’ll be left behind.

This tutorial series, taken from the second session of the course, will provide the fundamental concepts of an SDN switch. This first part covers a short history of networking and the driving forces of innovation behind SDN. It also introduces the concept of planes and gives an overview of the three planes of networking.

The second part shows the architecture and operations of a traditional switch and how the planes are implemented therein. Then part three illustrates the architectural differences of a software defined switch and introduces the concept of an SDN Controller. It then covers RFC 7426 and how it introduced a number of abstraction layers to simplify the programming of complex networks.

Get all three parts and test questions by downloading a free sample chapter from the course today!

A Short History of Networking

The networks that drive today’s world, and the information technology industry in particular, are built on the concepts introduced by ALOHA and the U.S. Defense Advanced Research Project Agency (DARPA) initiative called ARPANET (Advanced Research Projects Agency Network).

What we now refer to as the “Internet” is the evolution of Arpanet. Created in the early 1960s, Arpanet was a packet-based network, as opposed to the widespread circuit switched Public Switched Telephone Network (PSTN).  The resilience, we now assume, was created to ensure survivability of a nuclear attack.  If a node (in this macabre case, a city) was removed from the network, the remaining nodes would adapt and route around the missing node.

In the 1980s, the Internet Protocol Suite (TCP/IP) was introduced, and the U.S. National Science Foundation funded numerous supercomputing centers at select universities and then funded connectivity to these sites to other research institutions. It was the advent of the web browser by Tim Berners-Lee of CERN that gave us a simple interface to the Internet and its resources and became the World Wide Web that’s become integrated in our lives.

The techniques and methods used in packet networking, as well as the hardware and the software, evolved over time. However, the actual network building blocks are the same, and we enhance them on top of the existing infrastructure.

With the advent of virtual machines (VMs) and virtualized data centers, the landscape changed in the compute domain. Despite that, the networks have been slower to adapt. Networks are geographically large systems with dozens of purpose-built hardware devices connected with miles of fiber optic cables.  For an enterprise the network is critical infrastructure, and for service providers the network is their business. Upgrading these mission-critical systems while they are in use is wrought with challenges.  Additionally, these purpose-built hardware devices are not only proprietary vendor-specific implementations, they are also rigid and inflexible. Thus, network operators are at the mercy of each vendor’s upgrade cycle and roadmaps. This is often referred to as “vendor lock-in.” To make it more challenging, services are often tightly coupled to hardware devices. If you want to add a new network service, you need to qualify, test, and then integrate a new hardware device to your installed base. As an illustration of this point, AT&T has noted that their average central office has more than 300 unique hardware devices. This alone is an operational nightmare.

As the web skyrocketed, the number of Internet Service Providers (ISPs) did too, creating a large market for companies that made switches and routers.  Based on the technology at the time and subsequent technical and market forces, these hardware-centric systems grew in physical size, performance, power consumption, and price.

To achieve the levels of performance required, vendors were often forced to create custom application-specific integrated circuits (ASICS).  These complexities led to numerous vendor-specific (proprietary) implementations and management systems. As a result, the services that ran on the network were tightly coupled to the specific pieces of hardware. If a service provider, or enterprise, wanted to add a new service (e.g., VPNs, residential firewalls, etc.), this became a multi-year effort requiring both new hardware and new expensive integration efforts.

At the same time, aggressive cash-rich and nimble web or cloud companies (e.g., Google, Amazon, et al.) were introducing new services seemingly weekly. They accomplished this using Commercial Off-The-Shelf (COTS) hardware and open source software. In networking, the inflexibility, growing costs and services-hardware lock-in ignited the global innovation engine. Research projects led to the paradigm of a programmable network infrastructure, which we now know under the name of Software Defined Networking (SDN). Some of the research projects which led to SDN were:

SDN will transform the network away from specialized hardware with protocols and applications implemented for each switch/router hardware/software combination. Instead, the functionality is implemented at a higher level, using the controllers APIs independent of the underlying hardware. Instead of programming individual devices, we can now program the network.

Intro to Networking Planes

On a whiteboard, networks may be drawn as a cloud or a number of straight lines between nodes. In reality, there are three dimensions, called “planes,” of a network: the Data Plane, the Control Plane, and the Management Plane.  It is important to understand these planes and how each of them is treated in a software-defined network.

 • Data Plane

The data plane is responsible for handling the data packets and applying actions to them, based on rules that we program into lookup tables. The actions must happen at line speed, therefore we must be fast enough (e.g., 40Gbit/sec per port).  Also called the data path or the forwarding plane, the data plane takes packets in one port of a switch and sends them out another port.

Knowing what port to send them out requires input from the control plane. Once configured, packets come and go at “wire speed” (e.g., 10Gbps).  So the switch has .0000000001 second (at 10Gbps) to figure out which port to forward the packet to. If it can’t match the packet to a pre-programmed rule, it sends the packet to the control plane.

• Control Plane

The control plane is tasked with calculating and programming actions for the data plane. This is where the forwarding decisions are made and where other functions (e.g., Quality of Service, Virtual Local Area Networks, etc.) are implemented. The control plane is operating at a lower speed than the data plane. It does not operate — or need to operate — at wire speed.

• Management Plane

The management plane is where we can configure and monitor the network device (e.g., switch or router). The network device can be a shell, command-line interface (CLI) or web interface. The management plane usually runs on the same processor as the control plane.

In part 2 of this series, we’ll explain the architecture and operations of a traditional switch and how these planes are implemented in this environment.

The “Software Defined Networking Fundamentals” training course from The Linux Foundation is designed to provide system and network administrators and engineers with the skills necessary to maintain an SDN deployment in a virtual networking environment. Download the sample chapter today!