One of the objections raised about OpenFlow is that it doesnt inter-work with "legacy" IP networks.
As with most sales objections, there is often some truth in these objections and also fear, uncertainty and doubt (FUD) spread by competitors that have something to lose.
So what does the word "interworking" actually mean? In order to answer that question, lets return to basics.
The world is full of IP networking equipment. In fact thee human race has become dependent on the Internet. It would be impossible to build a parallel OpenFlow network and have a big bang switch over on a particular date and time. Lets also be realistic - legacy IP networking does a reasonable job. The business case of ripping it out and replacing it with OpenFlow doesnt make sense if we apply it on a ubiquitous basis.
At least initially, OpenFlow is being deployed in very specific locations to solve particular problems. I am very familiar with mobile network architectures and in the core network (if you are familiar with the terminology, the Gi network) is where OpenFlow will deliver simplicity, elegance and flexibility for mobile operators and remove the mountain of different boxes which are attempting to control user policy whereas in a mobile feeder network, there are little gains to be made - at least today. (This would be the Iu network before the SGSN if you are familiar with the terminology). So here OpenFlow has a sweet spot. It is likely that OpenFlow adoption will be on the periphery - places where the legacy technology is struggling or where it's a square peg in a round hole - in other words there are lots of boxes to do work-arounds.
Google actively uses OpenFlow in live operations. If OpenFlow doesn't interwork then surely we wouldn't be able to use Google!
In my experience, there are real challenges getting legacy IP equipment to interwork. I don't mean interworking between different vendors. I've seen network engineers struggle to get a Cisco box to talk with another Cisco box simply because one had a different software version! Interworking challenges are simply part of the world of networking.
So let's look a little closer at OpenFlow. There are 2 types of interfaces: data and control. Whereas on a legacy router, the control is usually embedded in with the data. One of the key differences is that OpenFlow separates out the data plane from the control plane.
So if you have an OpenFlow switch and we look at the data plane interfaces, they will probably be Ethernet. They will support the IP protocol and the box will forward packets from one port to another. So far no difference to a legacy switch or router so no challenges for interworking here. At least on first sight.
So what is this control I'm referring to? Control is the decision making how a packet is routed from A to B. In legacy networking there are a few ways to do this.
- Broadcast or flooding
- Someone manually configures it
- It is automatically discovered
Next someone manually programmes the equipment saying this address or address range can be reached down here. Humans tend to make mistakes so traffic might be routed down a black-hole. Also the Internet is constantly changing so it's again not a scalable approach.
Finally we have discovery. Legacy IP equipment uses a variety of protocols to discover and advertise routing information. Protocols such as ARP, RIP, OSPF, BGP.
These protocols form the control and routers make their own decisions based on this routing information.
OpenFlow however relies on a "central" intelligence to make routing decisions. When a packet arrives at an OpenFlow switch, if it hasnt been programmed, the switch doesnt know what to do with it. (A legacy router will have the same issue unless it has been configured and gathered routing information.) The OpenFLow switch therefore sends a message via the control interface to a controller and says "I've got this packet - what do you want me to do with it?". Controllers are programmable. It is therefore possible to write a controller that behaves identically to a legacy router. The only difference is there is either a logical or maybe a physical separation between the control and the data plane compared to a legacy router.
So if we can develop an OpenFlow switch controller combination that is conceptually identical to a legacy switch, interworking issues are clearly being overstated!
However it doesnt make sense to go to all the trouble of creating OpenFlow to only do what a legacy router does - it wouldnt create the shift away from a box driven networking industry!
Todays legacy IP networks are in-fact islands. There are lots of fancy terms like routing domains and "autonomous systems" for these islands. The internet is not a single thing - it is a collection of networks where each network has it's own controls.
This is an important concept and it is one that will continue. To achieve interworking between legacy networks and OpenFlow networks we need islands. It is the joining point between islands where the challenges and complexities lie. So at the demarcation point between a legacy network, the gateway router may be talking to the OpenFlow switch using OSPF, where it is advertising what networks it can reach. The OpenFlow switch at the border needs to participate in this discussion.
If look at the last sentence, it isn't 100% true. The OpenFlow switch can in fact be pretty dumb. When an OSPF packet arrives from the legacy router, it can adopt the approach of forwarding it to the controller and asking what to do with it. It is the controller, using software, that can decide how to interact with the legacy router by programming the OpenFlow switch.
So interworking with legacy networks is not an insoluble problem. It does require some thought, planning and intelligence but these are skills that you need in legacy networks anyway!
No comments:
Post a Comment