Network virtualization-FlowVisor: Network Virtual Layer (medium)

Network virtualization-FlowVisor: Network Virtual Layer (medium)

1. Concepts understanding and review

As mentioned in the previous blog, slice is defined as an instance of a virtual network, and a sliced stream can be considered as a sub-space of the whole geometric space consisting of headers of all possible data packets. For example, the stream table items in OpenFlow match certain fields. We can divide the entire geometric space according to different fields.

FLowVisor defines slices as a group of streams. Therefore, we can treat slices as a group of domains. Given a packet header, we can determine which stream space this packet contains, you can determine which virtual network the packet belongs to. Therefore, an instance of FLowVisor can be equivalent to a stream space.

FLowVisor has three goals:

This virtualization should be transparent to the Controller.

Different Slices are completely independent.

Slice definition is scalable

II. Implementation of FLowVisor

1. Workflow

Similar to an OpenFlow proxy, FLowVisor intercepts messages between an OpenFlow switch and a controller, for example, left. All OpenFlow messages, from vswitches to users and from users to vswitches, will pass through FLowVisor. FLowVisor uses the OpenFlow protocol to communicate with users and vswitches. FLowVisor is transparent to vswitches and users, so in the user's opinion, they communicate directly with the switch. Next, we will illustrate the FLowVisor operation process with a simple example on the left.

 

Bob runs an HTTP Server Load balancer application on the Controller to distribute all HTTP streams to a group of servers, bob's FLowVisor's policy is to slice the network so that he can only process all the HTTP streams whose source IP addresses are a fixed value, and all the HTTP streams can be seen on the controller, the Controller is confident that it can achieve Load Balancing tasks. It will issue a stream table to balance all HTTP streams. When Bob's controller sends a stream table (for example, directing a stream to a server), FLowVisor intercepts Bob (1 on the left ), compared with Bob's slice policy (2 on the left), the rewrite stream table item is only valid for HTTP streams with fixed source IP addresses, in this way, the Controller only controls the stream of the fixed source IP address, but he feels that he has controlled all the streams. Similarly, for messages sent from the switch to the Controller, FLowVisor can only upload messages that meet the corresponding shard stream space. FLowVisor does not require one-to-one existence of FLowVisor instances and physical switches. A FLowVisor instance can control multiple physical switches and even Virtualize another virtual network. For example, right

The author published the source code, which is written in C language and contains about 7000 lines.

2. Slice definition Policy

Slices in FLowVisor are defined as insertion modules (very convenient and convenient). Each policy is described in a text configuration file, with one slice. For bandwidth allocation, all streams in one slice are mapped to one Qos group. Each slice has a fixed number of vswitch CPUs and the budget of the forwarding flow table, the network topology is specified as a list of network nodes and ports.

An ordered list of elements is similar to the flow space of each slice defined by firewall rules. Each rule describes an operation, such as allow, read-only, or deny, these are parsed in a specific order to perform the First Matching Rule operation. All the rules are combined as part of the stream space, and the whole slice is basically controlled. Read-Only rules only allow slice to receive OpenFlow control messages, query switch statistics, and do not allow streaming table insertion in the forwarding table. Overlapping rules are allowed.

We are going to complicate the previous scenario: Bob invited some of his friends to work with him to conduct an HTTP Server Load balancer experiment. The Network Administrator Alice allowed Bob to perform these cooperative experiments, alice handed the HTTP stream of the person involved in this cooperative HTTP experiment to Bob, and she continued to be responsible for the remaining HTTP streams. In addition, alice also wants to run a passive slice to monitor the performance of the entire network. To achieve this function, we can use the following stream space rules.

Bob's test network: it is defined as the HTTP stream required by all participants. His network description file has only one rule for each user, in the following format:

Allow: tcp_port: 80 and ip = user_ip

When an OpenFlow message from a vswitch that matches this rule is forwarded to Bob's controller, all flow table entries that Bob intends to insert will meet these rules.

Alice's production network is a supplement of Bob's network, so the rules are as follows:

Deny: tcp_port: 80 and ip = user_ip

Allow: all

All OpenFlow messages of switches that do not enter Bob's virtual network will be directed to the production network controller, which can be controlled at will for stream production controllers that do not meet Bob's flow space.

Alice's monitoring network: You need to see all the streams in the network. Its rules are as follows:

Read-only: all

This rule ensures that Alice's detection network is completely passive and does not conflict with her production network or Bob's test network.

Based on the above description, we can find that the rule-based policy is relatively simple, but it can meet the experiment and deployment requirements, more importantly, you can completely DIY the rules you need, so they are flexible and scalable.

After these two articles, I have basically understood the principle and process of FLowVisor and further broadened my thinking. The next article details how FLowVisor isolates different virtual networks.