Just when it appears that you've got everything figured out, technology has a way of throwing you a curve ball. The curve balls can throw away conventional wisdom built up over years virtually overnight. These changes are many times the actions of a "beast" that has been unleashed unknowingly and will eventually change everything. The beast changed the world of computing and now the question is will a new beast kill traditional core routing approaches and change network architecture?
Let's start with the traditional example – the beat that changed computers. Once upon a time, computers were measured in tons and kilowatts and each design's total production was measured in at most in the tens of thousands of units. Then, the beast was unleashed. At the same time IBM was producing a very successful line of mainframe computers, an almost aside operation created albeit not the first ever personal computer, but the first personal computer that did not sell just in the thousands but sold in the millions. The beast unleashed here was the production of millions of microprocessors. Because tremendous production volume and the demand for more and more performance, this beast rapidly transformed where computing power was found. No longer was it found in the single computer behind the glass window or even in the computer room of a department, this beast was now everywhere. And everywhere meant that economy of scale and the huge revenue opportunity for producing faster and better processors started a real exponential ride.
This beast destroyed empires that could not rapidly adapt. Examples include DEC, Data General, CDC, and many others. Other that could, like IBM, changed both the technology of their mainframes (from ECL to CMOS) and the entire direction of the company.
Today, each of us has more than a supercomputer of the recent past on our desk or laps that cost only a few hundred of dollars. If we now turn our attention to data networking, is there a beast and if yes what and where is it? If we draw a parallel to computing, I contend it is the data networking core. Consisting primarily of large routers, these "mainframe" routers cost hundreds of thousands of dollars – millions when fully populated, just like the old mainframes and moreover, are in production runs of a few thousand units.
It seems pretty clear that Ethernet technology is the beast. Most people are familiar with the Ethernet technology that is used to connect computers to a LAN – and more importantly the fact that you can go to a local office supply or computer store and buy hubs and switches right off the shelf. With 1 Gbps interfaces costing tens of dollars and 10 Gbps interfaces costing around two thousand dollars, this technology beast has dropped the cost of communications equipment dramatically. So if this is the beast, what does is replace? Well, the simple fact is, as I discussed in an earlier post, the cost of an Ethernet port on a carrier-class switch is almost 30-80 times cheaper than the equivalent 10G SONET-based port and almost 10-50 times less expensive than routers with 10G Ethernet interfaces.
So, what does this mean? With the huge increase in bandwidth needs for Internet and enterprise network services, is the current router-based architecture the best way to go? If we draw the conclusion from the computer analogy above, there are hundreds of thousands, if not millions, of high-performance Ethernet switches being sold, as compared to most likely two orders of magnitude fewer large-scale carrier routers. Again, just like in the computer microprocessor example massive production and standards drove increased performance and features that now serve everything from the laptop to the server room (and supercomputers). Will the Ethernet beast run down the same path? Does it really have the right environment to be game changing?
Well, there are several factors. Just like there is competition on price and performance for processors, there is the same competition on the high-volume fundamental chipsets for Ethernet interfaces and switching. Of course, this is not the entire story, but with incredible performance of embedded processors and open source software all the elements are place.
This complete environment of high-performance cheap fundamental switching hardware, high performance processing for higher-level protocols, and open source software for many of the protocols required for an Ethernet switch (and features for routers as well) is now available. Although at one time, open source software was not looked on too warmly by industry, commercial enterprises that have productized open source material and provide traditional software support functions have changed this attitude, and open source is now becoming viewed as being able to support mission critical functions.
The dramatic combination of available hardware and software is the new reality that may have profound and dramatic impact on the current approach to carrier-class MPLS services. Why is this true? In short, it is the need to cost effectively scale. The largest routers today, if we restrict ourselves to a single standard rack, have approximately 160 10G Ethernet ports. The largest and most dense Ethernet switches can be stacked to provide almost 300 or more 10G Ethernet ports in the same space and with much less power consumption (so, as with almost everything, there is a green angle to this as well). Of course, we have to ask the question of whether these switches will have the stability and software features to build carrier-class infrastructure.
The argument that they will is pretty simple. When computer manufacturers believed that microprocessors were toys because of word size or lack or memory management features, and rudimentary operating systems, it did not take very long until microprocessors were the guts of not only laptops and desktops, but mainframe computers as well with all the needed features and more. In the Ethernet world, it is going to be a lot easier to continue to upgrade Ethernet switches with features such as MPLS Fast-ReRoute (FRR) and VRF features for VPNs that will rival and then supplant traditional router approaches. This environment will also will enable new approaches, such as flow-based Layer 2 routing protocols, per flow authorization for security, and others.
In fact, with research projects such as Clean Slate Internet at Stanford University and the National Science Foundation’s Global Environment for Network Innovations (GENI), there are researchers all around the country that are in a position to take these hardware and software tools and create new components and new models for Internet services.
The battle of the LAN was won by Ethernet, the battle of the Edge is being won by Ethernet, so how far away is the battle for the core of the network? In fact it has already begun and for those whose network core router cheese is based on an old-style computer mainframe approach, it may move faster than you think. What will it do to networking equipment manufacturers? And, what will it do to network service providers?
1 comment:
June 23 --
I'm sitting in a tutorial on Carrier Ethernet by Cisco. Its a great tutorial, extremely well presented and with great technical depth.
It leaves me wondering if the battle for the edge is over and whether Ethernet switching has already lost in the core. The Metro Ethernet Forum seeks to simplify service offerings and ensure consistent architectures. Yet, in implementation, things get complicated.
For example, when considering residential access models, you have dozens of options to consider. Bridged vs routed; trunk vs non-trunk; EVCs support 1:1 or n:1; and so many more. When this gets replicated in a real network, how does a carrier choose to implement services? What are the cost, feature, and reliability trade offs? They aren't clear to me. Guess I need to do more study.
And then, configuration and operation isn't what any body expects. It is niether familiar to a bell head or data geek mentality; and it is very complicated. Despite the efforts to produce OAM improvements, fault and performance management cannot be trivial.
I think some implementation maturity is due before we declare Ethernet has "won".
Steve G.
Post a Comment