----
OpenDaylight Developer Spotlight: Curt Beckmann
// OpenDaylight blogs
The OpenDaylight community is comprised of leading technologists from around the globe who are working together to transform networking with open source. This blog series highlights the developers, users and researchers collaborating within OpenDaylight to build an open, common platform for SDN and NFV.
Curt Beckmann is the founding chair of the ONF's Forwarding Abstractions Working Group (FAWG), which works to make OpenFlow more scalable and interoperable. He also serves as a member of the ONF's Chipmakers' Advisory Board (CAB). Related to OpenFlow, Mr Beckmann contributes to the OpenDaylight SDN controller, where he is project leader for the Table Type Patterns project. Since being named Brocade's Chief Technology Architect for EMEA, Mr Beckmann is now based in Paris.
What project in OpenDaylight are you working on?
I'm the project lead for the Table Type Patterns (TTP) project. TTPs are an OpenFlow-related idea developed into a specification by the ONF's Forwarding Abstractions Working Group (FAWG), which I chair. TTPs were conceived as means for describing "abstract device models" that can map easily to a variety of broadly deployed physical networking devices (i.e. traditional switches and routers). A set of common and broadly supported "abstract models" (TTPs) will allow an SDN controller (like OpenDaylight) to abstract away the differences between physical devices. TTPs will simplify the development of the MD-SAL layer. Between TTPs and the MD-SAL, it will become much easier to write OpenFlow-enabled SDN applications without knowing (or limiting) what specific hardware the application will run on.
What do you hear most from users as a key reason they want SDN?
The key reason that I'm focused on is the original motivation for SDN, and NFV. That is customers-- especially the big buyers-- want the freedom to be able to buy or develop intelligent algorithms for controlling their networks without being constrained by the classic networking paradigms that assume that all of the control intelligence must reside inside the network devices. Now that industry attention has shifted toward SDN and NFV implementation, this early "meta" motivation isn't the reason that comes up in conversation as often as it used to.
What is NFV's relationship to SDN and how do you see them working together?
SDN is usually described as being about decoupling the control plane from the data plane. Typically this is described in physical terms, but the original motivation for this was actually in market terms. That is, the buyer wanted to be able to buy or develop control plane software without being constrained by classic data plane control interfaces. In short, traditional network devices are systems made of hardware and software, but the software is overly constrained to the hardware. The driver behind SDN was new demands on networks and new business models. Think of firms like Amazon, Google and Rackspace.
The rise of NFV was similar, in the sense that it is buyer-driven, but slightly different, being driven by a slightly different customer base. Telecomm and other similar service providers (SPs) have a wide variety of broadly distributed equipment. Like legacy network equipment, these boxes are a mix of hardware and software where much of the intelligence is in the software, and the two are tightly bound. Equipment vendors like to use innovation as a reason to replace boxes, but that is doubly painful for SPs because their business model is based on a long term amortization, and also because upgrades incur high operating costs. Often two people must load up a truck and drive to the equipment site (under a sidewalk or halfway up a cell tower) and do the replacement. So, similar to SDN advocates, SPs want to drive innovation in software (which can be upgraded remotely without trucks) while stretching hardware lifetimes for longer term amortization.
The linkage between SDN and NFV is that although complex NFV functions will be moved into VMs, something must still transport the traffic from the source to the VMs, between VMs, and from the VM to the destination. That transport layer must be orchestrated with the VMs. It's pretty clear that the transport layer is SDN.
How would you describe OpenDaylight to a developer interested in joining the community?
I regard OpenDaylight as the network operating system of the future, and as such it is central to the future of networking. SDN and NFV depend on a common, unifying platform in order to build a vibrant ecosystem. Consider that there are very many Unix-like operating systems, but there is really just one dominant open source version of Unix (with a number of highly compatible distributions). We need a single shared open source network OS as well.
Though clearly inspired at some level by the early OpenFlow controllers, ODL makes broad SDN adoption practical because it adds support for other southbound interfaces. That's vital for enabling real deployments early in the movement when many devices are not OpenFlow-capable (in part because OpenFlow is still maturing). In addition, ODL includes the MD-SAL concept, which is a big step forward in allowing the controller to abstract away hardware differences. (Like a compute-oriented operating system, ODL will need to provide good abstraction services to allow a variety of applications to run transparently on diverse hardware.)
What's the biggest challenge facing networking today? How will SDN and NFV resolve it?
The biggest challenge is that the traditional networking innovation model has been broken for some time. That model relies on standards bodies to mediate innovation, but standards bodies are not good for rapid innovation, particularly when the innovation is opposed by vested interests. Multiple innovation models are being proposed as replacements for that traditional model, but many are effectively proprietary schemes (though some are touted as open).
Only open SDN and NFV, the buyer-driven movements, are credible approaches for replacing the classic model, in part because they leverage open source, which rewards working code above all else. But where hardware is involved, open source software isn't quite enough, and so we also need some open standards, such as OpenFlow, to ensure that hardware devices are included in the new innovation paradigm.
But open SDN in particular faces the challenge (at least in the near term) of controlling a diverse array of networking hardware. This is the challenge that ODL's TTP project is particularly focused on tackling. In short, I see our work as being central to the success of the leading SDN controller.
I expect you've heard that inspiring perspective that the bricks you are laying will ultimately build a cathedral? I like to think that way, and it's not hard with this project. Since I believe that SDN will really depend on a common de facto standard controller (currently ODL), I see the TTP project as central to the long term success of SDN itself.
Any new developments to share related to your project?
The biggest news is that TTPs are quietly gaining a lot of traction. Broadcom has upgraded their OF-DPA project, which was inspired by the ONF's TTP development. Several other vendors are approaching the ONF FAWG team about TTPs that they are working on. A key tool provider is reaching out to FAWG to help create tools that will simplify the creation and use of new TTPs. FAWG has also just finished a white paper on the benefits of TTPs. The Lithium release will add several attractive features to the TTP project implementation, but these new features are much more interesting in the presence of a pool of interesting TTPs, so all these efforts are really very complementary.
What part of the world do you live in? Why there?
Last year I was fortunate to have the opportunity to relocate to Europe in part because the customer base for SDN and NFV is much more globally distributed than my firm's SDN/NFV expertise was. As part of an effort to address the mismatch, I was able to relocate to Paris in order to improve our connection with our EMEA customers. That's the business reason. On a personal level, I have long wanted to experience life outside the US, so this is a dream come true. It has already been very broadening to heart, mind and soul. For example, I had never visited the Normandy coast. Also, having joined the Paris march, "je suis Charlie" is a more meaningful for me than if I had just watched on television.
----
Shared via my feedly reader
Sent from my iPhone
No comments:
Post a Comment