What about the development of programmable networks?
Software-defined network based on edge/end host (2013-present)
It soon became clear that OpenFlowAPI was not sufficient to express all the needs of network operators, because it was designed as a universal minimum denominator API that was easy to adopt. OpenFlow's lack of expressive power has led to edge-based software-defined networking methods.
In this way, network routers are divided into two categories. The edge router is located at the entrance or edge of the network and performs programmable packet processing. At the core of the network are core routers, which simply forward packets with little programmability. Because edge routers are spatially distributed to serve clients in different locations, each edge router only needs to handle a small portion of the total traffic going into and out of the network.
Therefore, compared to the core, the performance requirements of edge routers are much lower, which allows them to be implemented on general-purpose CPUs. Using general-purpose CPUs to program edge routers can make them more programmable than the restricted OpenFlow API. Open virtual switches are a well-known example of edge routers. It runs in a hypervisor on the terminal host and connects multiple virtual machines on a single terminal host to the network. Recently, increasing performance requirements on the edge have led to the implementation of such virtual switches on FPGAs.
Logically speaking, the edge router may be the end host itself. Therefore, when discussing the edge-based approach, we also include some recent proposals that use the final host to achieve network flexibility. For example, Eden can use a commercial router to provide a programmable data plane by programming only the end host. The mini-packet program (TPP) allows the final host to embed the applet in the packet header, which is then executed by the router in a manner similar to a capsule-based active network. TPP uses a restricted instruction set to alleviate the performance and security issues of active networks. In terms of measurement and monitoring, many systems only monitor network performance from the end host.
For application contexts that are not available in the network, edge-based or end-host-based solutions are required. For example, only on the end host can you gain knowledge about which application uses the network (may be useful for monitoring). Similarly, many web security applications (for example, filtering spam) are best run on the final host, because for privacy reasons, determining what is spam and what is not the best information is left on the final host. In addition, many programmable network functions (eg, network virtualization, access control, security policies, etc.) can be realized only by edge programmability.
However, the edge-based method is not sufficient to solve all network problems. For example, by using network support for congestion control (for example, DCTCP using explicit congestion notification support from routers and XCP using explicit information from the congestion level of routers), performance has improved significantly. Many other recent proposals for improving network performance rely on the support of routers in the core of the network. Compared with the root cause of network problems using network measurement results "triangulation" from favorable positions of different terminal hosts, monitoring directly in the network has significantly improved network visibility. In short, the lack of a programmable network core will greatly reduce performance and complicate network debugging.
Someone may propose a hybrid network architecture that combines edge-based programmability with a smarter but fixed core router. Such an architecture still puts all programmability at the edge, but the core router is extended with a small number of fixed functions to support programmability from the edge. Examples of this approach include general packet scheduling and in-band network telemetry. They extend the router with fine-grained priority queues and can export queue size information to packets, but retain all programmability to the edge .
If there are a small number of functions that are sufficient for fixed-function routers, then this hybrid approach will be a general method for the future. If there is indeed such a small set of fixed functions, it would be better and simpler to build a fixed function router instead of a programmable router.
If you want to know more, our website has product specifications for programmable networks, you can go to ALLICDATA ELECTRONICS LIMITED to get more information