OpenFlow Will Change Network Architecture
Big Switch Networks co-founder Kyle Forster says the new technology finally will let IT departments make the network fit the org chart.
May 11, 2011
![Network Computing logo Network Computing logo](https://eu-images.contentstack.com/v3/assets/bltde8121fc52c5c8f3/blt3f3d0318f746b1c2/65a530e4187606040a1d8b8c/placeholder.png?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
InformationWeek Interop Digital Supplement - May 2011
![InformationWeek Green InformationWeek Green](https://twimgs.com/infoweek/graphics_library/misc/Green_leaf_88x88.jpg?width=700&auto=webp&quality=80&disable=upscale)
InformationWeek Green
Download the entire May 2011 InformationWeek Interop digital supplement, distributed in an all-digital format as part of our Green Initiative(Registration required.)
We will plant a tree for each of the first 5,000 downloads.
Kyle Forster
Forget cloud and consumerization. The buzz among the tech cognoscenti at Interop 2011 in Las Vegas, a UBM TechWeb event, is OpenFlow, and when you think OpenFlow, you think Big Switch Networks. At least that’s the hope of Big Switch co-founder Kyle Forster. We sat down with Forster as Interop was kicking off.
InformationWeek: Tell us about Big Switch.
Kyle Forster: The company is a new startup. We're building products based on OpenFlow. We believe that OpenFlow does three things. Well, let me say that differently. OpenFlow does three things that traditional networking can't do, or can't do easily: virtualization, advanced forwarding, and programmability. And for us, we're really focused on the virtualization piece. So we're building a software platform for network virtualization, targeted at the enterprise data center and campus LAN.
That's sort of the company side of it. We recently got our A-round financing, so the company is sort of hitting this inflection point, starting to grow like crazy. We're just about a year and a half old. I'm one of the two co-founders. My co-founder, Guido [Appenzeller], and I are friends from grad school. We've always kept in touch. We've tried to recruit each other back and forth a couple of times. And about a year and a half ago or so, I was moving back to the Bay area and I went out to lunch with him … and we started talking about his research. He'd been working on OpenFlow at that point for two and a half years, give or take.
He led the engineering team that published at Stanford the OpenFlow 1.0 spec. We started talking about this thing. He was incredibly proud of it, really enamored by it. Kept talking about it. I was trying to help him out with some of my experience from Cisco that I thought would work in the market, and we went from basically an every-couple-of-weeks lunch to a once-a-week lunch. I downloaded the open source piece that he was working on and got something up and running myself, and that, for me, was the eye-opener. In 48 hours I had this sort of interesting little thing--far from a product, but it's something that I could kind of see using on a day-to-day basis, as a fingerprinting app to tell you what operating systems are coming on a network. It solved some of the really hard, intractable problems that I saw when I was at Cisco easily and so elegantly. My plan was never to do a startup. I had a couple of job offers at Cisco, I had an offer at Juniper, I was absolutely doing that. But it was just one of those things I couldn't pass up. So he left Stanford in March, we closed our seed funding in April, we posted in May, had our first prototype out in basically midsummer.
InformationWeek: Can you give us the basics on OpenFlow?
Forster: The place where I would start is, there's OpenFlow the protocol, and there's OpenFlow the architecture. The best metaphor that I give is that OpenFlow looks a lot like the x86 instruction set. By itself, that doesn't do a whole lot without a lot of very manual programming. So it sort of comes from kind of a humble start. The [OpenFlow] architecture looks like the x86 instruction set, plus a whole series of applications on top, plus an entire programming language for you to do whatever else you want that you can't happen to find already. But the really interesting part is where the OpenFlow architecture is going, and we think that this year’s Interop is going to be a big coming-out party for an awful lot of this stuff.
As we look at OpenFlow architectures, there are three really interesting pieces. A few of them are trying to do what switching and routing can do today. I don't think those are going to last all that long. The ones that really bring something new, I think, are doing three new things: They're doing virtualization, so we have our own particular take on virtualization. I think everybody that gets into this starts saying, "Wow, there's a either multi-tenant or multi-team story here with OpenFlow, and we can do this in a way that's hard to do otherwise." There's advance forwarding. Networks don't look like trees anymore. In the campus LAN you simply see more and more funky devices that don't have traditional operating systems that move around. And in the data center you just see the need for non-tree topologies, as with virtual machines that move around. So there's a sort of advanced forwarding component, and we believe the state-of-the-art OpenFlow architectures are going to have some form of advance forwarding that gets rid of spanning tree, a big advance for the industry overall if we can really get that in the market.And the third piece is progammability. I think some of this is just the period in history when these things are coming out, but suddenly we have a REST API into the network. It's incredibly simple.
I'm assuming the other vendors that come through here are going to have something sort of similar. But a highlight is these incredibly simple APIs that you can start tying to your applications. You know, rather than doing Radius Soft you can go directly to Active Directory. Really simple. Hey, I have a machine inventory. I also have vCenter. Can I just tie my network directly to vCenter? You kind of tie this thing to other applications in the environment.
These three things are going to unlock a lot of value around things that the network could do today, except that the current architecture is really hard. I think if you look at where the OpenFlow architecture is going to land, it's going to be those three things: virtualization, advanced forwarding, programmability.
InformationWeek: So what's your thought about Cisco embracing OpenFlow?
Forster: I'm very proud of my alma mater. Certainly if [Cisco] can find a path here where it's really advantageous to them--and I believe that path is there--they could play in a much larger ecosystem. And having Cisco in an ecosystem of vendors would certainly be spectacular for the OpenFlow industry. We'd be the first one popping bottles of champagne. It would be a great thing. Whether or not they do something that plays with the ecosystem is a different question.
InformationWeek: One equipment vendor recently pointed out that OpenFlow has the potential to take equipment and just commoditize it so that it's no longer relevant what switch you have. So what does a Cisco, HP, or Force10 do to differentiate its edge gear, or any networking equipment?
Forster: I love that question, because I was the product manager of a couple of lines of Cisco's wireless LAN controllers, and with wireless LAN there was this huge debate when we came out with controllers that we're just going to commoditize the [access points]. APs are going to disappear to zero overnight. And over the three years’ worth of data that I had access to, after we bought Airespace and launched controllers, we saw that AP prices on average went up, and AP margins on average went up, not down.
Now, I don't know what's happened after that. You could argue it's just a point in time, but if wireless LAN controllers and APs just did the exact same thing that common access points did before, then absolutely margins would have gone down and they would have commoditized the APs, but they didn't. Whether it was rogue detection, whether it was with respect to intelligence, whether it was guest access--we had this whole laundry list of really, really good features that ultimately customers are willing to pay a lot more for. And they couldn't care less whether [the functionality was in] the AP or the controller, but the fact is that from a technical architecture, we couldn't do it without the controller.
So when I look at OpenFlow, I see the exact same thing. Look, if we're using OpenFlow controllers and switches to do stuff that switches do today, this is going to commoditize switching. The real opportunity is to make the network do more than what it does today, and if you do more than what it does today, then I believe that margins will stay just fine and in fact could go up, because we'll just make the stuff more useful. Generally enterprises don't get the most out of their equipment today, and if we can unlock some of that latent potential, then I think actually the opposite could happen.
InformationWeek: But in the wireless controller market, you bought your controller and APs from the same vendor, so a lot of that stuff you're talking about--the advanced features, the guest access, the fingerprinting--was built into the system. Whereas with OpenFlow, potentially I could have a controller from Big Switch and switches from HP, Extreme, Juniper, whoever, and once I put that controller out there and give it an IP address, I can do all my networking, configurations, and monitoring through Big Switch.
Forster: So let me add one more layer on the stack and then I'll loop to it. There are three layers here: There are switches; there are controllers, which effectively just marshal switch resources; and then there are the really interesting part: applications. This isn't part of the OpenFlow protocol, but it is part of every OpenFlow vendor architecture that we're looking at. You have a layer of applications on top, and these are sort of pluggable components, and you sort of fiddle with them and get them to work together, but ultimately the vision here is that you'd actually buy your components from a lot different vendors and stitch them together yourself, so you can do a best-of-breed type of thing.
Or, given the complexity of this whole stack up and down, my guess is there will be two directions. The folks that go best of breed, they're going to have access to equipment at very different price points from everybody else because they're going to be willing to play with some crazy stuff out there. We already see open source controllers--we're launching an open source controller. We're launching a core suite of apps that are going to be open source.Then the other branch is going to be folks who just say, "Look, I see the functionality. I love it. I want all that functionality. But I also want one throat to choke. I want somebody to wrap it all up as a solution, and I want to buy this all from one brand." I don't think we're just talking about networking. When we look at this model, what they buy may actually include computers as well. It may actually include storage. I kind of think that's the long-term trend here.
So realistically I think we're going to see two branches, and one branch fits the exact market dynamics that you're talking about. The other branch says, "Hey, I want to buy a solution that's entirely in a box, validated," and I think there's going to be a lot of margin there.
InformationWeek: So hardware vendors shouldn’t worry about the “white box” effect?
Forster: I think they need to worry about it. They can react it in one of two ways: You can either try to play defense, or you can try to play offense. I'm absolutely offense. I'm coming out and thinking really hard and pushing engineering teams to come out with innovative features that just make networks work better for customers, make them do more and work better. If you're really pushing hard in that direction, then I don't think anybody has anything to fear. If you play defense, then you should be really worried. And I don't think that's new. That to me is a very old story that we're seeing playing out again here.
InformationWeek: Let’s talk about the Open Networking Foundation. Traditional standards groups like the ITF and IEEE are open--customers and enterprises can go to the meetings and participate, but most of the contributors are vendors, because vendors have a vested interest in making standards work. Is the ONF going to bring the customer organization back into the standards process?
Forster: Yes. I think we touched on this a tiny bit in our last conversation. The networking industry has had a lot of competitors to ITF. I think of the ATM Forum as being one of the more successful ones because it did involve customers up front. ITF had customers at the very, very early days--at a very different period in history when there was way less money involved! I think that ONF has a wonderful opportunity at longevity. I think to do that they need to keep the customer voice very strong and very representative of the entire customer base of OpenFlow. When I speak from the vendor side, if the voice of the customer--the voice of my customer--is very, very strong on that body, then we're going to pay attention. It's when they lose that customer voice that we just have less and less incentive to follow.
InformationWeek: So for enterprise IT pros, how will your company in particular and OpenFlow in general make their lives better?
Forster: For OpenFlow, we have this sense of, hey, take three ports from here, two ports from here, five ports from over here, basically all these switch ports from all across a very complex network. An architect would come through and pull these ports and carefully connect them. But then, they can wrap them up and delegate them out to an administrator who sees this as just one switch. And that's where the name of the company comes from, because it could be 1,000 ports from here, these 25 ports, and suddenly we have a 1,025-port switch. So for us, it's this sort of two-view thing where we have, OK, one person who sort of knows the physical topology and constructs it very carefully, and then the other who, to be honest, just sees the network as one big switch. And that, I think, has the opportunity to really make life a lot easier.
Recommended Reading:
You May Also Like
Maximizing cloud potential: Building and operating an effective Cloud Center of Excellence (CCoE)
September 10, 2024Radical Automation of ITSM
September 19, 2024Maximizing Manufacturing Efficiency with Real-Time Production Monitoring
September 25, 2024