About routing service in OpenFlow Network (1)

About routing service in OpenFlow Network (1)

Here, the so-called OpenFlow network refers to a set of OpenFlow switches connected to each other, and all these switches are placed under the management of an OpenFlow Controller or an OpenFlow Controller cluster. The routing service of OpenFlow network refers to simply sending a Packet from one Host to another, rather than implementing layer-3 IP routing protocol. The host is also the destination of the route. It can be a physical server or Virtual Machine (VM, Virtual Machine ). According to the SDN data plane and Control Plane Separation mode and the centralized management system structure, the OpenFlow network routing is completely implemented by the OpenFlow Controller according to the user's routing Policy) generate and install the Flow Table and the Flow Entry and Group Entry set of each OpenFlow switch. Therefore, this article assumes that readers have some knowledge about the basic concepts of OpenFlow switches and OpenFlow Controller. For more information, see the "OpenFlow Switch Specification" section in ONF (Open Network Foundation. The discussion in this article is also based on the definition given in the document.

General idea

The connection mode between the host and OpenFlow network directly affects the routing settings of OpenFlow network. This article discusses three common scenarios: first, the port of the switch of the host and OpenFlow network is directly connected, this is the simplest case. Second, the host accesses the OpenFlow network through a L2 network. Third, the host finally connects to the OpenFlow network through multiple IP subnets through the router, the network connected to the host and the intermediate network are all traditional IP networks that use traditional routing protocols, such as OSPF or BGP. For the convenience of the description, the host under the first connection mode and the second connection mode is regarded as the internal host of the OpenFlow network, and the host under the third connection mode is considered as the external host of the OpenFlow network. The so-called "external" is because the OpenFlow network cannot directly "perceive" the existence of the host. 1. Host A is connected to Port 3 of Edge Switch ES1 (method 1), and host B is connected to Port 3 through L2 link network (1.1.1.0/24) connect to Port 2 of the edge switch ES2 (method 2). Host C is connected to an external IP Network (3.3.3.0/24 ), vror R is an intermediary for communication between the OpenFlow internal host and the external host (the third method), and is connected to Port 2 of the edge switch es3.

The general idea of implementing the OpenFlow routing service is to obtain the host information and the information connected to the OpenFlow network, calculate the path between hosts, and send OpenFlow messages to each switch in the path, change its Flow Table and Group Table to define its forwarding behavior, and ultimately implement the routing and communication between the host and the host. These are basically the functions of OpenFlow Controller or network applications on it. The following sections describe all functions of OpenFlow Controller without distinction.

Host and access

To achieve routing and communication between hosts, OpenFlow Controller must first obtain information about the host. For internal hosts in the OpenFlow network, the information to be obtained includes the IP address of the host, the edge switch and port connecting to the OpenFlow network, and the MAC address of the host. In addition to Manual Static configuration, the network's Orchestration system provides the Host IP address and the switch and port connecting to the OpenFlow network, and the network's Orchestration System Management Server and Virtual Machine deployment on the network. For example, in a cloud computing data center, network administrators can use Orchestration systems such as OpenStack to customize IP subnets for customers. In this way, the IP address of each host in the IP subnet and the data of the connected switch and its port are transmitted to the Controller through the OpenStack plug-in. The MAC address of the host needs to be dynamically obtained through ARP. For example, in Figure 1, assume there is A packet sent to host A, but the MAC address of host A is unknown. In this case, the Controller sends an ARP request to Port 3 through the packet_out message. After receiving the reply packet from host A, switch ES1, because its Flow Table does not have a Flow Entry that matches the ARP packet, ES1 packs the ARP reply packet into a packet_in message by default and sends it to OpenFlow Controller. The OpenFlow Controller parses the packet to obtain the MAC address of host.

For external hosts in the OpenFlow network, OpenFlow Controller must know the IP address and MAC address of the router directly connected to the OpenFlow network, and the edge switch and port of the OpenFlow network of the router, the IP address (Prefix) and mask of the subnet where the external host is located. The IP address and MAC address of the router, as well as the edge switches and ports connected to the OpenFlow network can be obtained according to the method described above. The IP subnet address and mask of the external host are obtained by the Virtual Router. 1 shows that the IP address and mask (3.3.3.0/24) of the subnet where host C is located are finally transmitted to the router R through the traditional Distributed IP routing system. In Band or Out Of Band, R and vro establish a session In advance, such as BGP session, and exchange route accessibility information. Therefore, after the vro obtains the reachable information of 3.3.3.0/24, it is finally submitted to the OpenFlow Controller. Some open-source programs can be used to implement virtual routers, such as Xorp, Quagga, and ExaBGP. Generally, the session between a vro and an external router uses the BGP protocol. Details about vrouters are not the focus of this article.

Topology and Path

The control plane and data plane are separated to form a centralized control platform centered on OpenFlow Controller. All switches in OpenFlow are under the supervision of OpenFlow Controller. Therefore, OpenFlow Controller has the opportunity to master the global network topology view and the status of each switch. In this way, OpenFlow Controller can be more intelligent to adjust the forwarding behavior of each switch in a timely manner according to the user's routing policy, so that it is easier to implement Traffic Engineering (Traffic Engineering) and Fail Over. This is also the advantage of SDN.

Generally, OpenFlow Controller uses the LLDP (Link Layer Discovery Protocol) Protocol to discover the connection status between OpenFlow switches. The LLDP protocol is widely used by network devices to broadcast their own IDs, Capabilities, and neighbors. LLDP has a dedicated MAC broadcast address and EtherType, so that OpenFlow Controller can easily identify LLDP packets. The discovery of network topology is initiated by OpenFlow Controller. OpenFlow Controller sends a packet_out message to each OpenFlow switch, indicating that the switch sends LLDP packets to all ports. At the same time, the switch that receives the LLDP packet will also send the LLDP packet to all its ports. However, the Flow Table of the switch that receives the LLDP packet does not contain the Flow Entry that matches the LLDP packet. Therefore, it encapsulates the received LLDP packet as a packet_in message and sends it to OpenFlow Controller. By analyzing these LLDP packets, OpenFow Controller can know who and who are connected through which port. Finally, OpenFlow Controller obtains the complete topology of the network.

In the routing service of OpenFlow, the topology is found to calculate the path from one edge switch to another. For the convenience of the discussion, we assume that the routing service only uses the Shortest Path Policy. Although this is the simplest case, you can use the basic principles and methods provided here to implement more advanced and more valuable network routing policies. The network topology is represented in the data structure, which is a Graph ). As we all know, given a graph like a network topology, the Algorithm for calculating the shortest path between two points is the famous Dijkstra's Algorithm. For a source node in the figure, the algorithm can calculate the shortest path to all other nodes at a time. For details about the algorithm, see the Wikipedia documentation: http://en.wikipedia.org/wiki/?stra's_algorithm. The shortest path between two points may not have only one path, but may exist many. I have expanded this algorithm to calculate all the shortest paths between two points. Another blog of mine provides the C ++ implementation of this extension algorithm, which can be compiled and run directly. After obtaining multiple shortest paths, you can implement a routing policy similar to ECMP's Traffic balancing (Traffic Ba lance.

As shown in figure 1, OpenFlow Controller uses Dijkstra's Algorithm to obtain the path from host A to host B in the OpenFlow network as follows. The number indicates the inbound or outbound port.

Path (A, B): (3, ES1, 1)-> (1, ES2, 2)

Similarly, the paths from host A to host C and from host C to host B are as follows:

Path (A, C): (3, ES1, 2)-> (2, SW0, 1)-> (1, ES3, 2)

Path (C, B) :( 2, ES3, 1)-> (1, SW0, 3)-> (3, ES2, 2)

Of course, the computation of paths in the opposite direction, such as Path (B, C), Path (C, A), and Path (B, A), is also true.