Thanks to SDN, the “Controller” word pops up in many network architecture discussions these days. In networking alone, we’re already surrounded by many “controllers” and we’re busy introducing more as we speak: For example, Session Border Controllers or Wireless LAN Controllers have been around for quite some time, and have recently announced the OpenDaylight Controller, the Cisco XNC, or the Cloupia Unified Infrastructure Controller. So what is a “Controller” in networking terms, and how many do we need in emerging network architectures?
June is summer weather in the San Francisco Bay Area, but quite different from the June I was used to in Boston. A common misconception around Mark Twain and his relationship with San Francisco summer is that he never said “The coldest winter I ever spent was a summer in San Francisco.” But he did say: “Cold! If the thermometer had been an inch longer we’d all have frozen to death.”
June is always exciting here and in Europe. NBA playoffs are on and the Giro d’Italia just ended with the Italian Vincenzo Nibali winning it emphatically. The San Antonio Spurs have been so good but King James brought the Heat back from a certain death in Game 6. Game 7 decides it all!
Equally exciting is the buzz in networking circles, especially in the Bay Area, around Software Defined Networking (SDN) and how it is potentially commoditizing networking infrastructure. However, just as we cleared up that misconception about Mark Twain, I’d like to clear up some points around WAN challenges with cloud migration and how SDN might be applied to overcome these challenges.
In this blog post I will discuss the challenges in the Enterprise WAN and relevancy of SDN in overcoming these challenges. In part 2, I’ll cover how the Cisco ONE Enterprise Networks Architecture addresses these WAN challenges. Read More »
Congratulations to all OpenDaylight founding partners, contributors, users and supporters. I am convinced this ambitious endeavor will redefine the meaning of “open source = collaboration”. This is a historic event, the coming of age of networking partners driving in the open source world, companies which until now, have been primarily preoccupied with driving open standards, though in many ways, resonating with the tenet of “running code and rough consensus” almost a generation before Open Source did. Perhaps this is, back to the future.
The announcement details are on the Consortium website at the Linux Foundation, contributions come in three categories, a multi protocol Controller platform contributed by Cisco, northbound (NB) applications on top, and southbound (SB) protocol drivers to support them from below. We expect that with such diverse community from the start, we will have a very open, diverse and collaborative development that will accelerate the growth and adoption of these projects for years to come.
Having been in this project from the very beginning, I would like to tell you exactly how and why we reached the open source model that we did, my own perspective in what I think is the key to getting that balance right. But later, not today.
Today is the day to celebrate all those diverse partners that were brought together by one singular desire to grow the market for application centered networking, to grow our collective ecosystem of users, developers, partners and customers, so that we can all win. With a rise in applications NB, more SB vendors will come and with a rise in SB support, more NB applications will arrive – the promise of the infinite feedback loop. I do not believe anyone out there should look for who wins and who loses; in this endeavor, this is a positive move for the industry, this is a win-win for everyone!
I think I’m going to play that “Meet Me On The Equinox” music and get into the OpenDaylight. It’s time to move forward and I hope everyone will.
The announcement today of OpenDaylight is big news. Industry leading companies are partnering via Open Source to serve an emerging set of market needs:
- Operators: want affordable real-time orchestration and operation of integrated virtual compute, application, and network.
- Application Developers: want a single simple interface to the network. Underlying details such as “router”, or “switch”, or “topology” can be a distraction they desire to abstract and simplify away.
- Equipment Vendors: want a stable forum to interwork a plethora of Application interfaces with a plethora of nascent Network Device programmatic interfaces.
OpenDaylight members understand Read More »
After our Open Network Environment (Cisco ONE) announcement at Cisco live!, where we unveiled our strategy for network programmability, Jim Duffy at NetworkWorld had a very interesting article that asks a key question, “What are the killer apps for software defined networks?” While SDN technology is very exciting and holds a great deal of promise, the answer to that question will ultimately determine how quickly it is adopted and by who. The consensus is that network virtualization or virtual network overlays are one of the early killer apps that software defined networks can certainly enable (when coupled with other technologies), which is exactly why Cisco made virtual overlays one of the three solution pillars of its ONE announcement. As I mentioned in my TechwiseTV video on virtual overlays, the primary use case for SDN/OpenFlow research in universities is also campus network slicing or creating virtual network partitions for test and production environments, e.g., to share a physical network. As noted in Duffy’s article, virtual overlays can be done with or without OpenFlow.
In the aftermath of a major launch, after reading the press and analyst coverage of the news, I always ask what we could have made clearer, what could have been highlighted better, or how could we have made the complexity of some of the details easier to understand. One such point that probably could have been clarified is just how “open” the Open Network Environment (what’s in a name anyway?). Specifically, regarding our Nexus 1000V virtual overlay framework, there were some comments and questions about how open and interoperable this overlay framework was, especially compared to other vendors touting programmable overlays. One financial analyst firm even stated that our overlay networks had some great advantages, but only worked with Cisco switches. Read More »