SDN architecture and analysis: In-depth openness and integration

For a long time, network technology has always evolved in a passive manner, and a large number of technological innovations have been applied to network devices, such as increasing bandwidth, from 1G to 10G, to 40G and 100G; the architecture of the equipment has changed to continuously improve the performance, from dozens of Gbps of switching capability to TB; networking changes, Network Device N: 1 cluster virtualization, optimized network architecture within a certain range and a certain scale, simplified network design; large L2 network technology, by eliminating the loop factor, a wide range of layer-2 diffusion computing is supported for virtual machines under virtualization conditions.

The commercialization of new technologies will always lead to upgrades and upgrades of devices. With the huge changes in traffic, the network deployment and change technology is becoming more and more complex, it is difficult for the Network to have good expectations in response to traffic changes. In the current mode, once the service is deployed, the server is connected to the network through the network cable, the impact of application traffic throughput on the network is difficult to control, and network adjustment also lags behind.

The emergence and concept evolution of Software Defined Network (SDN) began to change the current situation of Network passive, so that the Network can be Defined flexibly; this definability means that the network actively "processes" the traffic, not just passively "carries" the traffic, but makes the relationship between the network and computing more than just "Docking", but "interaction ".

The SDN concept is embodied in the separation between the control plane and the physical data forwarding layer, which has a profound impact on the way the network switches work. High-end users are not satisfied with the use of pre-defined functions of the network, but want to be able to quickly adjust their own needs as their business functions continue to change. After the control layer is separated, or the control layer can be opened up, the flexibility of virtualization can be achieved, allowing users to compile programs, so rapid response based on application and traffic changes can be achieved, you do not need to rely solely on the hardware and software upgrades of equipment suppliers over a long period.

The idea of SDN is to give more control to network users. In addition to design, deployment, and configuration changes, SDN software can also be reconstructed so that new technical verification can be performed before commercialization. This network can solve the Network Complexity problem in an abstract way, lift the constraints on the functions and features of the user's income and expenditure network, and study and meet the business needs at a higher level.

1. Current mainstream SDN concepts

The most typical SDN architecture is the SDN architecture diagram (1) From ONF (Open Network Foundation ).

Figure 1 SDN Architecture

Figure 1 illustrates the concept of layered decoupling of SDN, including general basic hardware layer, hardware abstraction layer, network operating system, and upper-layer applications. The basic hardware and Hardware Abstraction constitute a physical network device, that is, the data forwarding layer in the SDN architecture. The network operating system and upper-layer applications constitute a control layer. The data forwarding and control layers are decoupled using a standardized interaction protocol, which is currently OpenFlow. This decoupling architecture indicates that network operating systems and network applications (such as routing control protocols) do not have to run on physical devices, but can run on external systems (such as X86 servers) to realize flexible and programmable network control.

In addition to understanding the coupling control layer and data forwarding layer, SDN also introduces the concept of centralized control (2 ). For traditional devices, because of different hardware and vendor-proprietary software, the network itself is relatively closed and can only be operated in concert with computing devices through standard intercommunication protocols. The systems of all devices in the network are relatively isolated and scattered. Network Control is distributed among all devices. The network changes are complex and the workload is heavy. In addition, due to the heterogeneous devices, the management compatibility is poor, the functions and configurations of different devices vary greatly. Modification or evolution of network functions may involve network-wide upgrades and updates. Under the SDN open architecture, a certain range of networks (or SDN domains) are managed by centralized and unified control logic units, this solves the problem of scattered and independent operation and management of a large number of devices in the network, so that the network design, deployment, O & M, and management are completed at a control point, the underlying network difference is also eliminated by the decoupling architecture. Centralized Control introduces SDN Controller, a role different from the traditional network architecture, in the network, that is, the control unit that runs the SDN network operating system and controls all network nodes. SDN can provide network application interfaces, design and program software based on business requirements, and load software on SDN Controller, so that the entire network can quickly upgrade new network functions, you do not have to perform independent operations on each node.

Figure 2 closed network and Open Network

In the layered decoupling architecture, the OpenFlow protocol is used to separate the control and forwarding layers of the network. Figure 3 shows the decoupling model of OpenFlow from Stanford.

Figure 3 OpenFlow Protocol Working Mode

The network device (OpenFlowSwitch in figure 3) consists of standard network hardware and software supporting OpenFlow proxy. The network hardware defined by OpenFlow is not a traditional exchange mode, but a stream table for data forwarding, it is very similar to the TCAM used by the current switch to classify and control data streams. The flow in each network is controlled and processed by the rules in the stream table, which can achieve extremely fine granularity. The OpenFlow Protocol defines a common data plane description language. The OpenFlow agent software on the device establishes security encryption (such as SSL communication mechanism) with the OpenFlow Controller) communication tunnel to receive control and forwarding commands for devices. All flow table commands are defined as standard specifications and are reliably transmitted through the encryption protocol between the Controller and the proxy. Various network applications running on the Controller are converted to the OpenFlow "Instruction Set", which makes it easy to implement standardized models. This makes OpenFlow an important technology in the SDN architecture.

OpenFlow defines the Supply Mode of network devices in an ideal form, but this definition makes the network not a smooth upgrade and evolution, but a disruptive update, the existing network cannot be upgraded through OpenFlow, but must be completely replaced. At the same time, the OpenFlow device is a kind of stream table forwarding and also requires a new architecture to design network chips. Although the existing TCAM technology can support the features of OpenFlow, however, devices with incomplete functions and large TCAM table items are extremely expensive. Therefore, the current OpenFlow device basically supports the OpenFlow protocol on the basis of the traditional network, the initial product with limited specifications.

The design concept of OpenFlow reflects the SDN architecture. However, this idea only reflects the advantages of centralized control and does not take network O & M management into consideration, how to Use OpenFlow for management communication and separate it from normal business flows, whether to overwrite or manage it with traditional SNMP/NETCONF, the centralized OpenFlow Controller and distributed OpenFlow network devices must be proven by continuous technical practices of OpenFlow.

The Protocol definition of OpenFlow is not complete yet. The definition of existing network features is still being supplemented and changed. content changes will continue and different technical versions will be gradually formed, this makes software and hardware highly compatible. This is also a serious problem in the network application coverage of OpenFlow as an SDN protocol.

2 H3C SDN architecture: openness and integration

2.1 overall architecture and strategy of H3C SDN

H3C will deliver a wide range of SDN products and solutions based on the end-to-end network architecture. (4) H3C SDN currently provides three solutions: Full SDN network delivery based on Controller/Agent, Open API-based network platform Open interfaces, and OAA-based custom network platform. Based on the integration of these three solutions, build an SDN system for a standardized, in-depth open, and user-Application-integrated NPaaS (Network Platform as a Service) Network Platform as a Service, it not only has the advantages of H3C network technology solutions, but also can integrate and expand user-made network applications at various layers.

Figure 4 overall architecture of H3C SDN

2.2 full SDN network delivery based on Controller/Agent

In the framework defined in the SDN basic architecture, H3C provides the same solution architecture. As shown in figure 5, H3C will support the standardized OpenFlow protocol and its own protocol RIPCRIPC (Remote IPC) based on H3C's mature technology in the same SDN architecture ).

Figure 5 SDN network of Controller/Agent

H3C will provide a standardized series of Controller components. It can use the OpenFlow protocol for centralized control of OpenFlow devices and provide flexible open interfaces for the upper layer to meet the call needs of various network applications. In the current network product, the OpenFlow feature is gradually integrated to meet the initial OpenFlow network deployment requirements, and the OpenFlow product composition is gradually enriched. the SDN network of the entire OpenFlow is constructed in the figure 6 left.

Based on the Controller/Agent architecture and the H3C RIPCRIPC protocol, The VCF technology is further enhanced for the H3C advantage technology IRF, as shown in the figure 6 on the right, use the IRF struct consisting of multiple S5820V2 to work as the Controller role of the network and downlink multiple S5120HI instances.

Figure 6 two implementation modes of H3C SDN Network

VCF uses the SDN-based N: 1 network virtualization. It not only integrates multiple devices at the same network layer, but also the devices at the other layer. The entire network runs like a large box-type device, all operations of operation management are virtualized on a large device. All controls and device management are in the IRF group of S5820V2, and other S5120HI operations are in line card mode. In this SDN architecture, the H3C RIPC protocol eliminates the lack of efficiency and management of OpenFlow protocol, and effectively inherits the original IRF advantages of the H3C Comware platform.

2.3 Open API-Based Network Platform

SDN's most important network requirement is programmability, that is, users can develop their own software as needed when their services change, the core of this requirement is that the network must have flexible and open interfaces for programming implementation. H3C implements a multi-layer Open API solution (7 ).

The basic device layer provides in-depth SDK-level standardized VCC network applications (VCC: Virtual Computing Container) and advanced xml access to the netconf standard interface system, openFlow is also a standard interface mode provided by devices;

The SDN Controller is a network operating system. The standardized interfaces provide VCC, REST/SOAP, NETCONF, and OpenFlow services based on different implementations of the Controller.

Open APIs and the Integrated APIs (such as RIPC) of the H3C System (Comware/iMC) complement each other to build a different SDN architecture, in addition, self-owned systems and open and standardized systems are formed at different levels, so that the programmable and application variability requirements of different users can be met.

Figure 7 H3C multi-layer Open APIs

In Open APIs, REST/SOAP is a common high-level protocol programming interface, NETCONF is a new XML language programming interface on network devices, and OpenFlow is a SDN protocol, all of the above are universal technology implementations, while VCC is a more underlying standard implementation formed by H3C in the long-term network software technology accumulation process.

ComwareV7 is a new generation cloud computing network operating system based on Linux kernel. The current architecture forms an open SDK Based on POSIX-like Linux interfaces and extensions, h3C provides a complete programming environment including SDK interface description, call library, and compilation environment, this allows users to use C/C ++ to develop their network application software in an environment almost identical to that in Linux, comwareV7 provides a complete system environment for your software operation, as shown in figure 8.

Figure 8 VCC running

In the VCC environment, user packages can be independently loaded to devices for operation, and the software can be upgraded without interruption. Comware V7 provides interfaces for users to access the underlying hardware to a certain extent, operate on hardware table items such as routers and MAC, or change the configuration of devices and monitor the corresponding status, at the same time, you can also use the existing features of Comware V7 to help implement your business, so as to meet the real needs of your software-defined network.

2.4 OAA-based custom network platform

Early on, H3C proposed an Open Application Architecture (Open Application Architecture) network model, that is, to provide a line card with computing capabilities in H3C network devices, users can develop their own special applications on them and interact with the network through the OAA protocol of H3C.

Based on the SDN Architecture concept, H3C implements a more flexible user-defined network design and implements a new OAA business model, allowing you to flexibly implement custom network functions. Based on OAA, two open interface models are proposed, as shown in figure 9.

Figure 9 the left figure shows a fully loosely coupled OAA architecture. Network services running in any form of user may be computing services on servers (such as traffic monitoring analysis and data bypass mining ), it may also be a dedicated service device (such as firewall, IPS, encryptor, and data compressor). user devices can communicate with H3C networks by supporting standard OpenFlow protocols, transmits business commands in the OpenFlow protocol to perform mirroring, channeling, encapsulation, and targeting operations on the network traffic to be processed, guide clearly defined data streams to your computing devices for custom processing in an appropriate manner. The essence of this solution is to use the SDN Model to run users' data processing devices as SDN controllers and process specific business flows.

Figure 9 right shows a tightly coupled OAA architecture in two modes: Mode 1, user-designed high-performance computing unit sub-card, and H3C provides the OAA line board, the two are connected by open standardized electrical interface connectors, and the user's computing unit and network are still using the standard OpenFlow Method for network traffic drainage, the software and hardware are designed by the user based on their own business needs. Mode 2: H3C provides the overall OAA line card. You can develop your own software based on H3C hardware, the Protocol still uses OpenFlow for specific data processing.

Figure 9 OAA-based custom network platform

3 conclusion

SDN is a broad network architecture that requires flexible and open structures to meet user needs. H3C technical Model, it provides interfaces and business environments required by users at different network levels and different architecture. H3C also provides SDN-based user network applications.