Talk about the past and present of programmable network elements

[[402793]]

This article is reprinted from the WeChat public account "Xianzao Classroom", written by Xianzao Classroom. Please contact the Xianzao Classroom public account to reprint this article.

▉ The past of programmable network elements

For a long time in the past, network elements interacted with each other through distributed routing protocols such as OSPF (Open Shortest Path First) and BGP (Border Gateway Protocol) running on the control plane of the device.

The network element provides interfaces such as SNMP, NETCONF, WEB, and CLI for configuration delivery or status acquisition. The control plane and forwarding plane are implemented by equipment vendors or chip vendors. The internal architecture or implementation details are a black box to the owner of the network element. This type of network element is a "configurable network element."

Later, SDN (Software Defined Network) came into being.

One of the hallmarks of SDN is the separation of the forwarding plane and the control plane, which for the first time ended the mutually exclusive coupling between the two.

The control plane is often implemented in software and deployed in a centralized manner, and can simultaneously control multiple data plane forwarding network elements. Well-known open source SDN controllers include ONOS and ODL.

The controller will centrally perform routing calculations and issue the table entries of each controlled forwarding network element in the form of standard APIs such as Openflow.

The network owner can customize the control plane of the forwarding network element on demand (through the controller). The customization of the forwarding plane is limited and often depends on the adopted Openflow specification and the selected ASIC hardware.

The hardware forwarding network elements in the SDN era are "control plane programmable network elements".

▉ Current Status of Programmable Network Elements

With the emergence of programmable data plane switching chips and P4 language, the data plane of forwarding network elements has become more "empathetic" and can be customized according to users' business scenarios and traffic models.

For example, traditional IP forwarding network elements do not support the encapsulation and decapsulation of GTP messages used by 5G user plane network elements UPF. In the era of non-programmable data planes, supporting GTP requires redesigning hardware and going through the traditional product demand research, project establishment, R&D, testing and other links again. This cycle is very long.

With the emergence of programmable data plane hardware, the P4 Runtime agent (such as stratum) running on the device side interacts with the control plane through P4 Runtime, making it possible to dynamically switch or change the forwarding logic (such as converting to a data plane that supports GTP). This type of network element is a "fully programmable network element."

The following table provides a brief comparison of the three types of network elements:

The forwarding network data plane is programmable, but it is not exclusive to programmable switching chips.

Virtual network elements implemented by software, network multi-core processors NP, FPGA, etc. can all be used as targets for running the P4 language. Moreover, the programmability of these network elements is often better than that of programmable switching chips.

However, in terms of hard indicators such as bandwidth, power consumption, and cost, programmable switching chips still win.

The direct benefit of fully programmable control and forwarding planes of network elements is that network owners are no longer locked in by equipment and chip vendors.

Fully programmable network elements and the programmable networks composed of these network elements can greatly stimulate the enthusiasm of industry, academia and research for network element and network innovation. At the same time, they also lower the threshold for innovation through P4 language and other means.

With the maturity of SDN, research on the control plane has yielded fruitful results.

Below, I have listed some outstanding innovations and practices in data plane programmability. Through these cases, we can better understand the current status of programmable network elements:

• Load Balancing

Virtual IP address traffic accounts for about 44% of large data center network traffic, and stateful load balancing is required to maintain the consistency of each connection.

The common solution of data centers is to use hundreds of servers for load balancing, which takes up about 4% of computing resources, and these computing resources can no longer be sold to customers for monetization.

To make matters worse, using servers to run software for load balancing will result in higher latency and jitter, affecting the user experience.

A SIGCOMM paper in 2017 proposed the SilkRoad solution (yes, it means "Silk Road" in Chinese), successfully throwing this thorny problem into the trash can.

SilkRoad uses programmable switches to perform stateful layer-4 load balancing. By storing the five-tuple hash value of the flow and the DIP pool version number, the size of the matching domain and action are reduced respectively, thereby maintaining stateful connections for millions of flows on the switch at the same time. The bloom filter implemented in hardware is used to ensure that the consistency of each connection is maintained even if the DIP pool is updated.

The benefits of SilkRoad's approach are also obvious. It can use a programmable switch to replace hundreds of servers to complete the work of stateful load balancing. This not only reduces the cost of stateful load balancing by two orders of magnitude, but also reduces latency and jitter.

• Network Measurement

Readers with experience in network operation and maintenance will surely understand that daily network management and maintenance rely on timely and effective network measurement and monitoring.

Some readers may have heard of NetFlow, a widely used network monitoring tool. If all flows are monitored, it will lead to high processing time and large storage space consumption, which is difficult to deploy in commercial switches in data centers.

Therefore, NetFlow needs to sample packets and can only monitor a portion of the flows. This makes it impractical to detect transient routing loops, routing black holes, and burst flows, because these require monitoring all flows without sampling in a short period of time.

A document titled "A better NetFlow for data centers" designed FlowRadar to specifically solve this pain point.

The core idea is to use an extended reversible blue filter lookup table on the programmable switch to encode the counters of each flow. Then, the computing power of the remote collector is used to decode and analyze the flow counters of the entire network.

After all this trouble, FlowRadar's advantages over NetFlow are clear: it is more scalable, can monitor all flows, and can detect difficult problems such as transient routing loops, routing black holes, and burst flows.

• Cybersecurity

DDoS attacks are familiar to everyone. Even if you have not experienced them, you should have at least heard of them. This is because they are the largest and most frequent means of network attack in the current network environment.

The traditional way to deal with this kind of attack is to use middleware to mitigate it. Although SDN technology can also be used to defend against DDoS attacks, it introduces new DDoS attack points. A SYN-flood attack can quickly make the link capacity of the control channel and the data plane cache become bottlenecks, which is a real-life example.

So, is there a solution to directly clean up DDoS attack traffic on the data plane?

Yes, there is. A document titled "Network anti spoofing with SDN data plane" proposes a DDoS traffic cleaning method that can be fully implemented on a programmable data plane, thus avoiding interaction with the controller.

The core idea is that the data plane device will intercept and proxy the SYN request, and use the random SYN-ACK challenge recalculated based on the message as the response number. The source address that successfully responds to the challenge will be added to the whitelist and the connection will be reset.

Before passing the challenge verification, neither the server nor the data plane device needs to maintain any stateful information, and can cope with large attack traffic.

When the attack traffic exceeds the resource limit of a single device, all programmable data plane resources on the same forwarding path are used to collaboratively filter the attack traffic. Each device is only responsible for cleaning a portion of the traffic, and the rest is handled by downstream devices, making the DDoS attack more fierce!

We can give many more examples of innovation using data plane programmability. Due to space limitations, I will end this section with a picture.

The figure below shows that research on programmable network elements covers network telemetry, performance optimization, accelerated offloading, security, etc. Readers who are interested in this field can also use this figure as a navigation map to start their in-depth study and research journey.

▉ The future of programmable network elements

With the gradual enrichment of data plane programmable solutions, programmable network elements have entered the era of fully programmable network elements where both the control plane and the data plane are programmable.

Have the expectations of users, services and networks for programmable network elements become a reality? Will programmable network elements dominate the future network?

Each reader has his or her own understanding of the above questions. Below, I would like to share my views.

First, the needs of users, services, and networks are constantly evolving and changing. Moreover, the trend of change is gradually accelerating. Therefore, the demand or expectation for programmable network elements will never disappear.

Secondly, the future network must be an intelligent pipeline that is elastic, flexible, high-performance, and has guaranteed SLAs. To achieve this goal, programmable network elements are definitely a potential stock.

However, as mentioned above, the hardware forms of programmable network elements will certainly be reduced compared to the current variety of types and models, but it is unlikely that there will be only one hardware form. At least, virtualized programmable network elements of general servers and integrated hardware and software programmable hardware network elements using programmable switching chips, NPs or FPGAs, or a combination of several of them, are likely to survive.

At present, mainstream chip suppliers have launched their own programmable chip solutions. White box equipment vendors can't wait to launch their own programmable network element hardware based on programmable chips. Leading Internet companies at home and abroad, such as AWS, Google, Alibaba, Tencent, etc., have deployed their troops to carry out the research and development and implementation of programmable network elements.

In the future, academic research and industrial applications of programmable hardware network elements with integrated hardware and software will surely develop rapidly, and various ways of playing based on programmable hardware network elements will also flourish.

Finally, the above picture is for readers’ reference. I hope it will not squeeze your imagination for innovation based on programmable network elements.