Shulou(Shulou.com)06/02 Report--

This article is reproduced from the official account "Biao GE Shuo the World" (ID:bgstx001) on Wechat. Author: Li Zongbiao.

SDN,Software Defined Network, the software-defined network, has been in the ascendant in recent years. However, the author thinks that SDN also has a trend of getting worse and worse. Moreover, there is no consensus in the industry on what is meant by SDN. The author tries to sort out what SDN is!

I. the three main lines of SDN development

From the birth to the development of SDN, there are three key main lines.

The protagonist of the first main line is Stanford. In 2008, Professor Nick McKeown of Stanford University and others put forward the concept of OpenFlow, and based on the programmable characteristics that OpenFlow brings to the network, further put forward the concept of SDN (Software Defined Network, Software defined Network). In 2009, the concept of SDN was listed in the top ten cutting-edge technologies of Technology Review, and since then it has been widely recognized and strongly supported by academia and industry. In December 2009, the OpenFlow specification released a landmark version 1.0 that can be used for commercial products.

The protagonist of the second main line is Google. Google's B4 network SDN transformation, to the industry a huge injection of chicken blood. The transformation of Google is divided into three stages. The first phase was completed in the spring of 2010, the second phase was completed by mid-2011, and the third phase was completed in early 2012, with the entire B4 network fully switched to the OpenFlow network. After the transformation, the link bandwidth utilization has been increased more than 3 times, close to 100%. This brings indescribable shock and shock to the industry. The author thinks that SDN began to develop explosively, from then on!

The protagonist of the third main line is Cisco. In June 2012, Cisco launched the ONE (Open Network Environment) strategy. In April 2013, Cisco and other companies launched the Open Daylight open source organization to develop SDN controllers. The theme of both things at Cisco is to "redefine SDN". Before that, SDN was basically equated with Openflow. Cisco stops and says that SDN is not equal to Openflow, which we can see from the architecture of ONE and ODL, as shown in the following figure:

Figure 1 Cisco onePK architecture

Figure 2 ODL architecture

Figure 1 is "onePK (One Platform Kit)" to support Cisco's ONE strategy. Figure 2 shows the architecture of ODL. For these architectures, we only need to pay attention to the red box in the picture. OnePK red box part, are all Cisco equipment, Cisco means: my home equipment is SDN, I will give you an API (onePK) on the line. The red box of ODL means that the protocol of SDN, besides OpenFlow, can also be other protocols (NETCONF, BGP, etc.)

These three main lines are very interesting. Stanford University (Professor Nick McKeown et al.) invented SDN in an attempt to redefine the network, Google pushed SDN to the first highlight, and Cisco wanted to turn SDN around and redefine SDN!

If Stanford University found a clear current, Google set off a huge wave, and Cisco is to muddy this pool of spring water!

(note: companies that founded ODL with Cisco are: IBM, Microsoft, Big Switch, Brocade, Citrix, Dell, Ericsson, Fujitsu, Intel, Juniper Networks, NEC, Hewlett-Packard, Red Hat and VMware)

II. The three major schools of SDN

Precisely speaking, the three main lines mentioned above have evolved into the three major schools of SDN.

1. Software-defined network element

We still use the naming method of SDN to name the software-defined network element: Softeware Defined Network Element (SDNE). Network element refers to these network devices, such as switches, routers and so on.

This school comes from OpenFlow of Stanford University. The concept of SDN proposed by Stanford University, based on the OpenFlow protocol, emphasizes the separation of the control plane from the forwarding plane, and emphasizes centralized control.

However, centralized control, the word, if stingy, its meaning is different.

One meaning is that the controller has the whole network in mind, do path planning / calculation based on this network, and then issue forwarding rules for each network element.

One meaning is that although a controller can manage (control) all (related) network elements in the entire network, there are only independent network elements in the controller, not a network. The controller is that each network element does its own exchange rule configuration. For example, br-ex and br-int in the compute nodes described in the Neutron implementation model.

Both of these meanings are that a controller manages (controls) all (related) network elements, that is, centralized control. However, the latter meaning is actually only the control of discrete individual network elements.

Software defined Network element (SDNE) belongs to the latter meaning. Due to the defects of OpenFlow's own protocol and the forwarding performance of related hardware, its application scenario is very limited. Now it is not mainstream to do SDNE based on OpenFlow (or other similar protocols). Either small companies / startups, or large companies are launching SDNE-related products in extremely limited scenarios.

The SDNE school, on the surface, inherits the pure status of SDN, but in fact it has tailored the orthodox SDN.

Although this school is not powerful, it is still the main force for the continuation of SDN incense in the industry.

2. Software-defined network management

Software-defined network management, Software Defined Network Management System,SDNMS. This genre stems from Cisco's so-called "redefining SDN". Cisco not only launches the ONE strategy, but also the whole ODL open source, although ODL open source claims to support OpenFlow, but the essence of Cisco is to make a package of traditional equipment, change a waistcoat, and transform it into SDN.

In other words, when the device is still that device, whether it is soft (VNF) or hard (PNF, traditional router / switch), what can its service distribution do except to make a configuration like a network management?

In a WeChat group, the author saw someone retweet an article, as shown in the following figure:

Fig. 3 SDN promotional materials of a factory

In this article, it declares that the controller is only responsible for business distribution, not for the calculation of forwarding table items. The calculation of forwarding table items is done using the standard BGP-EVPN protocol with high maturity.

This is a typical case in which the industry uses the network management as a controller as a SDN to publicize. Now this kind of voice in the industry is very loud and very mainstream. When they publicize, they also have a classical theory: the architecture of network management is not good, and the interface of network management is not abstract. It seems as if its architecture is very good and its interface is very abstract.)

We do not compare the network management and the so-called controller, whose architecture is good, whose interface is abstract.

We need to recognize one thing:

The two software systems do the same thing (function). Whether the architecture is good or bad and whether the interface is abstract or not is a matter of pure software design / development, which depends on the "people" who design and develop the system, rather than the name of SDN, the architecture can automatically improve.

This basic logic should be clear! If there is no such logic.

This mainstream voice in the industry has two terrible consequences: (1) ideologically, it has confused the concept of SDN; (2) in action, it has wasted a lot of manpower and material resources to do network management all over again.

For those companies / organizations that do not have network management products (such as some companies, such as most open source organizations), there is no problem to do network management again, because they do not have network management in the first place. And for those companies that already have giant network management products, this idea is fatal!

3. Software-defined network optimization

Software-defined network optimization, Software Defined Network Optimization,SDNO. The abbreviations of SDNO and SDN Orchestrator are repeated. Please be careful not to get confused.

This school, originated from Google, is slightly different from Google in that Google uses OpenFlow network elements (switches), while this school uses traditional network elements. There is also a bit of Cisco in this school. However, the essence of Cisco school is network management, and the essence of this school is network optimization, so we still classify this school as Google school.

As mentioned earlier, due to the limitations of OpenFlow, there are not many application scenarios for OpenFlow network elements (switches), so this school uses traditional network elements, which is not bad, but very correct.

Network optimization, refers to network traffic optimization, under the premise of meeting the QoS, try to improve the utilization of the network.

This school is subdivided into two points: (a) static optimal path calculation and (B) dynamic path tuning.

Static optimal path calculation is to calculate the optimal path (usually the shortest path) of a route in advance. But one of this method is that there is no overall concept, the other is that there is no ability of dynamic tuning, and traditional routing protocols basically have this ability, so we will not talk about this point. However, it should be pointed out that this small school, there is also a certain market, they often take this small point to compete with network management, saying that they are not only a network manager, but also do a path calculation. Alas, I don't know what to say about them: (1) this is a pure algorithmic programming, not unique to SDN; (2) Network managers already have this ability.

All right, stop complaining, let's take a look at dynamic path tuning. Let's start with an example, as shown in the following figure:

Figure 4 example of dynamic path tuning

In the figure, the path of a flow was originally planned to be: R1-R2-R3. However, when this path is congested, it is dynamically adjusted to a more idle path: R1-R4-R3.

This is a simple indication of dynamic path tuning.

From the point of view of high-end technology, dynamic path optimization is the highest technical content of the three schools. However, it is the genre that has the least voice in the SDN industry.

Google, the ancestor of this school, made a name for himself with a small hand at that time. Why is it so difficult for this school to become a climate? Are other companies stupid? It's not all stupid, ^ _ ^

There are many technical difficulties to overcome in this school: real-time monitoring and prediction of traffic; distinction and prediction of elephant flow and mouse flow; definition of QoS of flow. These technical difficulties are difficult to overcome. Instead of describing these technical difficulties, you only need to pay attention to the word "prediction" and you can imagine how difficult it is! For example, in the example in the figure above, when you adjust a flow to the R1-R4-R3 path, suddenly the R1-R2-R3 path becomes idle and the R1-R4-R3 becomes congested. Alas, being fired from the company, you don't even know who to reason with!

But why can Google overcome these and that points? Do you have any cool techs in Google? There is an article on the Internet that says very well, "Don't SDN-Google SDN for SDN has nothing to do with you" (https://www.douban.com/group/topic/47582532/), I suggest you read it. Here are a few brief excerpts from the author:

(1) expensive transnational links and submarine cables: compared to domestic transmission links, submarine cables and transnational links will be sky-high prices.

(2) N years of MPLS-TE deployment experience

(3) Classification of data levels: the average utilization of submarine cables and transnational links in Google B4 can be maintained at more than 95%, which is an astonishing figure. But what can we read behind this number?

a. There is already a strict hierarchy of internal data: what kind of data is high priority and what is medium and low priority has been clearly defined. Start identifying and limiting the speed of the application from the server entrance.

b. The size of each level of traffic is clear: starting from the entrance, it is very clear how much traffic each type of business will have, so that the overall traffic of each level can be summarized, and the summary CoS level plan can be specified. Otherwise, there is no way to do traffic CoS, which is why there is often no way to do CoS in China.

c. The sacrifice of medium and low priority leads to high utilization: CoS can not generate bandwidth, and can maintain high utilization because of the light load of high priority traffic, and then fill it with medium and low priority, then the low priority will be delayed or discarded when failures, high priority and burst traffic occur.

To sum up, there are three points: (1) strong demand; (2) sufficient experience and good technology; and (3) traffic conditions can be mastered by themselves.

Sorry, Google seems to be the only company that meets these three points. Google's network, running is its own home traffic, then the traffic can be planned by itself, and we are dealing with an unknown network, who knows what the traffic in this network is, and who knows what level of traffic in this network should be? Google is precisely that there is no cool techs, but from the source, the complexity faced by us (all but Google) is completely different from that faced by Google.

In addition, there is a paradox of network dynamic tuning: if you don't do a lot of tests on the existing network, you can't be stable and commercial; however, no existing network can allow an unstable program to do a lot of tests on it. This forms an endless cycle. And Google happens to be able to break this endless cycle, because its traffic costs are very high, "expensive transnational links and sea cables: compared to domestic transmission links, sea cables and cross-border links will be sky-high prices." High costs can motivate them to make up their minds to break this dead cycle, and unfortunately, we can't seem to find anyone else who has the motivation to break it.

Third, Google is its own research and development. I know my own network best, which is incomparable. It is with these three guarantees that Google can occasionally emerge, while it is almost impossible for other companies to do so. This is the reason why this school, which looks beautiful, is actually very weak.

(the author guesses that this is also the reason why Google seldom pronounces in the SDN industry after showing off its skills. He can't find a second same story either. After the matter, wipe your clothes to hide your merit and fame!

4. Summary

Our last "SDN maturity" map, this map, is my definition. As shown in the following figure:

Fig. 5 SDN maturity map

Abscissa means "general hardware maturity" and ordinate means "traffic optimization (global network) maturity".

Let's start with SDNE (Software defined Network element). Due to the limitations of OpenFlow itself, SDNE can only be used in limited scenarios, so I sum up its general hardware maturity as "0.1". And the SDNE school, if you put aside the OpenFlow, it is actually a network manager, and the controller does not have the whole network in mind (the whole network is in people's mind), and it is just a configuration, so I attribute its "traffic optimization (global network) maturity" to "0".

With SDNE as a reference, we can naturally attribute the SDNMS (Software defined Network Management) genre to the dimension of (0,0), which has neither general hardware maturity nor traffic optimization (global network) maturity.

SDNO-1, static network optimization, is slightly better than SDNE. After all, some static global optimal path calculations have been done, so I boil it down to (0,0.1) this dimension.

Let's take a look at the great Google, which actually belongs to the (0.1,0.2) dimension. It uses an OpenFlow switch, so the general hardware maturity is 0.1, and its dynamic traffic optimization is based on the premise that "traffic is under control", so I only attribute its traffic optimization (global network) maturity to 0.2.

In the picture, I draw a circle in two places with a maturity of "1". In fact, I am more euphemistic. I originally wanted to draw a red cross.

In the current stage, dynamic traffic optimization is almost impossible, perhaps in the future big data, artificial intelligence technology mature, this piece can break through.

As for the unified hardware maturity, there is no hope for OpenFlow, and there are also relevant software and hardware technologies to replace OpenFlow, but the author thinks that it does not solve the problem. It is almost impossible for hardware maturity to reach "1" in the short term.

The two impossibilities, I think, can give us some enlightenment:

As a product planning, large companies can calm down, the current situation, SDN is not suitable to do a product with great fanfare, but should be turned to pure theoretical research. As for small companies / startups, you can make some money in the field of SDNE (Software defined Network element), which is understandable, just go ahead.

As for the SDNMS (Software defined Network Manager), if you don't currently have it, do it, if you need it, and if you want to continue to preach that this is SDN, then advocate it, after all, the world needs lies. If you already have a giant network management product, the author advises: stop it and don't do it again!

As for SDNO-1, static network optimization, its volume is not enough to become a product, that is, a module, it is suggested to be integrated into the network management inside, do not use this to talk about things, give yourself a reason to do network management again!

Don't use wolf sex as a cover to be the sinner of the company! Don't cover up the laziness of thinking with diligence in action! In addition, I never mentioned the SDN collaborator. So which dimension should the SDN collaborator fall into? Guess.

III. The essence of SDN

In my mind, the essence of SDN is shown in the following figure:

Figure 6 the nature of SDN

In my mind, the essence of SDN, only need to achieve (1,0.1), do not need to achieve (1,1), of course, can achieve better.

A general hardware, plus a static optimal path algorithm, is the essence of SDN in my mind. As for the price of the submarine cable in Google is too expensive, it is an individual demand and does not affect the overall situation.

As I said before, the essence of SDN is "Taobao + Baidu". Some people understand my view as "SDN is white box". Sorry, you misunderstood my point of view.

To analyze the nature of a technology, we must first look at the economic benefits of the technology. If the economic volume of a technology also produces a profit of 32 cents, then there is no need for us to analyze the nature of this technology. Specialization produces closure, standardization produces division of labor, and socialized division of labor greatly improves social productivity. Complication and specialization will produce high profits of individual enterprises, while standardization, simplification and socialized division of labor will produce high profits of the whole people.

The original intention of SDN is to derive standardized hardware and simplified software based on OpenFlow (we assume that OpenFlow works). Let's imagine this scenario: the hardware has been standardized, that is, it is readily available (which is why I said to buy hardware from Taobao), and the basic package of communication protocols will definitely be open source. You just need to do personalized requirements on it (that's why I'm talking about searching for software on Baidu).

As for whether fake goods are bought on Taobao and whether piracy is found on Baidu, sorry, that is not a matter of SDN, OpenFlow currently has a variety of problems, that is the problem of technology itself, which does not affect the nature of SDN.

If the essence of SDN can be realized, it must be the great improvement of the telecom production efficiency of the whole society and the extreme reduction of telecom charges paid by the whole people.

Current science has proved that the speed in the universe cannot exceed the speed of light. For science, we need to be in awe! whether the essence of SDN can be realized, from a scientific point of view, is possible or impossible, which also needs to be considered! Another level of thinking!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.