On February 18, Cisco announced the evolution of service provider (SP) networks. It is probably a good idea to step back, just a little, and explain how Cisco sees the challenges ahead and how we intend to continue to provide our mobile service provider customers with the strongest portfolio of solutions in the industry. That’s the reason I am writing this blog post. In it, I hope to share with you some of our learnings from the past year and also, explain a little bit about the rationale for our announcement.
We are virtualizing our entire SP portfolio. The year 2013 is one where the concept of “Network Function Virtualization” (NfV) caught the industry by storm. In NfV, virtualized network functions are software appliances executing on virtual machines delivered in a telco cloud environment. In a nutshell, NfV is attractive to our customers because it allows them to clearly delineate the respective values of software, hardware and professional services for total solution integration. Practices based on data center techniques promise to reduce the cost of operating the network and simplify work processes through the agility we are seeing today in the cloud environment. And none of this evolution will compromise the ability of service providers to deploy multi-vendor solutions though it is fair to state, procurement practices will need to re-align to this brave new world. For example, rather than procure integrated network functions to be assembled into a network, service providers may have to separate out layers Read More »
A few weeks ago when we announced the Cisco APIC Enterprise Module, in response to a post by Cisco VP Jeff Reed, David had quite a lengthy comment to which I’d like to respond. His specific question (within the full comment) was:
Do you see an upside for more value-added offerings — beyond the current anticipated cost-savings debate about the promise of SDN/NFV technologies?
First, thank you David for your questions. In short, Yes. At Cisco we see a lot of value in offering services to our Enterprise customers and also to our partners who offer managed services to their customers. Let me expand on this.
Cisco is fully aware of the emerging market segments with the still nascent SDN technology adoption. As you say, larger telcos and cloud service providers are looking at SDN/NFV with open hardware assessments and are more interested in scaling their deployments of multi-tenancy architectures. Whereas small and medium sized enterprises are evaluating SDN with a more application-centric approach. The main concern, given their modest investment infrastructure, (compared to the telcos and cloud service providers) is about having agile IT that can respond quickly to their business needs. Read More »
If you were to believe the industry press, you could easily be forgiven for thinking that many companies across the world were rolling software defined networking (SDN) technologies into their networks today. I’m part of Cisco’s Services team and my colleagues across the world are the experts in helping you all design and deploy networks. If there is a large or complex leading (or bleeding!) edge network out there being designed, you can place a safe bet that someone from the Cisco Services team is involved helping our customers achieve their targets. If you’re involved in deploying any type of high technology equipment, you’ll appreciate that there is a world of difference between selling, demoing, and actually making it all work in your environment when it comes to new technology. Our team are in the latter camp.
So what are our consultants telling me about SDN in the real world? Excluding a few notable high profile cases (usually involving hyper-scale data centers) they are not seeing -- as yet, to be honest -- many early deployments. However they are seeing a growing number of customers interest in learning about and evaluating SDN related technologies -- including Cisco ONE, NFV and in particular Application Centric Infrastructure (ACI). And they are providing some early feedback on the use cases of SDN that customers are most interested in. They are all clear, however, on this point: this is the time to learn what SDN and Cisco ONE can do for your network in the future.
So how do you get started in SDN? Let me outline 5 key steps to help you get started. I’ll also point you to a technical white paper written by Mitch Mitchiner and Reema Prasad, two of our Customer Solutions Architects in Cisco Services, two of our experts responsible for making all of this work for you, your team and your business. I also recommend you check out the video link I’ve provided, for an excellent live demo of Cisco ONE technology, first presented at Cisco Live last year. This video gives a live demo of latency-based routing, one of the use cases described in Mitch and Reema’s paper.
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.
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.