{"id":668,"date":"2013-06-25T14:49:22","date_gmt":"2013-06-25T14:49:22","guid":{"rendered":"http:\/\/www.upgrademag.com\/web\/?p=668"},"modified":"2013-06-25T14:49:22","modified_gmt":"2013-06-25T14:49:22","slug":"following-the-openflow","status":"publish","type":"post","link":"http:\/\/www.upgrademag.com\/web\/2013\/06\/25\/following-the-openflow\/","title":{"rendered":"Following the OpenFlow"},"content":{"rendered":"

This is an exciting time for networking. Perhaps more exciting than anything ONF Executive Director Dan Pitt has ever experienced since those early days in his career when everything seemed exciting. At least, that\u2019s what he claimed in his recent keynote speech at the SDN & OpenFlow APAC Congress in Singapore.<\/em><\/p>\n

\"Dan<\/a><\/p>\n

\u201cI lived through the LAN revolution,\u201d Dan went on \u201cTCP\/IP and the Internet, optical networking and the dotcom bubble \u2013 then the bursting of that bubble. After that I kept out of networking for a few years and was glad to be away from it\u201d.<\/p>\n

Then, about three years ago, Professor Nick McKeown from Stanford and Professor Scott Shenker from Berkeley rang him saying: \u201cDan, we need you. We have a job for you. It\u2019s in networking”. Dan replied: \u201cI’m done with networking\u201d and they came back: \u201cBut it\u2019s different now, it’s changed.” That was when he first heard about the proposed Open Networking Foundation (ONF).<\/p>\n

At first Dan was very sceptical, but they wooed him until finally he gave in. Since the forum\u2019s launch on March 21st, 2011, the ONF Executive Director position has been his full-time job: \u201cWe’ve only been going a couple of years, but it really is changing the way we do networking. It\u2019ll never go back\u201d.<\/p>\n

Software-Defined Networking<\/strong><\/p>\n

What brought networking back to life for Dan was the concept of Software-Defined Networking (SDN), being developed in academia at that time. There are many definitions and flavors of SDN but the common core in today\u2019s understanding of the term lies in the physical separation of control and forwarding \u2013 Fig 1.<\/p>\n

\"Figure<\/a><\/p>\n

The network is given a control plane distinct from the data plane carrying the network traffic, and this control plane can host applications that allow centralized control and shaping of the network. So any one instance of network control can oversee multiple instances of forwarding. Effectively it allows the network to be virtualized so that the same fixed physical wiring structure now has the flexibility to host any number of different data flow patterns.<\/p>\n

Some protocol is needed to communicate between these two planes. To save market fragmentation and all the problems that arise, it was decided that the protocol should be a common global standard and not tied to any one company. The vendor-agnostic protocol under development at Stanford, and inherited by the newly formed ONF, was called OpenFlow \u2013 formalised as OpenFlow 1.0, and since then we have had versions 1.1, 1.2, and 1.3.<\/p>\n

The growing availability of OpenFlow-enabled switches and controllers allows the network to be centrally programmed. Policy, security, performance, and compliance decisions can be incorporated into the path determination and the controller will transmit them from the control plane to the switches. These switches need only obey instructions, instead of making decisions themselves, resulting in the use of simpler, less intelligent switches across the network.<\/p>\n

Today\u2019s market drivers<\/strong><\/p>\n

Dan reckons the SDN revolution could in theory have happened 15 years ago. He was working on something similar at the time, but it was way premature: \u201cThe company wasn’t ready, the market wasn\u2019t ready, and the technology wasn’t ready \u2013 we didn’t even have virtualisation in the computing space, let alone the networks.\u201d<\/p>\n

Compare that time with now, with the number of virtual machines already over six times the number of servers and increasing at 7% CAGR \u2013 Fig 2. Back then it was 100MB Ethernet, while this year 10GbE is set to overtake 1GbE and is rising fast \u2013 Fig 3.<\/p>\n

\"Figure<\/a><\/p>\n

\"Figure<\/a><\/p>\n

 <\/p>\n

Increasing VM density and link bandwidth are two of the prime drivers for software-defined networking, according to Dan, and another fertile ground for SDN is public and private cloud computing at over 18% CAGR. Growth rates predicted for mobile video are even more spectacular \u2013 Fig 4. Dan says: \u201cIt’s a nightmare trying to manage these traffic flows if you’re an operator\u201d. Traffic is soaring while revenues are flat \u2013 so some dramatic solution is needed to keep the operators in business.<\/p>\n

\"Figure<\/a><\/p>\n

Other factors favoring the growth of SDN, according to Dan, are the availability of ever higher performance merchant silicon to power Ethernet switches, the spread of distributed systems, and: \u201cthe whole phenomenon of open source\u201d. According to Dan: \u201cIf you’re running a network, either in an enterprise or as a provider, there are really only two things that SDN can do for you: it can help you save money and it can help you make money\u201d.<\/p>\n

As to saving money: there has been a lot made of the potential saving from this use of cheaper, dumber switches across the network, to the extent that people have raised concern that OpenFlow could commoditize the industry at the expense of certain big switch vendors. This, according to Dan, misses the real point, which is the OpEx rather than the CapEx saving: \u201cIt’s the introduction of automation that will bring about the operational expense savings. What’s most exciting is to be able to offer new services at very high velocity and with less administrative overhead \u2013 as fast as you can write software, you can introduce new services\u201d.<\/p>\n

ONF today
\n<\/strong>
\nSo, what does the head of the ONF have to say about the ONF\u2019s progress over the past two years?<\/p>\n

Dan emphasizes that the true goal of the ONF was not to churn out standards or pump up membership, but rather to promote the commercial success of SDN for the benefit of users: \u201cWe started the commercialization of OpenFlow by making it industrial strength \u2013 what we inherited from Stanford was not very industrial strength. Our aim is to promote SDN as a whole \u2013 OpenFlow is just a foundation and all the great things you can do are above that.\u201d<\/p>\n

On the question of standards he mentioned a number of important liaisons with organisations including standards bodies: IEEE, ITU, OIF, MEF, IETF, TMForum, ON User Group, and US Ignite. He went on: \u201cYes, we do create standards but we\u2019re not a typical standards organisation. Because once you’ve got the foundation in place \u2013 you have the control plane and the switches \u2013 then software standards (for interfacing to applications above) are best determined in the marketplace because they are easily modified. We feel strongly about this southbound interface from the control plane being the OpenFlow protocol, because all it does is convey flow information down and network statistics up. It’s simple and broadly applicable, so let’s get it sorted and move on. We strongly advocate experimentation, writing code \u2013 and open source wherever possible\u201d.<\/p>\n

Looking to the next 12 months, Dan outlined some of the key events and aims: \u201cWe have probably about 1100 participants involved in our discussions, specifications, and guidelines\u201d. The main pillars are the eight currently active ONF workgroups, covering: Architecture and Framework, Configuration and Management, Extensibility, Forwarding Abstractions, Market Education, Migration, Optical Transport, and Testing and Interoperability. Then there are the less formal Discussion Group forums including: Security, Skills Certification, Wireless Transport, and a Japanese-language forum.<\/p>\n

As ONF has already developed and released OpenFlow 1.2 to 1.3.2, versions 1.4 and 1.5 are expected before the end of 2014. Work continues on the security of the OpenFlow protocol as well as on the security capabilities from using the protocol. Configuration management specifications have already been issued and further work is being carried out on OAM (operations, administration, and maintenance). Optical transport and the discussion group on wireless transport and mobility are the newest additions to the program \u2013 and they have their sights set on using OpenFlow protocol not just to switch ports but for things like switching frequencies, wavelengths, or actual fibres.<\/p>\n

In response to those early rumors that OpenFlow was just an ivory tower academic exercise, Dan emphasizes ONF\u2019s practical, down to earth focus: \u201cWe are an organisation really driven by users. We have nearly 100 diverse members but our board consists purely of major users \u2013 telecom or major data center operators \u2013 and Goldman Sachs representing enterprises. It’s an impressive community and we’re consciously trying to bring to market solutions that are implementable, that will be deployed. It’s an exciting community \u2013 the network operators are in charge here, and their requirements are what the vendors listen to\u201d.<\/p>\n

Outreach programs<\/strong><\/p>\n

As well as leading this internal work on OpenFlow, ONF is looking outwards to encourage implementation and deployment of SDN: \u201cWe’re not just into paper standards, we want products and services to be available, so we’re hosting \u2018plug fests\u2019 where vendors get together with all their controllers, switches, clients, and features to make sure they interoperate. We have one going on now at Indiana University’s InCNTRE lab with about 50 people representing 20 companies hammering out their implementation details\u201d.<\/p>\n

Work on conformance testing has also been started, encouraging independent test laboratories to join in: \u201cWe develop test cases and release them to the world. Anyone can offer conformance testing and we\u2019ll sanction their laboratories to join the certification program that we govern\u201d. Meanwhile the Migration Working Group is focusing on ways to speed and simplify migration with a clear roadmap for operators: \u201chow to get there smoothly without ending up in some blind alley\u201d.<\/p>\n

An important part of this thrust lies in strategic collaborations with other organisations. Dan mentioned: Open Compute Project, ON.Lab, SDN Central, Open Data Center Alliance, OpenStack, and ETSI NFV.<\/p>\n

Fostering a chipset and hardware ecosystem<\/strong><\/p>\n

A further ONF outreach project is to extend the SDN ecosystem to include not just hypervisor solutions but also hardware-based solutions. To help foster a supply chain for both chips and hardware, the Forwarding Abstractions Working Group is looking at Table Typing Patterns to use existing chips to implement the multiple table structure of OpenFlow, and discussions are being held in the new Chipmakers Advisory Board on ways that merchant silicon might evolve to better support OpenFlow.<\/p>\n

ONF is collaborating with Facebook and the Open Compute Project, on an open source hardware design for an OpenFlow switch. This was announced at InterOp in Las Vegas: \u201cIt\u2019s been done for servers and for storage, and now we’re encouraging them to do it for network switches. We’re seeing a transformation of the industry: from selling hardware and giving away software to the other way round. So in the future they\u2019ll sell the software and you can find a box to run it on yourself, as they are not into selling boxes. This will be a gradual change but a fundamental one for the industry\u201d.<\/p>\n

By the way: if you are looking at overlay solutions \u2013 virtualisation at the edges \u2013 Dan\u2019s opinion is that it\u2019s just a temporary fix: \u201cokay for a start but the real work has to be done in the core\u201d.<\/p>\n

Promoting innovation \u2013 the driver competition<\/strong><\/p>\n

ONF is actively supporting services above OpenFlow: \u201cwhere service value comes in. We\u2019re putting hooks in the OpenFlow substrate to give the network more capability to support things like network function virtualization and Layers 4 to 7\u201d.<\/p>\n

ONF has plenty on its hands, and wants to encourage more people to join in the work by encouraging innovation in this field. Academic researchers and independent laboratories are already on the job, and the latest drive is to launch a public competition worldwide for an open source OpenFlow driver \u2013 while freeing up developers to focus on the value-adding work.<\/p>\n

What\u2019s needed, says Dan, is: \u201cJust a little plug-in for the controller \u2013 with its equivalent piece in the switch. It’ll be something that everyone can build around, and it will easily adapt to the evolution of OpenFlow protocol\u201d.<\/p>\n

Anyone can pitch in \u2013 an individual or a team \u2013 for a chance to win the $50,000 prize, with submissions by August 15th and the winner being decided by September 30th \u2013 see https:\/\/www.opennetworking.org\/competition<\/a> for full details.<\/p>\n

Conclusion<\/strong><\/p>\n

There\u2019s a lot of hype and a wide divergence of opinion about SDN currently, so it is good to get back towards the source and listen to the head of the organisation behind the current SDN drive. Dan Pitt, ONF Executive Director, summed up his message as follows:<\/p>\n

\u201cSoftware-Defined Networking is about programming networks. When we look back in 5 years we\u2019ll say \u2018how did we ever manage without it?\u2019 It’s definitely happened: industry has already invested widely in its product development, in hardware, in open source software, in trials, in proofs of concept, and in actual services.<\/p>\n

\u201cAt this point I would say that ALL the incumbent networking vendors are implementing OpenFlow \u2013 and I predict that in 2 years time you will not be able to buy an Ethernet switch that is not OpenFlow enabled, as it\u2019s just so easy to add\u201d.<\/p>\n","protected":false},"excerpt":{"rendered":"

Dan Pitt on the current state of tomorrow\u2019s networks.<\/p>\n","protected":false},"author":7,"featured_media":672,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15,26,18],"tags":[185,186,235,188],"class_list":["post-668","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-business","category-opinions","category-white-papers","tag-open-networking-foundation","tag-openflow","tag-sdn","tag-software-defined-networking"],"_links":{"self":[{"href":"http:\/\/www.upgrademag.com\/web\/wp-json\/wp\/v2\/posts\/668","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.upgrademag.com\/web\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.upgrademag.com\/web\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.upgrademag.com\/web\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"http:\/\/www.upgrademag.com\/web\/wp-json\/wp\/v2\/comments?post=668"}],"version-history":[{"count":0,"href":"http:\/\/www.upgrademag.com\/web\/wp-json\/wp\/v2\/posts\/668\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/www.upgrademag.com\/web\/wp-json\/wp\/v2\/media\/672"}],"wp:attachment":[{"href":"http:\/\/www.upgrademag.com\/web\/wp-json\/wp\/v2\/media?parent=668"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.upgrademag.com\/web\/wp-json\/wp\/v2\/categories?post=668"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.upgrademag.com\/web\/wp-json\/wp\/v2\/tags?post=668"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}