Network Programming
Network programming allows the behavior and traffic control of network devices to be processed by software that runs independently of network hardware, meaning that users can program on a controller to configure, control, and manage networks. Network programming separates the control plane of a network from its data plane. The data plane no longer needs to implement control logics of various network protocols. Instead, it only needs to receive and execute the operation instructions of the control plane.
How Does Network Programming Come About?
On a traditional network device, the network device hardware, operating systems (OSs), and network applications are tightly coupled, forming a closed system and relying on one another. As a result of this setup, if we aim to conduct innovation or evolution on one part, we must also upgrade the other parts correspondingly. This architecture impedes network innovation in the following aspects:
- Lack of a global network view and traffic visualization capability. As a consequence of this, it is difficult to make optimal decisions from a global perspective of the network, or quickly respond to TE requirements.
- Lack of a unified abstract model on the data plane prevents the control plane from supporting new functions by programming based on data-plane application programming interfaces (APIs).
- Lack of automation tools and a long service rollout period.
- The data and control planes of a device are tightly coupled and bundled for sale. As such, these two planes rely on each other as far as evolution is concerned, and the control plane on a device provided by one vendor cannot control the data plane on a device provided by another.
Is there a new way to solve the preceding problems? Researchers at the time took inspiration from the development of computer terminals. Personal computers adopt a universal processor, based on which they implement software-defined functions. Therefore, computers have more flexible programming capabilities, resulting in explosive growth in software applications. Through computer programming, we can convert our intent into a series of instructions that computers can understand and execute to meet our requirements. Similarly, can a network translate the service intents it carries into a series of forwarding instructions that network devices along the path can execute — like a computer does — in order to implement network programming and ultimately meet service customization requirements? Drawing on universal hardware, software-defined functions, and the open-source model in the computer field, Professor Nick McKeown's team proposed a new network architecture — software-defined networking (SDN).
In the SDN architecture, the control plane of a network is separated from its data plane: The data plane becomes more generalized, similar to the universal hardware of a computer. It no longer needs to specifically implement the control logics of various network protocols; instead, it only needs to execute the operation instructions received from the control plane. The control logic of a network device is defined by the SDN controller and applications, and as such, network functions are defined by software. The following figure depicts the evolution from the traditional network architecture to the SDN architecture.
Evolution from the traditional network architecture to the SDN architecture
What Are the Technologies Used to Implement Network Programming?
Network programming is the core characteristic of SDN. SDN provides a new network abstraction model with a complete set of universal APIs for users, who can then program on the controller to configure, control, and manage networks. So which technologies can be used to implement network programming?
OpenFlow
On March 14, 2008, Professor Nick McKeown and others proposed OpenFlow, which is a protocol used between the SDN control plane and data plane.
Essentially, the forwarding behavior on a device can be abstracted into "matching and action." The design principle of OpenFlow involves abstracting matching and forwarding actions into specific operations and using the controller to deliver flow table entries to switches to guide packet forwarding. In the OpenFlow protocol architecture, an OpenFlow channel is established between an OpenFlow switch and OpenFlow controller to exchange information.
In OpenFlow, a packet can be forwarded to a specific interface or discarded by matching protocol fields such as Ethernet, IPv4, or IPv6. The controller can program a matching + action rule via a flow table entry to implement network programming. For example, the controller delivers a flow table entry to switch A, instructing the switch to forward a packet whose destination IP address is 192.168.1.20 to outbound interface 1.
OpenFlow 1.0 architecture
In short, OpenFlow is an SDN technology that abstracts and generalizes network processing rules and supports centralized programming.
POF
Similar to OpenFlow, the architecture of POF includes two parts: the control plane (POF controller) and the data plane (POF Forwarding Element (FE)). POF is an SDN technology that comprehensively abstracts network processing into a more interoperable, protocol-oblivious process, while supporting programming forwarding rules and forwarding logic. The following figure shows the architecture of the POF hardware and software switches.
POF hardware switch (left) and POF software switch (right)
P4
P4 can also solve the insufficient programmability of OpenFlow. P4 supports programmable packet processing on a device by defining a P4 program containing the following components: headers, parsers, tables, actions, and control programs. This allows for reconfigurability without interrupting service forwarding and implements a protocol-independent programmable network data plane. The following figure shows the architecture of P4.
P4 architecture model
Segment Routing
Is revolutionary innovation necessary for network programming? The answer is no.
In 2013, Segment Routing (SR) was proposed, which is a transitional extension based on the existing network and provides network programmability. SR is a source routing protocol. It makes the network programmable by allowing the ingress of a path to insert forwarding instructions into packets to guide packet forwarding. The core idea of SR is to combine different segments into a path and insert segment information into packets on the ingress of the path to guide packet forwarding. Each path segment — referred to simply as a segment — is identified by a segment identifier (SID). Currently, there are two data planes for SR: MPLS and IPv6. When SR is applied to the MPLS data plane, it is called SR-MPLS and uses MPLS labels as SIDs. When SR is applied to the IPv6 data plane, it is called SRv6 and uses IPv6 addresses as SIDs.
As shown in the following figure, a packet enters the SR network from node A. From the destination address, node A determines that the packet needs to pass through nodes B and C before reaching node D. Therefore, node A inserts the SIDs of nodes B, C, and D into the packet header to guide packet forwarding. Nodes B and C forward the packet to the specified destination (node D) according to the SID information in the packet header.
Packet forwarding process with SR
Because SR-MPLS does not modify MPLS data encapsulation, it can easily interwork with traditional MPLS networks on the data plane. Unlike revolutionary protocols such as OpenFlow, SR-MPLS considers compatibility with existing networks and supports smooth evolution while also providing network programming capabilities.
SRv6
SRv6 is SR based on the IPv6 data plane. It combines the advantages of SR-MPLS's ingress programming and IPv6's header extensibility. SRv6 translates network functions into instructions and encapsulates the instructions into 128-bit IPv6 addresses. As such, service requirements can be translated into an ordered list of instructions, which can then be executed by network devices along the service forwarding path, achieving flexible orchestration and on-demand customization of services on an SRv6 network.
SRv6 defines network instructions — SRv6 segments, which are identified using 128-bit SIDs. Each SRv6 SID typically consists of three parts.
- The Locator part identifies the location of a network node, and is used for other nodes to route and forward packets to this identified node.
- The Function part specifies the forwarding behavior to be performed, and is similar to the opcode in a computer instruction.
- The Arguments (Args) part is optional. It is used to define parameters for instruction execution, and can contain flow, service, and any other related information.
SRv6 SID
SRv6 offers more powerful network programming capabilities than SR-MPLS in the following aspects:
First dimension: flexible segment combination. In SRv6, multiple segments are sequentially combined to represent a specific SRv6 path.
Second dimension: flexible combination of fields in the 128-bit SRv6 SID. It is known that each MPLS label contains four fixed-length fields: 20-bit Label field, 8-bit TTL field, 3-bit Traffic Class field, and 1-bit S field. In contrast, each SRv6 SID has 128 bits that can be flexibly divided into fields with variable lengths. This further demonstrates the programmability of SRv6.
Third dimension: flexible combination of optional TLVs following segment lists. During packet transmission on a network, irregular information can be encapsulated on the forwarding plane by flexibly combining TLVs.
The three-dimensional programming space allows SRv6 to deliver more powerful network programming capabilities, better meeting different network path requirements, such as network slicing, deterministic latency, and IOAM requirements. Taking a step further, SRv6 integrates SDN-powered global network management and control capabilities to implement flexible programming, thereby facilitating fast deployment of new services and helping build truly intelligent networks.
SRv6-enabled three-dimensional programming space
The working process of SRv6 is similar to that of navigation maps in our daily life. A navigation map involves topology collection, path computation, information delivery, path selection, and driving guidance.
Working process of a navigation map
The same is true for SRv6. A forwarder reports network topology information to a network controller through BGP-LS. The controller then analyzes the topology information and computes SLA-compliant paths according to the service requirements. Next, the controller uses a BGP SR-Policy extension to deliver path information to the headend, which then generates SRv6 TE Policies containing key information such as the headend address, destination address, and color. The headend selects an appropriate SRv6 TE Policy to guide forwarding. Finally, the forwarder executes the instruction bound to the SID advertised by itself to forward data.
Another prominent feature of SRv6 is its excellent extensibility. Specifically, by simply defining a new instruction, SRv6 can support a new network function without requiring any protocol mechanism or deployment changes. This capability significantly accelerates the rollout of innovative network services.
Advantages of Network Programming
Network programming plays a pivotal role in implementing intelligent cloud-networks. As the pace of global digital development accelerates, an increasing number of enterprises are now migrating their services to the cloud. However, enterprise cloudification also faces a myriad of challenges. One of the challenges is that the cloud is fast but the network is slow. The cloud and network do not match in terms of service provisioning speed. While cloud service provisioning is fast due to the development of enterprise digitalization — such services can be subscribed in e-commerce mode and provisioned within minutes — network service provisioning is slow, taking months to establish a connection between the enterprise side and cloud side. This severely affects the service deployment speed.
The network as a service (NaaS) function in the intelligent cloud-network solution can implement mutual cloud-network scheduling, solving the problem of fast cloud but slow network. The key of this function lies in leveraging the network controller and SRv6 technology for cross-domain service provisioning to implement network programming and deliver services with one click. In this way, services can be quickly provisioned and adjusted, meeting the service development requirements in the cloud era.
What Are Future Trends of Network Programming?
Professor Nick McKeown believes that we should think of a network as a programmable platform rather than a collection of independent elements. The behavior of a network should be described using the top-down approach. In addition, network programming can continue to innovate and develop from two aspects: user intent-oriented management- and control-plane programming and new service-oriented forwarding-plane programming.
The first is user intent-oriented management- and control-plane programming. Traditional network configuration, modification, O&M, and service deployment are device-centric and require professional administrators. The development of SDN solves some problems, mainly the fast provisioning of overlay networks. In the future, user intent-centric and intent-driven automatic network management and control will be implemented, including full-lifecycle management (network planning, construction, maintenance, and optimization) of networks and covering all scenarios such as overlay, underlay, and security policies. Future technologies that are earmarked for research and development include automatic configuration conversion and real-time configuration verification.
The second is new service-oriented forwarding-plane programming. To nimbly respond to new services, programmability needs to be provided on the data plane to support rapid innovation and the trial of users' new ideas. For example, new data plane encapsulation, non-standard data plane forwarding behavior, and customized real-time network measurement capabilities need to be supported. Future technologies that are earmarked for research and development include forwarding plane model abstraction, DSL/compiler, and E2E collaboration capabilities. E2E collaboration capabilities are reflected in two aspects: E2E process collaboration covering hosts, NICs, and network devices, and compatibility with software-based forwarding, network processor (NP), application-specific integrated circuit (ASIC), and field programmable gate array (FPGA).
- Author： Chen Li
- Updated on： 2022-12-09
- Views： 8633
- Average rating：
