Talk about what you want to know and don't know about SDN

SDN has been very popular for a while. For a while, no matter operators, government enterprises or investment institutions, if you don't know SDN or can't use a few SDN-related terms, you seem to be behind the times. But after a while, everyone seems to be a little confused. There are many companies doing SDN, but there are not many projects that are truly commercially available and worth a name. What is SDN like and what is its future prospect? Today, from the perspective of a veteran who has been working in the SDN industry for a long time, I will talk about what you want to know and don't know about SDN.

Is SDN OpenFlow or separation of control and transmission?

SDN is OpenFlow? In fact, SDN relies on the forwarding behavior of control flow to realize the functional characteristics of software-defined networks. OpenFlow is just a control protocol developed by ONF. Whether it can eventually dominate the industry depends on its own adaptation to the needs of network development and industry support. In addition to ONF's OpenFlow, there are also potential competitors such as IETF's PCEP, NetConf and other potential competitors such as RPC/gRPC and P4 Runtime API.

Does SDN have to separate forwarding and control? When SDN was proposed, the separation of forwarding and control was its starting point. However, if we explore the essential concept of SDN, the core point is actually the network operating system (not the NOS in the device, the term device NOS has confused this concept), separate the control, management, and operation and maintenance aspects, decouple from the forwarding plane, open/universal interfaces, and get rid of the current protocol stacking evolution trap, get rid of the situation of being kidnapped by a few manufacturers' vertical chimneys and unable to develop and evolve freely. That is, from protocol drive to open API drive. Doesn't this look very much like the development process of the PC industry? PCs have evolved from closed personal computers like Apple I and II to the situation of compatible machines being universal and open. The actual network industry has a similar trajectory, but it has lagged behind in the development stage. The actual ATCA can also be seen as an impact on universal openness.

The essential concept of SDN is to learn from the operating system of PC. If you think that adding a control protocol and separating the control and transmission is SDN, it is actually a narrow perspective and falls into the trap of adding protocols (although they are control protocols) to solve problems. And from the perspective of smooth evolution and seamless connection between traditional networks and SDN, it would be ideal if this Networking OS can shield the differences between traditional networks and SDN/NFV and provide a unified capability API to the upper layer. If this direction is OK, it actually doesn't matter whether it is separation of control and management, OpenFlow or other things. The key is to provide an open and universal API to the upper layer.

ONF, IETF, OpenFlow, PCEP/NetConf, and Overlay, who should we listen to?

ONF is a new force in SDN. OpenFlow is a new start. There is also OF-Config in management and configuration, but it is not widely used. The idea of ​​IETF is to use existing research results and existing protocols as much as possible. However, if you look closely, the differences of the existing protocols promoted by IETF still require new equipment and new implementations. Although PCEP has been studied for many years, there are almost no routers that support it. NetConf was originally mainly used for configuration and monitoring, which are all management-related things. The reason why everyone thinks it can cross over to the control plane is because of its strong scalability.

From the history of the communications and network industries, strong scalability often means that manufacturers have their own "little tricks" and private implementations of their products/solutions (the so-called "differentiated competitiveness"), and interoperability and compatibility are difficult to guarantee. This can also be seen from the history of NetConf. NetConf was originally born out of several complaints conferences held by IAB under IETF from network administrators to developers. It was intended to overcome the shortcomings of SNMP and replace SNMP, but SNMP is still alive and well. Just when NetConf seemed to be "cooling down", SDN came. The reason why NetConf did not replace SNMP is precisely the comparison and trade-off between strong scalability and strong compatibility.

Therefore, which company or path should you choose? You still have to choose the one that suits you based on your scenario and needs. And it is unlikely that there will be a one-size-fits-all situation in the future.

SDN controllers all have single-point bottlenecks. Do they still have a future?

After the control plane is centralized, the centralized controller obviously becomes a single point of bottleneck. Many old networks are disappointed and think that this is not feasible and SDN is going to be dead. In fact, if you think about it carefully, this is going from one extreme (fully distributed IP network) to another extreme. You can't expect a network of the size of China Telecom to only need a small number of controllers or controller clusters to handle the control tasks of a province or even a large prefecture-level city network. This is unrealistic and unnecessary.

Distributed IP networks have a layered architecture that gradually converges forwarding paths, and also have a domain-based design. The same is true for SDN networks, which also require layering and domain-based. When the scale of the same layer or domain is large, slicing control is also required. This is a very natural demand and design idea.

In addition, there is a misconception that distribution is always good and centralization is always bad. In fact, distribution-centralization-distribution-centralization is similar to "long-term division must be united, and long-term unity must be divided". There is no absolute good or bad here. Meeting needs and adapting to trends are the most fundamental criteria for judgment. In addition, SDN can be designed with logical centralization and physical distribution. If it is deployed in layers, domains, and slices, it is actually a centralized + distributed architecture.

NFV and IBN are here, but SDN is dead?

After NFV became famous, many people thought that NFV would dominate the market and that NFV could be used almost everywhere, thus SDN was sidelined. If we analyze it in depth, we can find that from the functional point of view, NFV seems to be used almost everywhere, but from the perspective of input-output and the requirements of different network locations, NFV is not suitable for some locations/roles at present. For example, on the access side, close to the end-user terminal, a large number of ports are required, but the cost-effectiveness of the server after adding many ports is much worse. For example, the core requires high performance and large-capacity forwarding, and the current general-purpose server architecture cannot meet this requirement. Even if it is barely stacked, the cost is far higher than the current proprietary processing architecture. Although NFV does not cover all network roles, it is still very suitable for some places due to its flexible programmability. On the other hand, NFV is not a substitute for SDN, but an enabler of SDN, and can be considered as a part of SDN (provided that the broad concept of SDN is recognized and not limited to a narrow scope).

IBN, intent-based network, is intended to enable network operation and maintenance, and control layers to automatically perform network planning, network optimization, configuration, prediction, and early warning based on high-level abstract business logic/policies. For example, for VLAN and intranet IP address planning, IBN can automatically allocate VLAN, IP, and configure ACL based on the input network model, such as campus or enterprise, and which people/groups have what access rights. This is actually related to SDN and traditional networks, which are bearer/convergence, and requires network open APIs.

Why is SDN advancing so slowly?

SDN has been buzzing for several years and has basically crossed the chasm of the technology adoption cycle. It can be said that it has passed the Peak of Inflated Expectations stage in the Gartner Hype Cycle. Internet giants in China and the United States, AT&T, etc. have claimed to have commercialized SDN/NFV on a large scale or at least on a small scale. SD-WAN and other fields have also been proven. However, in other broader fields, the envisioned situation of conquering cities and destroying the enemy has indeed not appeared.

To sum up, there may be several reasons:

• First, the traditional network is huge in scale and volume, and has a heavy burden. The transformation to SDN/NFV is a gradual process, and it is not feasible to start from scratch. This is also a feature of the communications/network industry. The new journey must carry the historical burden.
• At present, SDN equipment still has some areas that are not suitable for the needs. For example, many equipment flow table entries are too few and cannot cope with some scenarios. The price of the same external specifications (ports, forwarding capacity, features) is much higher than that of traditional network equipment. Add the software quotation, and the price per unit is relatively high.
• The three parties have resistance from their own interests. The main traditional network giants rely on hardware boxes as their main source of income and profit. Their traditional network business and SDN are in a relationship of mutual growth and decline. It is in their natural interest to continue to bind manufacturers. This leads to the traditional network giants still playing the new vertical chimney game even if they promote SDN (there have been many cases in this regard). At the same time, there is also considerable resistance within the company to the marketing and sales of SDN.
• Fourthly, at the customer level, quite a few customers are torn. On the one hand, they do not want to be kidnapped by manufacturers, but on the other hand, they trust the hardware of traditional giants more. NFV seems to be able to solve this dilemma (so telecom operators basically focus on NFV first), but as mentioned above, NFV is not applicable to all positions and roles, and the threshold of VNF is low and the competition is fierce (more than a dozen new and old manufacturers won the bid for China Telecom's vBRAS bidding); fifthly, not every customer is in the scenario of "big data, Internet of Things, mobility, cloud and intelligence" that requires the network to be transformed. For example, some customers said that their network is configured and it will not be moved and there are few problems, or the scale of the network is not that large, and the traditional model operation and maintenance personnel can still hold on with a bit of hard work and fatigue.

SDN: My future is not a dream

Although there are some unfavorable factors, the direction is very clear, and the industry has a consensus that it has not yet reached the tipping point. I believe that with the further popularization of "big data, Internet of Things, Mobility, Cloud and Intelligence" services, the arrival of 5G, and the further improvement and optimization of SDN solutions, SDN will surely flourish, conquer cities and territories, and overwhelm the enemy. As the saying goes: "Crisis" can force out effective solutions.

Author: Tan Peilong, currently CTO of Shenzhen Taixintong Information Technology Co., Ltd., has worked for well-known network manufacturers for more than ten years, and is responsible for key network chip architecture and systems. He has more than 20 network-related patents, 5 PCT patents, and 3 important SDN patents. He is involved in strategic planning, product management, marketing, management/operation, hardware and software/chip development.