In the announcement of the Cisco Evolved Services Platform last week, we not only highlighted our initial service offers in mobility and video and the business benefits it enables, but also that it was open, extensible and elastic. Openness is critical for providers by nature of the fact that their networks – often global in scope and mind-boggling in scale – require all the different technologies and often from different vendors installed to create the network experience desired actually can work together. If not, it limits the offers they can take to market or requires operational contortions to make work, either of which would affect the provider’s ability to do business.
That’s why our engineering teams are so focused on making the Evolved Services Platform so Open. They have incorporated Openstack and Open Daylight (SDN) protocol suite; they’ve made it fully compliant with ETSI NfV (MANO), 3GPP Gi-LAN and more. In fact, their efforts in the more than 60 standards bodies helps us to factor into our roadmaps the latest understanding of the current standards and, just as importantly, where they are going.
But in addition to standards, the Cisco Evolved Services Platform needs to also be multi-vendor. And on the first day of our largest tradeshow of the year, Mobile World Congress in Barcelona, where pleased to highlight Broadsoft, Intel and Mavenir are joining in their endorsement of our approach. Here’s what they said:
“At BroadSoft we are the leading application provider and working toward the NFV implementation with an open eco-system. We share an open platform strategy with Cisco around virtualization, orchestration and automation that provides an environment where customers, partners, and independent developers can freely innovate and develop integrated applications that offer greater value to users. We are excited to work with Cisco to provide a virtualized/orchestrated VoLTE solution on the Cisco Evolved Services Platform.”, said Scott Hoffpauir, Chief Technology Officer, BroadSoft.
“With the virtualization capabilities enabled with the Evolved Services Platform, Cisco is able to address industry requirements for orchestration of services across both virtual and physical infrastructure,” said Rose Schooler, Vice President and General Manager of the Intel Communications and Storage Infrastructure Group. “By utilizing the advanced features of the Intel Xeon server platform, Cisco is able to deliver solution architectures that are enabling the performance agility on fully open compute systems that service providers need to quickly scale new services, more customized to customer needs, with a faster time to market.”
“Virtualization is transforming our business by providing the agility, flexibility and profitability for service innovations. More importantly, providing a cloud platform that is open, extensible and elastic for mobile solution providers is a key step toward realizing this direction. We are pleased to see Cisco making this vision a reality to the industry and its partners by providing the Cisco Evolved Services Platform.”, said Bahram Jalalizadeh, EVP of Business Development, Mavenir Systems
These, along with Openwave Mobility and Metaswitch, make up the initial members of the Cisco Evolved Services Platform Ecosystem, to help avoid making multi-vendor environment hamper a SP operations but rather to help give the service provider flexibility to pursue even more opportunities as they stay Open for business.
Earlier this month, I attended the first ever summit on OpenDaylight (ODL) project in Santa Clara, CA. This near sold out event was largely successful by many standards. It brought together a large number of great minds to the table to solve some of the toughest challenges the networking industry is facing around Software-defined Networking (SDN) and Network Function Virtualization (NFV). The group announced a first major step forward with the first open source software release called Hydrogen. The bulk of the credit goes to 154 contributors from Cisco, IBM, Ericsson, Red Hat, Citrix and others who wrote over a million lines of code in past ten months to make this happen.
The two-day summit was packed with a variety of sessions that were geared towards a diverse set of audience. The sessions varied from general topics to specific topics such as relevance of Open source software, NFV, LISP, standards, discussions on North and South bound APIs, developer tutorials for building applications & tool chain, using OpenStack with ODL, analytics, test automation, and a true story of SDN in production environment.
Of all these topics, here are the three important themes that stood out to me -
1. The importance of an Open Source, community initiative for SDN
The concept of Open Source software has been around since decades. It is fast catching up in the non-traditional realms of computer networking. For some, the concept of open source equates to free software. While this is partially true, I strongly believe that open=free is a misnomer. I have started to realize that open source and further, the collaborative initiatives like ODL is far beyond the notion of freeness. In my view, the most important thing that such an initiative does is to gather right minds to bring out bright ideas. The collective wisdom that emanates from such a collaborative initiative helps vendors develop a cohesive set of products that speaks a common language, and perhaps share certain fundamental design constructs to aid interoperability. At the same time, I believe that this collaboration helps to compress the infinite ways vendors can built products to a bounded, agreed upon set of behaviors and interfaces. Customers are real beneficiaries of such an open initiative due to this standardization and better product interoperability. As Vijay Pandey from IBM aptly said in one of his presentations, open source initiatives like ODL “promote innovation and raise the value bar.”
2. What and how much to Standardize (North and South bound APIs)
In the summit, there were several interesting debates on what to standardize and how much. With regards to how much, I am with Guru Parulkar’s mantra to “standardize as little as possible.”
One of the core capabilities that SDN brings to the table is the notion around exposing interfaces from control plane to the infrastructure layer (South Bound APIs or SBI) and to the application/business layer (North bound APIs or NBI). We talked about using common approach for design constructs above, and the APIs are central to the constructs. However, if we (are somehow able to) standardize every hook into the system, we are forcing the industry to take a “single” approach to solve the underlying problems. Additionally, I believe that such an approach will not only go against the very notion of openness, but will also hinder innovation and ability to provide unique experiences.
If we talk about SBI, we rightly need some standardized ways to abstract some of the infrastructure complexities. I learnt that ODL will include support for SDN open standards such as OpenFlow, VxLAN, PCEP etc. Similar to SBI, can we standardize the NBI’s as well?
Why should you put a virtualized content delivery network (CDN) in the cloud?
This is not just a theoretical question. It has come from our customers. At our recent Cisco Live event in Milan, we demonstrated how our continued CDN technical leadership can answer this question.
First, some history, as you can’t just begin with the cloud.
At Cisco, we’ve been working hard over the years to evolve our Videoscape Distribution Suite (VDS) platform. From its roots in hardware-based appliances, to software applications powered by our data center hardware, and more recently to virtual machine implementations which can be powered by our own or third party hardware. Each technological advance to our VDS platform has netted gains for our customers in their CDN deployments; whether through more flexible deployment from greater hardware independence, faster time-to-market implementing VDS software applications, or reduced total cost of ownership thanks to server-based virtualization that optimizes footprint and power/cooling requirements.
Last week at Cisco live! Milan, we announced another milestone in our OpenStack strategy with the availability this quarter of the Nexus 1000V virtual networking platform for Linux Kernel Virtual Machine (KVM) hypervisor and integration with the commercial OpenStack distribution from Canonical (Ubuntu Linux and OpenStack). I had a chance to sit down in Milan with John Zannos, VP of Global Alliances at Canonical, to talk about the Cisco-Canonical partnership, and what the integration of Nexus 1000V into their OpenStack architecture means for customers.
The Nexus 1000V on KVM brings to the OpenStack cloud a fully integrated network virtualization solution. The solution provides a full layer-2 feature set, feature-rich Layer-3 IOS router, security and QoS policies, VXLAN virtual overlays, vPath-enabled virtual services, and full monitoring and management capabilities. Enterprises and service providers may now deploy a full-featured virtual network infrastructure consistently across VMware, Microsoft, and Linux-based software platforms.
Nexus 1000V for Ubuntu Linux with OpenStack support is now available with full automation and orchestration of enablement of the solution via Juju/Charms. Juju provides both a command-line interface and an intuitive web app to design, build, configure, deploy and manage your infrastructure. Charms give Juju its power. They encapsulate application configurations, define how services are deployed, how they connect to other services and are scaled. Nexus 1000V support for Red Hat KVM and OpenStack is planned for later this year.
Additional details and data sheets can be found here.
And on a related note, if you are interested in Nexus 1000V-related items, we recently recorded a technical podcast with Greg Ferro and Ethan Banks of packetpushers.net on the Microsoft Hyper-V version of our virtual switch, which you can find here.
The OpenDaylight Project today announced that its first open source software release Hydrogen is now available for download. As the first simultaneous code release cross-community it has contributions across fifty organizations and includes over one million lines of code. Yes. ODL > 1MLOC. For those of you interested that’s approximately two hundred and thirty man-years of work completed in less than twelve months.
It was around this time last year that the media started to pick up on a few rumors that something may be in the works with software-defined networking and controllers. I remember our first meeting at Citrix where the community started to collaborate on The OpenDaylight Project and come to common ground on how to start something this large. We had multiple companies and academics in the room and many ideas of where we wanted this project to go but there was one thing we had in common: the belief and vision to drive networking software innovation to the Internet in a new way and accelerate SDN in the open; transparently and with diverse community support. Each of us had notions of what we could bring to the table, from controller offerings to virtualization solutions, SDN protocol plugins and apps to solve IT problems. Over two days at Citrix we looked at things from a customer perspective, a developer perspective and ultimately and arguably the most important, a community perspective. From there The OpenDaylight Project emerged under the Linux Foundation. As I look back I want to applaud and thank the companies, partners, developers, community members and the Linux Foundation for driving such a large vision from concept to reality in less than twelve months, which is an incredible feat in itself.
Hydrogen is truly a community release. Use cases span across enterprise, service provider, academia, data center, transport and NfV. There are multiple southbound protocols abstracted to a common northbound API for cross-vendor integration and interoperability and three editions have been created to ensure multi-domain support and application delivery as well as deployment modularity and flexibility for different domain-specific configurations. These packages have a consistent environment yet are tailored to domain and role-based needs of network engineers, developers and operators.
The Base Edition, which includes a scalable and multi-vendor SDN protocol based on OSGi, the latest (and backward compatible) OpenFlow 1.3 Plugin and Protocol Library, OVSDB, NetConf/Yang model driver SDN and Java-based YANG tooling for model-driven development.
The Virtualization Edition (which includes the Base Edition) and adds Affinity Metadata Service (essentially APIs to express workload relationships and service levels), Defense4All (DDoS detection & mitigation), Open DOVE, VTN, OpenStack Neutron NorthBound API support and a virtual tenant network offering.
The Service Provider Edition (again, including the Base Edition) that also offers the Metadata Services and Defense4All but includes BGP-LS and PCEP, LISP Flow Mapping and SNMP4SDN to manage routers, gateways switches.
More information can be found on the website with regards to the releases and projects themselves.
I want to stress the importance of how well the vision has been delivered to date. I’ve been involved in multiple standards-bodies and in open source discussions in the past but this is truly one of the largest undertakings I’ve seen come together in my entire career. OpenDaylight developers have been coding day and night to get this release out the door and it’s amazing to see the collaboration and coherency of the team as we unite to deliver on the industry’s first cross-vendor SDN and NfV Platform. In addition and frequently not mentioned is that many of the protocols listed in the Editions above are also standardized at organizations like the IETF during the same period. Code and specs at the same time. It’s been a long time since rough consensus and running code has been the norm.
Over here at Cisco we’re fully committed to OpenDaylight. We’re currently using it as a core component in our WAN Orchestration offering for service providers to allow intelligent network placement and automated capacity and workload planning. The ACI team (formerly Insieme) collaborated with IBM, Midokura and Plexxi to create a project in OpenDaylight that creates a northbound API that can set policy and be used across a wide range of network devices. And of course we’re bringing components of the OpenDaylight codebase into our own controllers and ensuring application portability for customers, partners and developers alike. From this I would expect to see more code donations going into the community moving forward as well. We made several announcements last week about our campus/branch controller that includes OpenDaylight technology.
At the end of the day an open source project is only as strong as its developers, its community and its code. As we as a community move forward with OpenDaylight I expect it to become stronger with more members joining with new project proposals as new code contributors coming onboard from different industries as well. As I look at our roadmap and upcoming release schedule I’m pumped for what’s next and so happy the community has catalyzed a developer community around networking.
Please do visit the site, download the code and take Hydrogen for a test-drive. We want to hear feedback on what we can make better, what features to add or how you’re going to utilize it. Moreover, we’d love you to participate. It’s a kick-ass community and I think you’ll have fun and the best part; you’ll see your hard work unleashed on the Internet and across multiple communities too.