What about the mid-term development of programmable networks?
Software-defined network (2004-present)
Since the early 2000s, researchers have advocated separating the router's control plane (running distributed routing protocols to calculate the router part of its routing table) from the router's data plane (forwarding packets by looking at the data in the routing table). As an example, the implementation of the link state routing protocol will be part of the control plane, and the implementation of the table lookup based on the longest prefix will be part of the data plane.
The idea behind this approach, later known as software-defined networking (SDN), is the most flexibility that network operators need when managing large networks (such as traffic engineering, access control, and creating virtual networks). It is related to the control plane and not to the data plane. In addition, the control plane performs relatively less frequently than the data plane: every few milliseconds, not every few nanoseconds. Therefore, although the data plane must be implemented in hardware to improve performance, the relatively rare nature of control plane operations allows it to be removed from the router and moved to a commodity general-purpose processor, where the operating procedures can be performed more easily.
SDN also introduces the concept of centralized control: by moving the router control plane from the router to the general-purpose processor, the entire network control plane can be centralized on several servers. In this way, these servers can use the global network visibility to calculate the route of the entire network. SDN effectively replaced the error-prone distributed routing calculation protocol with simpler centralized graph calculation (for example, the shortest path using Dijkstra's algorithm).
Once the control plane calculates the route for each router, SDN also needs a control plane mechanism to populate the contents of the routing table. When forwarding data packets, the data plane will query these tables. The most famous of these mechanisms is OpenFlowAPI, which exposes the smallest interface of the routing table in the router hardware. The goal of OpenFlow is to act as the smallest common denominator of the routing table across interfaces to different router chips. In this way, the existing chip can immediately support OpenFlowAPI.
Although OpenFlowAPI makes it possible to program the control plane of the network, it does not necessarily make it easy. Therefore, the development of SDN has also led to the development of high-level programming languages to program the control plane of routers. Although SDN has done a lot of research on programming and verifying rich control plane strategies, it has done a lot on enabling programmability in the data plane.
Network function virtualization (2012-present)
Network Function Virtualization (NFV) attempts to transfer richer packet processing functions (beyond the original packet forwarding function) to commodity general-purpose processors and cloud infrastructure. Such packet processing functions include deep packet inspection, load balancing, intrusion detection, and WAN acceleration, commonly referred to as "middle boxes." Systems have emerged to program the data and control planes of such middleboxes.
A common use case for such middleboxes is at the edge of the network (for example, at a cellular base station), where each time a client accesses the Internet, various packet processing functions run on the processor cluster. Since NFV performs packet processing on a software platform, it can also be seen as a practical use case for software routers on the edge with relatively low link rate requirements.
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