CN110601983A

CN110601983A - Method and system for forwarding routing without sensing source of protocol

Info

Publication number: CN110601983A
Application number: CN201910975715.1A
Authority: CN
Inventors: 李维勇; 张伟; 陈云芳; 李建林; 李方方
Original assignee: Nanjing College of Information Technology
Current assignee: Nanjing College of Information Technology
Priority date: 2019-10-15
Filing date: 2019-10-15
Publication date: 2019-12-20

Abstract

The invention discloses a method and a system for forwarding a protocol unaware source route, wherein the method comprises the following steps: when a first data Packet of a control message protocol request flow is received, a Packet-In message is sent to the SDN controller, so that the SDN controller can respond to the Packet-In message to decide an optimal forwarding path; receiving flow tables which define execution actions of all switches on the optimal forwarding path and are issued by an SDN controller; encapsulating the source routing forwarding information acquired from the flow table into a source routing packet header, and inserting the source routing packet header between an Ethernet packet header and an IP packet header to form a source routing data packet; and issuing the source routing data packet to each relevant switch on the optimal forwarding path, so that each switch can acquire source routing forwarding information by analyzing the source routing data packet, and protocol non-sensing source routing forwarding is realized. The invention can reduce the cost of flow table resources and delay caused by routing decision in the forwarding process.

Description

Method and system for forwarding routing without sensing source of protocol

Technical Field

The invention relates to a protocol unaware source route forwarding method and a system, belonging to the technical field of communication.

Background

In SDN (Software Defined Network) implementation technology, OpenFlow uses a relatively wide range of protocols to describe a communication interface between a controller and a switch. However, the number of flow tables in the SDN switch supporting the OpenFlow is small, it is difficult to implement fine-grained flow control and management, a small amount of flow information can be recorded only by a counter in a data plane, and information sharing between different data packets in the same flow cannot be supported. Meanwhile, OpenFlow uses an abstract model related to a protocol on a data plane, and a matching field of a switch is predefined when the switch leaves a factory, which causes a problem that the flexibility and the programmability of the switch on the data plane are insufficient. A Protocol-unaware Forwarding (POF) is an extended technology developed based on the OpenFlow Protocol, and has the basic feature of the OpenFlow Protocol that a centralized controller resides in a control plane and manages the Forwarding behavior of a switch in a data plane based on a flow table. The difference is that the POF provides a brand-new OpenFlow matching domain field and a group of general instruction sets for describing processing actions, and realizes fast forwarding irrelevant to a protocol in the SDN switch, so that the memory of the switch is saved, the communication between the switch and a controller is reduced, a large amount of controller decision and issuing time consumption is saved, and the transmission delay in a network is reduced.

The discovery of the next generation wide area network starts in 2004, and the DSL forum first proposed a wide area network management protocol based on Customer Premises Equipment (CPE), which performs automated configuration and policy issuing on the CPE through an automatic configuration server. The hybrid wide area network technology performs collaboration and load balancing on the wide area network by detecting different CPE networks, and allows some high-priority flows to be transmitted through an optimized extra line, so that the dependence of an enterprise network on a special line is reduced. The application router integrates an application sensing function for CPE, lines are distributed according to the priority of the application to which the flow belongs, and the stability and the safety of important flow are guaranteed. The research on the SD-WAN includes a multi-controller deployment problem, a switch dynamic migration problem, a Quality of Service (QoS) guarantee problem, and the like. Holler et al, who proposes the problem of controller deployment at the earliest, propose to adopt a greedy algorithm when the controller is deployed, with average delay and maximum delay as optimization objectives. Guo, cheng et al propose an SC-cSNN multi-controller deployment algorithm to reduce propagation delay between the controller and the switch, and propose a switch dynamic migration algorithm to solve the controller overload problem. For the problem of service quality guarantee, Mukherjee proposes a flexible transmission rate scheme in different WDM network architectures for the deadline-driven traffic on IEEE, and the deadline attribute is used as a QoS guarantee parameter. In terms of security, researchers have dynamically loaded these security capabilities through virtualization by migrating the security features of the firewall into the CPE.

Another new hotspot in SD-WAN research is the fast route forwarding problem, and centralized network management and control in SDN causes the controller to issue flow entries to each switch in each forwarding path one by one, which may increase the time for establishing the path. SDN based source routing is considered a strategy to address such issues. The source routing is characterized in that the required network topology information is provided by the source host. In the source route, the host adds related routing information to the head of the data packet according to a plurality of different subnet or intranet addresses to plan a forwarding path for the data packet, thereby realizing that a data plane in the network selectively sends the data packet to different destination addresses. Source routing greatly simplifies the complexity of the data plane compared to conventional routing protocols. The current source routing scheme is implemented by using support of an OpenFlow protocol for multi-Label Switching (MPLS) and Virtual Local Area Network (VLAN). Since the length of the VLAN or MPLS protocol header is 32bits, and the multiple layers of such protocol headers are required for nested encapsulation to express a piece of path information, the use of these existing protocol fields for path information encapsulation may cause a large bandwidth overhead.

Disclosure of Invention

The invention aims to overcome the defects in the prior art and provides a method and a system for forwarding a protocol unaware source route, which have the characteristics of saving bandwidth and reducing the use of a flow table for high-efficiency data packet forwarding.

In order to achieve the purpose, the invention is realized by adopting the following technical scheme:

in a first aspect, the present invention provides a protocol unaware source route forwarding method, including the following steps:

when a first data Packet of a control message protocol request flow is received, a Packet-In message is sent to the SDN controller, so that the SDN controller can respond to the Packet-In message to decide an optimal forwarding path;

receiving a flow table which is issued by an SDN controller and contains all switch execution actions on an optimal forwarding path;

the source routing forwarding information obtained from the flow table is encapsulated in a source routing packet header, and the source routing packet header is inserted between an Ethernet packet header and an IP packet header to form a source routing data packet;

and issuing the source routing data packet to each relevant switch on the optimal forwarding path, so that each switch can acquire source routing forwarding information by analyzing the source routing data packet, and protocol non-sensing source routing forwarding is realized.

With reference to the first aspect, further, the method further includes:

when receiving a first data packet of a control message protocol request stream, firstly, judging the Ethernet type of the first data packet: and if the matching of the loopback interface header field is successful, sending a Packet-In message to the SDN controller, modifying the type field of the Ethernet Packet header to be 0x0908, and otherwise, keeping the type field of the original Ethernet Packet header.

With reference to the first aspect, further, the forwarding information includes: data packet lifetime and forwarding ports on the complete optimal forwarding path.

With reference to the first aspect, further, when multiple flow tables are passed through during forwarding of a data packet, metadata is used to store flow information characteristics generated by a current flow table and provide the flow information characteristics to a next flow table for use, and the same matching logic is reused among different flow tables through abstraction.

With reference to the first aspect, further, the data packets are sequentially matched according to the priority of the flow table:

if the matching field of the flow table is consistent with the corresponding field in the data packet, executing a corresponding instruction set in the flow table, otherwise, requesting the SDN controller to issue processing logic;

and if the last flow table is matched, immediately executing a corresponding instruction set in the flow table.

Further in conjunction with the first aspect, the match domain field search key is a two-dimensional tuple consisting of an offset and a length.

In a second aspect, the invention provides a protocol unaware source route forwarding system, which includes an SDN controller and a plurality of OpenFlow-enabled switches, where the switches include an ingress switch;

upon receiving a first data packet of a control message protocol request flow, the ingress switch is capable of performing the following operational steps:

sending a Packet-In message to the SDN controller, so that the SDN controller can respond to the Packet-In message to decide an optimal forwarding path;

receiving flow tables which define execution actions of all switches on the optimal forwarding path and are issued by an SDN controller;

encapsulating the source routing forwarding information acquired from the flow table into a source routing packet header, and inserting the source routing packet header between an Ethernet packet header and an IP packet header to form a source routing data packet;

With reference to the second aspect, further, the SDN controller decides an optimal forwarding path according to a pre-obtained global topology link;

when a global topology link needs to be acquired, the SDN controller triggers a link discovery event, encapsulates an LLDP message through a Packet-Out message and forwards the LLDP message to all switch ports, so that a switch receiving the LLDP message triggers a local flow table lookup operation, and the LLDP message is encapsulated through a Packet-In message;

receiving a Packet-In message sent by the switches, and if determining that the messages received and sent by the two switches belong to the same event according to the same information In the Packet-Out message and the Packet-In message, creating a link record between the two switches until a global topology link is obtained.

Compared with the prior art, the invention has the following beneficial effects: the method comprises the steps of reconstructing a source routing packet header field by utilizing the high programmability and protocol independence characteristics of the POF, encapsulating source routing forwarding information in a data packet header, and forwarding all flows in a network by an intermediate switch on a forwarding path only by maintaining a small amount of flow table entries with a fixed number, so that signaling interaction between an SDN controller and the intermediate switch is reduced, the number of the flow table entries is reduced, and further the expenditure of flow table resources in the network is reduced, and delay caused by routing decision in the forwarding process is reduced.

Drawings

Fig. 1 is a schematic structural diagram of a source routing packet according to an embodiment of the present invention;

fig. 2 is a matching flow chart of the POF pipeline provided by the embodiment of the present invention;

fig. 3 is a block diagram of a configuration of a POF controller according to an embodiment of the present invention;

fig. 4 is a display screenshot of a data packet captured by WireShark at node 1 at POF function packet capture validation;

FIG. 5 is a graph comparing results of single link experiments for OpenFlow and POF schemes;

fig. 6 is a graph comparing multicast experiment results of the OpenFlow and POF schemes.

Detailed Description

Aiming at a wide area network environment with high flow, the embodiment of the invention provides a method and a system for quickly forwarding a source route based on protocol-unaware in an SD-WAN, further decoupling a control plane and a data plane of the network to realize a forwarding behavior irrelevant to a protocol, reconstructing a source route packet header field by using high programmability and protocol-irrelevant characteristics of POF (point of common function) for encapsulating a complete forwarding path, realizing the processing of a source route data packet by an algorithm, and reducing the expenditure of flow table entry resources.

The protocol unaware source route fast forwarding method provided by the embodiment of the invention comprises the following four main steps:

a) designing a data packet: the forwarding path processing information of the flow is encapsulated in a data packet header on an entrance switch, and only the processing information stored in the data packet header is needed to be forwarded in a subsequent intermediate switch on the path, so that the matching process in a flow table is avoided or reduced;

b) designing a data packet processing algorithm: by utilizing the programmability of the POF, a processing algorithm of an inlet switch and a core switch is designed, an intermediate switch on a path only needs to maintain a small amount of flow table entries with fixed quantity to forward all flow in a network, the signaling interaction between an SDN controller and the switch is reduced, the quantity of the flow table entries is reduced, and therefore the expenditure of flow table resources in the network is further reduced.

c) SDN controller network topology detection: and acquiring topology information of the SDN controller under the SD-WAN environment by using a Link Layer Discovery Protocol (LLDP) to realize the overall topology detection of the Protocol non-perception forwarding.

d) Unaware forwarding design: based on a protocol architecture combining a flow line and a group table, a plurality of flow tables connected in series form the flow line together, different flow tables are used for realizing different network functions, actions defined by the flow tables are unified, data needing to be operated are located by search keywords of a matching field of a POF, and protocol-independent fast forwarding is realized.

The invention utilizes the characteristic that the inlet switch in the SD-WAN only carries out information interaction with the SDN controller to unify the matching of new metadata parameters for the flow table of the subsequent core switch, and does not need to request new flow table items from the SDN controller for different protocols, thereby reducing the delay caused by routing decision in the forwarding process.

The invention is further described below with reference to the accompanying drawings. The following examples are only for illustrating the technical solutions of the present invention more clearly, and the protection scope of the present invention is not limited thereby.

01. Source routing packet design

Due to the protocol independence of POFs, there is no need to reuse header fields in legacy protocols. Thus, the source routing header field may be specifically tailored to achieve efficient routing. In this approach, the complete forwarding path would be recorded in this POF intermediate field, i.e., the POF would insert the relevant field between the ethernet header and the IP header, as shown in fig. 1.

The source routing packet header includes Time-to-Live (TTL) and forwarding ports on a complete optimal forwarding path decided by the SDN controller checking topology, and the forwarding ports are sequentially arranged according to an arrival order. When the TTL enters the POF network boundary, the SDN controller calculates that, when a data packet passes through one switch, the switch chip obtains a forwarding port of the current device according to the TTL and the offset, and the value of the TTL is reduced by 1, and when the TTL leaves the POF boundary, the value of the TTL is normally 0, which is used to detect the validity of the path. If the value is reduced to 0 in advance, the data packet is discarded and an asynchronous message is triggered to be submitted to the upper SDN controller to report an exception.

After inserting the new field, the type field of the ethernet header is modified to "0 x 0908" to indicate that the ethernet frame contains a POF-based data packet.

02. Source routing packet processing

When the first data Packet of a flow arrives at an ingress switch, it will determine the ethernet type of the data Packet according to the offset and length, and if matching the POF loopback header field succeeds, it will trigger a Packet-In message to be sent to the SDN controller and modify the ethernet frame type field, otherwise it is the original "0 x 0800". Because no Flow entry corresponds, when a Packet-In data Packet is received, the SDN controller calculates a routing path for the Flow and sends a Flow-mod message to the ingress switch, and the ingress switch encapsulates the specified output port information In a source routing Packet and sends the source routing Packet to each switch on the path for use. The ingress switch stores the output ports in metadata and inserts them into each data packet of the flow using a common instruction set. The processing algorithm of the ingress switch is shown in table 1.

Table 1 processing algorithm for ingress switch

When a core switch receives a source routing data packet sent by an ingress switch, POF data packets can be obtained from the source routing data packet, and a pre-installed pipelined matching rule is used to perform flow table matching and process the data packets. Since the complete forwarding path is already stored in the POF intermediate field of the data packet, the switch no longer needs to interact with the SDN controller, and only the forwarding port of the current switch node needs to be decapsulated from the metadata. The processing algorithm of the core switch is shown in table 2.

Table 2 processing algorithm for core switch

As can be seen from the above processing flows, in the POF-based SD-WAN, only the ingress switch generally needs to perform information interaction with the SDN controller, and benefits from network abstraction of the generic instruction set, and when no exception occurs in the forwarding path of all subsequent core switches, only uniform generic key flow table matching is performed according to new metadata parameters, and there is no need to request new flow table entries from the SDN controller for different protocols. The method greatly reduces the condition of asynchronous OpenFlow messages initiated by the core switch on the link, thereby greatly reducing the delay caused by routing decision in the forwarding process.

03. Obtaining global topological links

The SDN controller triggers a link discovery event in an initialization state, and because a destination MAC address in an LLDP protocol is a multicast address, the SDN controller encapsulates the data message through a Packet-Out message and forwards the data message to all ports. Once a switch receives an LLDP message from an SDN controller, the switch forwards the message to all ports, and when other switches receive the message, a local flow table lookup operation is triggered. Because the switch does not have a flow table about the LLDP data message, the switch receiving the message encapsulates the message through the Packet-In message and returns the Packet-In message to the SDN controller. The SDN controller can determine that the messages received and sent by the two switches belong to the same event through the same information In the Packet-Out and the Packet-In, and can create a link record between the two switches and store the link record locally. The process is performed in the whole network, so that the SDN controller can obtain the topology state of the whole network through the information, the network reaches a convergence state at the time, and when a flow is sent to the SDN environment, the SDN controller can decide an optimal forwarding path through the locally stored topology information.

This solution has compatibility requirements for legacy network equipment and environments due to the need to deploy SD-WANs in existing network environments in real environments. The SDN controller sends a Packet-Out message encapsulating the LLDP, and simultaneously sends a control signaling to enable a switch receiving the message to send a broadcast Packet to all ports, if a traditional switch In a non-SDN environment is reached, the switch can continue full-port broadcast through the device, when an SDN switch connected with the switch In the traditional environment at the other end receives the broadcast Packet, due to the lack of a flow table item for processing the broadcast Packet, the SDN controller can also trigger a Packet-In message to be submitted to an upper-level SDN controller, so that the SDN controller can determine that the non-SDN environment exists between links of the two switches, and if the SDN controller does not receive the Packet-Out message, the SDN controller can default that all devices operate In the SDN environment.

The global topology detection also has a task of updating the link state of the SDN switch and the link states of various logical networks at any time. The data center of an enterprise, which is the most important deployment environment of the SD-WAN, generally has the requirements of cloud computing, virtualization, and the like, and at this time, it is required that network resources in the system are wholly virtualized and managed through a resource pool, and different tenants may request related devices, ports, and corresponding bandwidths according to specific requirements. The logical networking has certain elasticity, and different from physical networking, attributes such as performance, safety and the like of different tenants need to be isolated from each other, so that an SDN controller is required to provide advanced characteristic support such as an access control list and QoS while supporting logical networking topology detection, and simultaneously store topology information, policy information and network resource scheduling information of various logical networking in real time.

04. Non-aware forwarding of multi-stage flow tables

In the SD-WAN, as the networking environment becomes more and more complex, in order to prevent the flow tables from being bloated and the readability from being reduced and the hardware performance requirement from being increased due to different policies stored in the same flow table, the POF inherits the protocol architecture characteristic of combining the pipeline of the mature OpenFlow version and the group table. A plurality of flow tables connected in series form a pipeline, and data packets are received from a switch and inquired to a corresponding interface to be forwarded, and jump among the plurality of flow tables is needed to complete matching. Different flow tables are used for realizing different network functions, for example, for two-layer forwarding, a controller firstly performs topology detection and synchronously records the MAC addresses of each device; for three-layer forwarding, the controller can calculate an optimal forwarding strategy according to the overhead and send the optimal forwarding strategy to the switch flow table; for the four-layer forwarding, the controller not only matches the MAC address with the IP address, but also matches according to the TCP/UDP port number, and writes the MAC address and the IP address into the corresponding flow table entry for issuing.

The POF switch uses metadata to keep the flow information characteristics generated by the current flow table and provide the information characteristics to the next table for use when the POF switch needs to pass through a plurality of flow tables in the process of forwarding data packets. The whole matching process is shown in fig. 2. The data packets are sequentially matched according to the priority of the flow table, and when the matching field of the flow table is consistent with the corresponding field in the packet, the corresponding instruction is executed. These actions are defined in the POF instruction set, and can implement functions of modifying data packets, updating POF counters, jumping to a specified flow table, and the like. The process is unidirectional and irreversible, if a certain flow table has no matching item, the Packet-In message request controller is triggered to issue processing logic, or if the last flow table matched has no corresponding GOTO statement instruction indicating the next-stage matching flow table, the corresponding instruction set is executed immediately. Both cases are considered the end of the matching process. In addition, the POF also inherits a concept of a leakage table entry newly added in OpenFlow v1.3.0, and is used for processing mismatched data packets in each flow table and performing unified operation according to an instruction set. The design of a multi-stage flow table has many advantages: firstly, the same matching logic can be reused among different flow tables through abstraction, so that the total flow table number is reduced and the forwarding efficiency is improved. Secondly, the matching process of the multilevel flow table enables decision logic to be clearer, allows the control plane to gradually realize forwarding decision of the data plane and issuing of the flow table according to a network protocol algorithm, and enhances the programmability of the SD-WAN architecture.

The POF switch employs a series of generic key combinations and table lookup instructions to perform the parsing of data packets and matching of flows. The POF's match field search key is a two-dimensional tuple consisting of an offset and a length. Actions defined by the flow table (the actions are defined in the POF instruction set and can realize functions of modifying data packets, updating a POF counter, jumping to a specified flow table and the like) are used for positioning data needing to be operated uniformly through the two-dimensional tuple. Due to the different formats of the different protocols, the locations where the required information is stored are different. In the traditional OpenFlow, a new action needs to be defined independently for label injection of different protocols, the POF can be positioned to any position of different protocols through a two-dimensional tuple of offset and length, and the operation itself can be abstracted into a unified action, so that the flow table decision process can be greatly accelerated, the forwarding can be quicker, and the performance of the whole network is improved.

When the data Packet encapsulating the POF intermediate frame is uploaded to the SDN controller, the SDN controller extracts the required flow table statistical information and port statistical information from the Packet-In message, and listens to a specific Address Assignment Mechanism (AAM) data Packet to construct a corresponding binding table of an IP address and a port. In addition, the SDN controller confirms information of an ingress switch of a flow corresponding to the data packet encapsulating the POF in an active probing discovery manner, and specifies a corresponding flow entry for the flow with the matching characteristic according to a protocol-independent fast forwarding mechanism of the POF.

After the SDN controller binds the IP address and the port according to the collected data and the flow characteristics extracted by the preprocessing analysis, the forwarding operation of the relevant flow may enter a relatively stable stage. At this time, the SDN controller sends polling messages to the switches directly connected to the SDN controller to verify whether the flow matching and forwarding operations are normal, and such a tracking mechanism does not change the forwarding behavior of the data plane. In order to prevent multiple polling-related Packet-Out messages from existing in a link at the same time, the SDN controller introduces a random jitter to the polling messages, which makes the frequency of the polling messages consistent but always does not arrive at the same time at different switches directly adjacent to the SDN controller on the link. After the polling message reaches the switch end, a statistical event is triggered, the statistical information of the switch of the previous time window is collected, then the forwarding event of the flow and the state change information of the switch are analyzed and verified according to the data information, whether an abnormal message is sent or not is determined according to the statistical information of the switch, the new polling frequency is determined, and the port state is dynamically adjusted. The mechanism of continuously polling and dynamically dividing ports can effectively meet the logic networking requirements and high-level characteristics such as QoS (quality of service) in the SD-WAN, and the flexibility and the expandability of the network are improved.

The following further describes an implementation method of a protocol unaware fast forwarding source routing system with reference to specific experiments, and similarly, the following embodiments are only used to more clearly illustrate the technical solution of the present invention, and the scope of the present invention is not limited thereby.

Building system simulation environment

In the embodiment of the invention, a Mininet experiment platform is selected as the environment of the POF experiment. The system consists of a virtual terminal node, an OpenFlow-supporting switch and an SDN controller, and provides good support for a remote SDN controller. The experimental platform data plane switch is an Open source switch which supports OpenFlow, and the corresponding function of the experimental platform data plane switch is to call and process a core forwarding module of a subsequent data packet for a decided flow. An opendataright controller is used in a network control plane, and the controller has an Open Service Gateway Independent (OSGi) structure, which can isolate a plurality of underlying network functions, thereby greatly enhancing the expandability of the control plane. Another big feature of opendataright is the presence of a Service Abstraction Layer (SAL) so that the controller can adapt to almost all the devices of different underlying protocols that may appear in the SD-WAN environment, ensuring that researchers can concentrate on SD-WAN scale network service application development without concern for the compatibility of parallel legacy networks with SD-WAN. Specific experimental environments are shown in table 3.

TABLE 3 System Experimental Environment

Two, protocol unaware forwarding deployment

2.1POF controller deployment

The SD-WAN network based on the OpenDaylight controller is a white-box system which can logically describe data packet forwarding and even calculate information such as delay intervals, flow table item magnitude and the like. The POF extension is added in opendataright, so that the controller can freely use the metadata of the data packet to temporarily cache the data required in the forwarding process. The POF module with the graphical interface provides an interface to complete manual configuration of the forwarding pipeline, configuration files can be loaded into the controller through the same interface, and meanwhile, other application programs can be developed for the POF manager by using the API, so that the SD-WAN network element can keep quite a plurality of software definition characteristics. Fig. 3 shows a frame of the POF controller.

In an SD-WAN environment, since the network will typically be managed and operated by different operators, there is a need to handle flows consisting of inter-domain traffic. However, the mechanism and implementation of the inter-domain operation based on the POF are not solved yet, and in order to solve the lost part, the system also designs an inter-domain module in the POF controller. This module is implemented by json (javascript object notification) and helps POF controllers exchange inter-domain information. In the design, each controller abstracts an Autonomous System (AS) managed by the controller into a large switch, and generates a domain forwarding table to describe the connection between the AS and its neighbors. When the topology changes, the domain forwarding table will broadcast to the co-controllers in the neighbor domains. After collecting the domain forwarding tables from all neighbors, each POF controller builds a global virtual topology and stores it locally. Then, when the inter-domain flow arrives, it can calculate the correct next domain through the domain forwarding table database and calculate the optimal path again according to the topological information in the domain to complete the forwarding. For traffic requiring a particular QoS, a controller may also cache end-to-end routing paths among multiple domains by cooperating with other controllers.

JSON data packets captured between inter-domain modules are mainly used to exchange inter-domain forwarding tables and send inter-domain messages of end-to-end paths. The data message of the protocol has a necessary field and an optional field, and the POF controller can judge a database which needs to be updated by the inter-domain data packet according to the necessary type field. The data message for announcing the forwarding table between domains has an optional field, the content is an array, each exit switch in the domain is a member object, and the controller receiving the message can know the global topology information of the neighbor domain according to the array. The data message of the notification end-to-end path has a matching list field, the member objects are POF intermediate frame two-dimensional tuple information and IP addresses of a sending end and a receiving end, when an end-to-end flow reaches the domain, the controller can preferentially match the route mapped by the message, and the controller can not generate incremental updating until the controller receives a new inter-domain forwarding table when topology changes.

2.2 POF switch deployment

In order to support new protocols developed in the future using POF, it is necessary to install an associated POF flow instruction set in advance in a POF switch of the data plane. The stream instructions may be divided into five categories as shown in table 4.

TABLE 4 classes of POF stream instruction set

The editing instructions are for editing the data packets. According to the system, the POF intermediate frame is inserted between the Ethernet header and the IP header, when an IPv4 data packet enters an entrance gateway of a POF-based SD-WAN environment, a switch can ADD the POF intermediate frame to a flow through ADD _ FIELD to distinguish the flow, particularly, a local area network adopting a network address translation protocol is usually arranged inside an enterprise network in the SD-WAN, the data packet transmission in the local area network is not notified to other networks, and therefore, even if certain values represent other meanings in other networks, the conflict cannot occur.

The forwarding instructions are for packet forwarding. In a network element, the forwarding process of data packets may include multiple processes, and a user may divide them into several flow tables according to functions, for example, a three-layer parsing flow table, a three-layer encapsulation flow table, and the like.

The entry instructions are used to implement the operation of the switch on the flow entry, similar to the EDITING instruction set. The manipulation of the flow entries may help the POF switch implement many protocol rules that require learning network information, such as topology detection, route calculation, and maintaining neighbor relationships. In the POF-based SD-WAN forwarding scheme, the mapping relationship between the MAC address and the port number is stored in a separate flow table, which checks the MAC address field of the flow at the input port. If the MAC address does not exist in the mapping TABLE, the user can ADD the MAC address and the input port about the source by using an ADD _ TABLE _ ENTRY method, and topology detection and route learning can also be realized by adopting similar operations.

The switch is assisted by a jump instruction set that implements some operations on the global state of the flow at the flow level to alter the processing of the data packet.

Third, experimental analysis

3.1 Experimental analysis in Single Link

A single link structure refers to a structure with only one link between two terminals without redundancy, and such a structure usually occurs at the end of the topology, i.e. the access stratum. Because enterprise networking typically only requires deployment of primary and backup links at the convergence layer for aggregated traffic without preparing redundancy for each terminal device. Therefore, the scenario of intercommunication between terminals of the access stratum can be generally simplified to data packet forwarding in such a topological environment.

The testing platform built by using the Mininet self-contained graphical interface tool consists of 4 Open vSwitch-based software switches, the POF supporting expansion is added, the forwarding performance is improved, and the Open vSwitch switches are operated in VMware virtual machines because the network scale needing experimental verification belongs to medium and small scale and is enough to be simulated by a personal computer. Each POF switch is provided with two 1GbE virtual ports and realizes the normal forwarding of high-throughput data packets based on the POF.

In addition to 4 switches, one SDN controller in the topology is responsible for control plane decisions, and two terminals (h1, h2) are used to simulate traffic in the SD-WAN. To verify the function of the POF, using h1 to ping h2, the ingress switch finds that there is no flow entry to match when the first data packet of the ICMP _ Request flow arrives at node 1. Node 1 will then encapsulate the Packet with a Packet-In message and upload to the SD-WANSDN controller. The SDN controller computes a unique path (1, 2, 3, 4) and instructs the switch on node 1 through Packet-Out to insert a POF header into the data Packet to carry the path information. Note that these operations occur on the switch rather than the SDN controller, which completes flow table issuance through the POF flow instruction set and directs the switch to complete POF inter-frame insertion. The format of the message after insertion is shown in table 5.

Table 5 POF encapsulation packet in single link topology experiment

Node 1 would change the type value to "0 x 0908" to indicate that the packet is a POF-encapsulated packet. The TTL and 4 outgoing ports form a POF intermediate frame, wherein the TTL takes 8 bits to display the TTL of the data packet, the TTL is reduced by 1 by a DEC _ FIELD instruction when passing through each node, the TTL is reduced to 1 when reaching the node 4, and meanwhile, the switch modifies the Ethertype FIELD back to the original 0x 8000. Because the number of switches through which a data packet needs to pass in an actual network is unknown, the POF intermediate frame adopts the TLV variable length format, and stores the outbound port of each hop on a forwarding path in reverse order, and each time a node switch passes through, the last outbound port is fetched and deleted by the DEL _ FIELD instruction and the standard offset and length of the port FIELD, and forwarding is completed by the OUTPUT instruction. Meanwhile, since the situation that the conventional network and the SD-WAN network coexist in the actual network generally exists, the above process can be restored to the format originally entering the SD-WAN environment when the packet arrives at the node 4, and even if a conventional network exists between the nodes 4 to h2, the packet can be forwarded normally without being misread and discarded due to the change of the format.

Figure 4 shows data packets captured by WireShark at node 1. The first and fourth of which are captured on the left-hand port of the switch and the remaining 2 on the right-hand port. It can be seen that the first data packet is a 98 byte ICMP _ Request packet incoming from the port on the left; the length of the second data packet becomes 104 bytes, which is exactly the length of one TTL field and 4 egress port fields, and the type field in the ethernet frame also becomes "unknown (0x 0908)", and it can be seen that the original data packet has been encapsulated into a data packet suitable for POF transmission under the direction of the SDN controller; the third data packet is a packet coming back from s2, which is sent out by h2 and has a length of 100 bytes, i.e., only extra TTL field remains, which verifies that the POF intermediate frame will complete self-subtraction during transmission; the fourth data packet is an ICMP _ Reply packet of 98 bytes in length, verifying that the POF encapsulated message has been converted back to the standard original format after transfer from the SD-WAN environment.

In order to verify the performance difference between the POF-based SD-WAN forwarding scheme and the OpenFlow scheme, a network test tool iPerf is used for simulating background flow in a network, then a connectivity test is carried out to record the delay generated from each experimental ICMP request to response, and then the number of switches in the topology is gradually added and the change of the delay is observed. Fig. 5(a) shows a variation of the delay of the OpenFlow scheme and the POF scheme. It can be seen that the OpenFlow scheme has significantly improved delay with the increase of the number of switches, and the POF-based forwarding scheme proposed by the present invention can maintain a delay time of a constant level. This is because the POF-based scheme encapsulates the data packet when it arrives at the ingress switch, and the subsequent switches do not need to perform information interaction with the SDN controller and can correctly complete forwarding by only taking out the corresponding egress port from the POF intermediate frame.

The iPerf is then used to begin flooding ICMP traffic to simulate the gradual increase in POF traffic in a real environment for about 10 seconds. Observing the change of the number of flow table entries as shown in fig. 5(b), the total number of flow table entries of the POF scheme is reduced by about 55-67% compared with the OpenFlow scheme, and more importantly, the advantages of the POF-based forwarding scheme proposed by the present invention become more and more obvious as the flow rate increases. This is because the ingress switches only need to install flow entries on a per flow basis while the core switches can share flow entries. Conventional OpenFlow requires a flow entry for each flow to be installed on each hop switch of the forwarding path, so that the data packet can be forwarded correctly.

3.2 Experimental analysis of multicast POFs

In addition to the single-link topology model, there are more than one link between most nodes in the wide area network to achieve load balancing and disaster recovery. Multicast is a widely used communication scheme in the present wide area network, and is often used to implement services such as video conference, data backup, and the like, and has high transmission efficiency.

The core problem of implementing multicast using POF source routing is how to encode the whole multicast tree in the packet header, and in order to solve this problem, the embodiments of the present invention design a recursive method based on POF multicast. After the multicast tree is obtained, its main path (referring to the shortest branch (in terms of hop count) of the multicast tree, which connects the source switch with one of the multicast destination switches) is first found, and one of the paths is randomly selected if there are multiple shortest branches of the tree. Then, regarding the branch node (referring to the switch with multiple branch links from the root to the leaf node path) as the source switch on the main path and starting to find the main path of the next stage, and repeating the process recursively until all the destination switches are connected with the main path. At this time, the multicast tree is divided into several non-overlapping branches and POF-based multicasting is implemented using them. To implement the encapsulation of the POF inter frames, the scheme still uses the structure of table 5 to encode the multicast tree, except that an MPort field is designed to replace the Port field in table 5, which consists of two subfields, a branch node check bit and a group tag. Wherein, the branch node check bit indicates whether the switch is a branch node, if yes, 1 is taken, otherwise 0 is taken. The group tag field assigns a tag to each active multicast session and therefore can be used to identify the multicast operation of the data packet at the branching node, which will split the data packet horizontally to other outgoing ports and encode a new POF header thereon if necessary. When the data packet arrives at the branch node, the switch will copy the data packet into several copies and encapsulate the new POF headers for them respectively, and when they are forwarded to the next hop node, the switch can forward them correctly according to the new POF headers.

The scheme designs a multicast function based on POF and performs performance analysis. Similarly, background flow is simulated by using iPerf, an ICMP message is flooded at h1 by using the iPerf, the flooding scale is gradually increased to carry out pressure test, the delay time of the ICMP message is observed, and the results of the two schemes are compared.

Since the branch node switch encapsulates a new POF header for the data packet, and the forwarding logic followed by the non-branch node switch is the same as that in the previous section, only the ingress switch, i.e., the node 1, needs to perform information interaction with the SDN controller in the multicast experiment. Therefore, the delay in the multicast experiment is consistent with the unicast scenario in the single link topology, and the experimental result is shown in fig. 6 (a). Since the number of switches is not increased in this experiment, the number of flow table entries for each flow is generally constant throughout the network. The performance of the scheme is evaluated by recording the percentage of the successfully received throughput, namely the receiving throughput, as the traffic load increases on four hosts, namely h2, h3, h4 and h5, instead of the number of flow table entries. 100 multicast sessions are generated on h1 using iPerf and broadcast to all four destination hosts, each destination providing ICMP traffic at 0.25 Mbps. The reception throughput of the four hosts was averaged, and the experimental result is shown in fig. 6 (b). Among them, the POF-based multicast scheme can achieve a reception throughput close to 100%. This is because the core switches in the POF scheme can share the characteristics of flow entries, and there are only fewer than 1000 flow entries per switch. The OpenFlow scheme requires a flow entry based on each flow to be installed on each hop of a forwarding path to achieve correct forwarding. It can be seen that the receive throughput of the OpenFlow scheme cannot approach 100% until more than 2200 flow entries are allocated per switch. Experimental results show that, for flow-level traffic management, the POF scheme utilizes flow entries more effectively than the conventional OpenFlow scheme, and this conclusion is applicable to both unicast and multicast scenarios.

The technical scheme provided by the embodiment of the invention starts from the application of SDN technology in a wide area network, namely the solution of SD-WAN, provides a source route fast forwarding scheme for applying POF technology in SD-WAN environment, and proves that the scheme has smaller delay and stronger network performance than the original OpenFlow scheme through two aspects of theoretical explanation and experimental verification, so that the technical scheme has good application value for similar government and enterprise professional delay sensitive services.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The above description is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, several modifications and variations can be made without departing from the technical principle of the present invention, and these modifications and variations should also be regarded as the protection scope of the present invention.

Claims

1. A protocol unaware source route forwarding method is characterized by comprising the following steps:

2. The protocol unaware source route forwarding method of claim 1, wherein the method further comprises:

3. The protocol unaware source route forwarding method of claim 1, wherein the source route forwarding information comprises: data packet lifetime and forwarding ports on the complete optimal forwarding path.

4. The protocol unaware source route forwarding method of claim 1, wherein when multiple flow tables are passed through in the data packet forwarding process, metadata is used to preserve the flow information characteristics generated by the current flow table and provide the flow information characteristics to the next flow table for use, and the same matching logic is reused between different flow tables through abstraction.

5. The protocol unaware source route forwarding method of claim 4, wherein the data packets are sequentially matched according to the flow table priority:

6. The protocol unaware source route forwarding method of claim 1, wherein the switches defined by the flow table perform actions to locate data needing to be operated on uniformly by matching field search key, which is a two-dimensional tuple consisting of offset and length.

7. The method for forwarding a protocol unaware source route according to claim 1, wherein the method for deciding the optimal forwarding path comprises: deciding an optimal forwarding path according to a pre-acquired global topology link;

the method for acquiring the global topological link comprises the following steps:

triggering a link discovery event, encapsulating an LLDP message through a Packet-Out message and forwarding the LLDP message to all switch ports, so that a switch receiving the LLDP message triggers a local flow table lookup operation, and encapsulating the LLDP message through a Packet-In message;

8. The method according to claim 7, wherein when Packet-Out messages encapsulated with LLDP messages are forwarded to all switch ports, a control signaling is sent at the same time, so that a switch receiving the LLDP messages sends Out a broadcast Packet to all ports;

if the broadcast Packet reaches a switch In a non-SDN environment, the broadcast Packet passes through the switch In the non-SDN environment to continue full-port broadcasting, and when a switch In an SDN environment connected with the switch In the non-SDN environment at the other end receives the broadcast Packet, a Packet-In message is triggered to an SDN controller, and the fact that the non-SDN environment exists between links of two switches is determined; if the SDN controller does not receive Packet-In messages, it defaults to all switches operating In the SDN environment.

9. A protocol unaware source route forwarding system is characterized by comprising an SDN controller and a plurality of switches supporting OpenFlow, wherein the switches comprise an ingress switch;

10. The protocol unaware source route forwarding system of claim 9, wherein the SDN controller decides an optimal forwarding path according to pre-obtained global topology links;