Distributed IFIT flow table issuing method and related device

Abstract

The invention provides a distributed IFIT flow table issuing method and a related device, and relates to the field of communication. The method comprises the following steps: acquiring a to-be-configured first IFIT flow table by a control plane device; if the first IFIT flow table is associated with a target network port, acquiring a target flow control unit to which the target network port belongs; and sending the first IFIT flow table to the target flow control unit. Therefore, compared with issuing to all the flow control units of all the line card boards, the first IFIT flow table is sent to the target flow control unit in the distributed rack equipment in a targeted manner, and the utilization efficiency of IFIT Flow resources can be improved.

Description

Technical Field

[0001] The present application relates to the field of communications, and in particular to a distributed IFIT flow table delivery method and related devices. Background Art

[0002] IFIT (In-situ Flow Information Telemetry) is a detection technology that directly detects network performance indicators such as latency and packet loss by marking the characteristics of real network service flows. Therefore, it is widely used in Ethernet environments with high transmission real-time requirements, such as data center networks and industrial networks.

[0003] With the rapid development of mobile bearer, private network and cloud network architecture, bearer network faces new demands and challenges such as ultra-large bandwidth, massive connections, high reliability and low latency. IFIT inserts IFIT message headers into real business messages for performance testing, and uses Telemetry technology to upload test data in real time, and finally presents the performance indicators of each packet or flow to users intuitively through a visual interface.

[0004] like Figure 1 As shown, first, starting from the head node, when the target flow reaches the head node, the head node will specially mark these data packets (ETH, IP, Payload) and generate an IFIT flow containing an IFIT tag (IFIT FlowID) to identify and track the transmission of the data flow in the network.

[0005] Then, the IFIT stream with the IFIT tag is transmitted in the network, passing through the intermediate nodes and the tail node. At each node passed, these nodes will perform real-time network performance detection on the IFIT stream, mainly including monitoring of latency, packet loss rate, etc. Each node reports these detection results to the analyzer located in the network management system. The analyzer will centrally process the detection data from different nodes, so as to be able to evaluate the overall performance of the network in real time.

[0006] After the IFIT flow reaches the tail node of the network, the tail node will remove the IFIT tag to restore the data flow to the original target flow, ensuring the normal transmission of the service flow without interference. Throughout the process, by monitoring each key node in the network transmission path, IFIT can provide fine-grained, low-overhead real-time network performance monitoring, helping network operators quickly identify and locate potential network problems and optimize network performance.

[0007] It should be noted that the above-mentioned nodes need to be configured with the IFIT flow table before they can monitor the IFIT flow. At present, in order to improve the monitoring efficiency of the IFIT flow, a distributed rack device is proposed. The distributed rack device includes at least one line card board (also known as Line Card), each of which includes at least one multi-core chip (also known as Chip), each of which includes multiple flow control units (also known as Pipline, hereinafter referred to as PP), and each of which includes a network port and an IFIT flow table engine for monitoring the network port. In practice, it was found that the first detection node, the middle detection node, and the tail detection node based on the distributed rack device, when issuing the IFIT table, whether it is statically configured or dynamically learned, will be issued to all PPs of all line card boards, which will greatly waste the resources of each PP for storing the IFIT flow table. Summary of the invention

[0008] In order to overcome at least one of the deficiencies in the prior art, the present application provides a distributed IFIT flow table delivery method and related devices, specifically including:

[0009] In a first aspect, the present application provides a distributed IFIT flow table delivery method, which is applied to a control plane device connected to a distributed rack device for communication, wherein the distributed rack device includes at least one line card board, each of the line card boards includes at least one multi-core chip, each of the multi-core chips includes multiple flow control units, each of the flow control units includes a network port and an IFIT flow table engine for monitoring the network port, and the method includes:

[0010] Obtain the first IFIT flow table to be configured;

[0011] If the first IFIT flow table is associated with a target network port, obtaining a target flow control unit to which the target network port belongs;

[0012] Send the first IFIT flow table to the target flow control unit.

[0013] In combination with the optional implementation manner of the first aspect, obtaining the target flow control unit to which the target network port belongs includes:

[0014] If the target network port is an aggregation port, then determining each member port in the aggregation port;

[0015] Determine the target flow control unit to which each member port belongs respectively;

[0016] The sending the first IFIT flow table to the target flow control unit includes:

[0017] The first IFIT flow table is sent once to each target flow control unit respectively.

[0018] In combination with the optional implementation manner of the first aspect, the method further includes:

[0019] If the first IFIT flow table is not associated with a target network port, and the control plane device serves as an intermediate detection point, the second IFIT flow table is sent to each flow control unit, wherein the second IFIT flow table enables a message upload function based on the first IFIT flow table, and is used to instruct each flow control unit to upload message information of a message to be analyzed, and the message to be analyzed is a message that matches the first IFIT flow table;

[0020] Determine, according to the message information, a target network port associated with the second IFIT flow table;

[0021] Delete the second IFIT flow table issued by other flow control units other than the target flow control unit, wherein the target flow control unit is the flow control unit to which the target network port belongs.

[0022] In combination with the optional implementation manner of the first aspect, after determining the target network port associated with the second IFIT flow table according to the message information, the method further includes:

[0023] Disable the message upload function of the target flow control unit to which the target network port belongs.

[0024] In combination with the optional implementation manner of the first aspect, the method further includes:

[0025] Receiving reported new flow learning information, wherein the new flow learning information includes message information, input port information, and output port information of the new IFIT flow;

[0026] Generate a third IFIT flow table to be configured according to the new flow learning information;

[0027] If an existing flow table corresponding to the third IFIT flow table is detected, a newly added flow control unit is determined;

[0028] The third IFIT flow table is sent to the newly added flow control unit.

[0029] In conjunction with the optional implementation manner of the first aspect, the determining of a newly added flow control unit includes:

[0030] The newly added flow control unit is determined according to a comparison result between the network port associated with the third IFIT flow table and the network port associated with the original flow table.

[0031] In combination with the optional implementation manner of the first aspect, the method further includes:

[0032] Receive reported event monitoring information, wherein the event monitoring information includes a flow table identifier of a configured fourth IFIT flow table and an actual port through which a message that triggers the event passes;

[0033] Determine the fourth IFIT flow table according to the flow table identifier;

[0034] Compare the network port associated with the fourth IFIT flow table with the actual port to determine a newly added flow control unit;

[0035] The fourth IFIT flow table is sent to the flow increase control unit.

[0036] In a second aspect, the present application further provides a distributed IFIT flow table issuing device, which is applied to a control plane device connected to a distributed rack device for communication, wherein the distributed rack device includes a plurality of line card boards, each of which includes a plurality of flow control units, each of which includes a network port and an IFIT flow table engine for monitoring the network port, and the device includes:

[0037] A flow table acquisition module, used to acquire a first IFIT flow table to be configured;

[0038] a target determination module, configured to obtain a target flow control unit to which the target network port belongs if the first IFIT flow table is associated with the target network port;

[0039] A flow table sending module sends the first IFIT flow table to the target flow control unit.

[0040] In conjunction with the optional implementation manner of the second aspect, the target determination module is further specifically configured to:

[0041] If the target network port is an aggregation port, then determining each member port in the aggregation port;

[0042] Determine the target flow control unit to which each member port belongs respectively;

[0043] The flow table sending module is also specifically used for:

[0044] The first IFIT flow table is sent once to each target flow control unit respectively.

[0045] In conjunction with the optional implementation manner of the second aspect, the target determination module is further specifically configured to:

[0046] If the first IFIT flow table is not associated with a target network port, and the control plane device serves as an intermediate detection point, the second IFIT flow table is sent to each flow control unit, wherein the second IFIT flow table enables a message upload function based on the first IFIT flow table, and is used to instruct each flow control unit to upload message information of a message to be analyzed, and the message to be analyzed is a message that matches the first IFIT flow table;

[0047] Determine, according to the message information, a target network port associated with the second IFIT flow table;

[0048] The flow table sending module is also specifically used for:

[0049] Delete the second IFIT flow table issued by other flow control units other than the target flow control unit, wherein the target flow control unit is the flow control unit to which the target network port belongs.

[0050] In conjunction with the optional implementation manner of the second aspect, after determining the target network port associated with the second IFIT flow table according to the message information, the method further includes:

[0051] Disable the message upload function of the target flow control unit to which the target network port belongs.

[0052] In combination with the optional implementation manner of the second aspect, the flow table sending module is further used to:

[0053] Receiving reported new flow learning information, wherein the new flow learning information includes message information, input port information, and output port information of the new IFIT flow;

[0054] Generate a third IFIT flow table to be configured according to the new flow learning information;

[0055] If an existing flow table corresponding to the third IFIT flow table is detected, a newly added flow control unit is determined;

[0056] The third IFIT flow table is sent to the newly added flow control unit.

[0057] In combination with the optional implementation manner of the second aspect, the flow table sending module is further used to:

[0058] The newly added flow control unit is determined according to a comparison result between the network port associated with the third IFIT flow table and the network port associated with the original flow table.

[0059] In combination with the optional implementation manner of the second aspect, the flow table sending module is further used to:

[0060] Receive reported event monitoring information, wherein the event monitoring information includes a flow table identifier of a configured fourth IFIT flow table and an actual port through which a message that triggers the event passes;

[0061] Determine the fourth IFIT flow table according to the flow table identifier;

[0062] Compare the network port associated with the fourth IFIT flow table with the actual port to determine a newly added flow control unit;

[0063] The fourth IFIT flow table is sent to the flow increase control unit.

[0064] In a third aspect, the present application further provides a storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the distributed IFIT flow table sending method is implemented.

[0065] In a fourth aspect, the present application also provides a network device, which includes a control plane device and a distributed rack device that are communicatively connected, the control plane device includes a processor and a memory, the memory stores a computer program, and when the computer program is executed by the processor, the distributed IFIT flow table sending method is implemented.

[0066] Compared with the prior art, this application has the following beneficial effects:

[0067] The present application provides a distributed IFIT flow table sending method and related devices. Among them, the control plane device obtains the first IFIT flow table to be configured; if the first IFIT flow table is associated with a target network port, the target flow control unit to which the target network port belongs is obtained; and the first IFIT flow table is sent to the target flow control unit. In this way, compared with sending to all flow control units of all line cards, sending the first IFIT flow table to the target flow control unit in the distributed rack device in a targeted manner can improve the utilization efficiency of IFIT Flow resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0069] Figure 1 One of the schematic diagrams of the IFIT flow monitoring principle provided in the embodiment of the present application;

[0070] Figure 2The second schematic diagram of the IFIT flow monitoring principle provided in the embodiment of the present application;

[0071] Figure 3 One of the schematic diagrams of the delay calculation principle provided in the embodiment of the present application;

[0072] Figure 4 The second schematic diagram of the delay calculation principle provided in the embodiment of the present application;

[0073] Figure 5 A schematic diagram of the principle of the flow table configuration method provided in the embodiment of the present application;

[0074] Figure 6 A schematic diagram of the structure of a distributed rack device provided in an embodiment of the present application;

[0075] Figure 7 A flowchart of a distributed IFIT flow table delivery method provided in an embodiment of the present application;

[0076] Figure 8 A schematic diagram of path changes between devices provided in an embodiment of the present application;

[0077] Fig. 9 A schematic diagram of path changes within a device provided in an embodiment of the present application;

[0078] Fig.10 A schematic diagram of the structure of a distributed IFIT flow table delivery device provided in an embodiment of the present application;

[0079] Fig.11 A schematic diagram of the structure of a control plane device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0080] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

[0081] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for which protection is sought, but merely represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0082] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, further definition and explanation thereof is not required in subsequent drawings.

[0083] In the description of the present application, it should be noted that the terms "first", "second", "third", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance. In addition, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device including the element.

[0084] Based on the above statement, in order to make the following embodiments easier to understand, Figure 2 , Figure 3 , Figure 4 Explain the packet loss and delay detection principles based on IFIT flow:

[0085] First of all, it should be understood that the IFIT detection process mainly involves three objects: the target flow, the network through which the target flow passes, and the detection system.

[0086] (1) Target flow:

[0087] By using the IFIT flow table to monitor the target flow, this embodiment provides three different monitoring intensities, allowing the received messages to be matched with different degrees of precision. According to the matching results, the pre-configured operations in the IFIT flow table will be performed on the successfully matched messages. The hierarchical monitoring mechanism provided by this implementation ensures that different traffic characteristics can be flexibly responded to, thereby achieving more accurate and efficient traffic management and analysis. The following is a detailed description of these three detection intensities:

[0088] The five-tuple granularity can uniquely determine the detection flow by specifying the relevant field information in the IP packet header, including the five-tuple of source IP address, destination IP address, protocol number, source port number, destination port number, and DSCP. This method is suitable for performance detection of specific flows. For example, if you want to monitor the network activity of a specific application or the access traffic of a specific website, then the five-tuple granularity detection is the most appropriate.

[0089] MAC granularity can uniquely determine the detection flow by specifying the relevant field information in the Ethernet packet header, including the source MAC address, destination MAC address, and protocol type. This method is suitable for performance testing of specific flows. Therefore, MAC granularity detection allows network administrators to track and analyze traffic at a more granular level. For example, in a local area network (LAN) environment, when it is necessary to monitor the communication traffic between specific devices, MAC granularity detection is particularly important.

[0090] Peer granularity is a more macroscopic detection method, mainly used to track end-to-end traffic conditions. It generates target flows by specifying the peer IPv4 / IPv6 address or the peer locator mechanism. This method is suitable for performance detection of the overall end-to-end traffic. Therefore, peer granularity detection is suitable for analyzing the overall trend and performance indicators of traffic from a specific source to a specific destination in the network, such as evaluating the end-to-end quality of service (QoS) of a specific business or application in a data center network.

[0091] (2) Traversing the network:

[0092] The network that the target flow traverses is the network that carries the target flow, that is, the target flow is neither generated nor terminated in the network, and each node in the network is required to have IP reachability. That is, it can be addressed and routed through the IP protocol so that the data packet can reach the destination point accurately from the source point. Depending on the different carrying networks, this implementation supports the following 6 types of traversal networks:

[0093] SRv6 tunnel,SRv6 tunnel is a tunnel technology based on Segment Routing (SR), which uses IPv6 prefix and label sequence to define the path. SRv6 allows flexible and programmable path control on IP networks, thereby supporting various types of data transmission, including multicast, broadcast and specific application requirements.

[0094] MPLS-SR tunnel combines the features of MPLS (Multiprotocol Label Switching) and SR to create an efficient traffic path on the IP / MPLS network while using the flexibility of SR to configure and optimize the path.

[0095] MPLS tunnel, the traditional MPLS tunnel technology, is used to provide a dedicated and reliable transmission path in a multi-protocol IP network. MPLS tunnel achieves fast forwarding by adding labels to data packets, improving network efficiency and security.

[0096] VxLAN Tunnel,VxLAN (Virtual eXtensible Local Area Network) is a UDP-based Layer 2 tunnel protocol used to extend the network in a virtualized environment.,Therefore, it allows the creation of virtual networks on the existing physical network infrastructure,,supporting larger-scale virtual machine (VM) migration and network isolation.

[0097] Native IPv4 network refers to a network built directly based on the IPv4 protocol, which is suitable for traditional Internet communications, enterprise LANs, etc. In these scenarios, IPv4 provides basic IP addressing and routing functions to support various applications and services.

[0098] Native IPv6 network is similar to Native IPv4, but based on IPv6 protocol, it provides a larger address space and supports more advanced network functions, such as multiplexing, flow table tagging, network security enhancement, etc. Therefore, IPv6 network is particularly suitable for the needs of future networks, including the Internet of Things, mobile communications and other fields.

[0099] (3) Detection system

[0100] Based on the introduction of the target flow and the target flow's traversal network in the above embodiment, Figure 2 As shown, the detection system includes the head node, the middle node, and the tail node:

[0101] The first node is the device where the target flow enters the traversal network. It is responsible for screening the target flow, adding an IFIT message header to the target flow, collecting the detection data of the target flow and reporting it to the analyzer.

[0102] The intermediate node automatically identifies the IFIT target flow according to whether the message contains the IFIT message header, and then decides whether to collect the detection data of the target flow and report it to the analyzer according to the measurement type carried in the IFIT header.

[0103] The tail node is the device where the target flow leaves the target and traverses the network. The tail node automatically identifies the IFIT target flow based on whether the message contains the IFIT message header, collects the detection data of the target flow and reports it to the analyzer, and finally strips off the IFIT message header of the target flow to restore the message to the original target flow.

[0104] The analyzer is responsible for collecting the detection data sent by the head node, intermediate node, and tail node and completing the data aggregation and calculation.

[0105] Therefore, each node performs different IFIT processing operations at the detection point granularity. According to different processing operations, there are mainly three types of detection points:

[0106]

[0107]

[0108] Based on the above embodiments, the target flow, the target flow's traversal network, and the detection system, IFIT can be used to detect packet loss and delay of messages. Figure 3 As shown in the figure, IFIT packet loss detection detects packet loss at different nodes in the network by marking and counting packets, and determines the location of packet loss. At the same time, the packet loss rate can be calculated. The detection process is as follows:

[0109] (1) Detect the start L-bit flag of the timer

[0110] In IFIT packet loss detection, the CPU of the first detection point will run a detection timer. The detection period of the detection timer is configured by the user, such as 1 second, 10 seconds, 60 seconds or 300 seconds. Each time the detection timer starts, the first detection point will mark the message of the target flow and set the value of the packet loss coloring mark (L-bit) of the message. In order to avoid statistical errors, the value of L-bit is alternately set to 0 and 1 in adjacent detection cycles. For example, if the value of L-bit is 0 in one cycle, then the value of L-bit will be set to 1 in the next cycle, and so on.

[0111] (2) Message statistics at each detection point

[0112] The CPU at the first detection point, the middle detection point, and the last detection point will run a statistical timer to count the received messages with the corresponding L-bit mark.

[0113] (3) Data statistics and clearing

[0114] When the statistical timer cycle ends, each detection point will read and clear the message count corresponding to the L-bit counted in the cycle. This process ensures that the count in the next statistical cycle will not be affected by the data in the previous cycle, thereby ensuring the accuracy of the statistical results.

[0115] (4) Packet loss detection and analysis

[0116] Each detection point (first detection point, middle detection point and last detection point) reports its counted packet count to the analyzer. Assume that the count of the first detection point is P i , the count of the middle detection point is P m , the count of the tail detection point is P e , the analyzer can determine whether there is packet loss, determine the location of packet loss, and calculate the packet loss rate by comparing these count values. i >P m >P e, it means that there is packet loss between the first detection point and the middle detection point and between the middle detection point and the last detection point.

[0117] like Figure 4 As shown in the figure, by marking the message with delay (D-bit), recording the timestamp of the message at different nodes in the network, the delay between nodes, within a node, and end-to-end can be calculated. The detection process is as follows:

[0118] (1) Detection timer start and D-bit marking

[0119] In IFIT delay detection, the CPU of the first detection point will run a detection timer. The detection period of this timer is also configured by the user, such as 1 second, 10 seconds, 30 seconds, 60 seconds or 300 seconds. At the beginning of each block detection period, the first detection point will set the delay coloring mark (D-bit) value of the first message of the target flow to 1, and set the D-bit value of subsequent messages to 0. In other words, in each block detection period, only one message is marked for delay detection, avoiding the extra burden brought by the delay statistics of a large number of messages.

[0120] (2) Time record of each testing point

[0121] When the first detection point, the middle detection point, and the last detection point receive a message with a D-bit value of 1, these detection points will immediately record the current timestamp. These timestamps reflect the specific arrival time of the message with a D-bit of 1 at each node. For example, Figure 4 The timestamps t0, t1, t2, t3, t4, t5, etc. in the table represent the specific arrival time of the message at the first node, the middle node, and the last node, respectively.

[0122] (3) Delay calculation and analysis

[0123] The timestamps recorded at each detection point will be reported to the analyzer. The analyzer can calculate the network delay based on these timestamps, including the delay between nodes, the delay within a node, and the total end-to-end delay. Specifically:

[0124] The inter-node delay can be calculated by comparing the timestamps of two adjacent nodes.

[0125] The intra-node delay can be calculated by comparing the timestamps of the inbound and outbound directions of the same node, for example, Figure 3 The difference between t1 and t0 can also reflect the delay of internal processing in the first node.

[0126] The total end-to-end delay can be calculated by comparing the timestamps of the first and last nodes, for example, Figure 4 The difference between t5 and t0 in represents the total delay experienced by the message from the head node to the tail node.

[0127] Based on the above embodiments, the IFIT packet loss and IFIT delay detection are described below. Figure 5 This chapter introduces the generation and configuration of IFIT flow tables. Currently, flow table generation methods include static configuration and dynamic learning:

[0128] Static configuration: The user directly specifies the Flow Key information and binding port, which are then sent to the ASIC on the data plane.

[0129] Dynamic learning: The user only specifies a whitelist, which can be a message feature, port information or all messages. The messages that do not find the corresponding IFIT Flow in the ASIC and meet the whitelist will be sent to the CPU for analysis and learning, and then the IFIT Flow will be generated and sent to the chip.

[0130] For different detection nodes, the types of IFIT flow tables are shown in the following table:

[0131]

[0132] The Linkagg port in the above table refers to the aggregation port, which means the technology of logically bundling multiple physical network interfaces into a single high-bandwidth interface. In link aggregation, these physical interfaces work together to increase the bandwidth of the link and provide redundancy, that is, when one of the physical interfaces fails, other interfaces can take over the traffic of the failed interface to ensure the continuity and stability of the network.

[0133] Based on the above embodiment, the generation and configuration of the IFIT flow table are introduced. Figure 6 This chapter introduces the structure of distributed rack equipment. Figure 6 As shown, the distributed chassis device is used as a data plane device. One distributed chassis device (Chassis) includes one or more line cards (Line Card). When there are multiple line cards, these line cards are divided into Fabric Card, Master Card and ordinary Line Card.

[0134] Continue to see Figure 6 Each line card contains one or more chips, where the chip is a multi-core type. The functions of these line cards can be realized by ASIC, which usually provides higher processing speed and lower power consumption, and is suitable for network applications that require high performance; of course, these line cards can also be realized by general-purpose processors, which is more flexible and suitable for scenarios that require frequent updates and adjustments of functions.

[0135] Continue to see Figure 6 Each Multi-Core Chip contains multiple PPs (PipeLines); each PP is the finest-grained execution unit, containing a pair of IFIT Flow engines, one IFIT Flow engine in the inbound direction and one in the outbound direction; each PP includes multiple DPs (DataPaths), which are responsible for specific port-level data packet forwarding and processing tasks; each network port uniquely belongs to one DP.

[0136] for Figure 6 In the distributed rack device shown in the figure, PP is the finest granularity unit for IFIT Flow delivery, and each network port belongs to a PP. However, when delivering IFIT flow tables, whether statically configured or dynamically learned, they will be delivered to all PPs of all line cards, which will greatly waste the resources of each PP for storing IFIT flow tables.

[0137] Based on the discovery of the above technical problems, the inventors have proposed the following technical solutions to solve or improve the above problems through creative work. It should be noted that the defects in the solutions in the above prior art are the results obtained by the inventors after practice and careful research. Therefore, the discovery process of the above problems and the solutions proposed in the embodiments of the present application for the above problems below should all be the contributions made by the inventors to the present application in the process of invention and creation, and should not be understood as technical contents known to those skilled in the art.

[0138] In view of the above technical problems, this embodiment provides a distributed IFIT flow table sending method. In this method, the control plane device obtains the first IFIT flow table to be configured; if the first IFIT flow table is associated with a target network port, the target flow control unit to which the target network port belongs is obtained; and the first IFIT flow table is sent to the target flow control unit. In this way, compared with sending to all flow control units of all line cards, sending the first IFIT flow table to the target flow control unit in the distributed rack device in a targeted manner can improve the utilization efficiency of IFIT flow table resources.

[0139] It should be noted that control plane devices refer to general-purpose controllers that can perform multiple tasks and handle a wide range of applications. For example, controllers with integrated general-purpose CPUs are general-purpose controllers. General-purpose CPUs can run a variety of software programs, from operating systems to applications, covering a wide range of functions from data processing, computing to image rendering. Therefore, they are widely used in personal computers, servers, mobile devices and other devices.

[0140] The data plane device corresponds to the control plane device, which is used to perform operations such as fast forwarding, filtering, and encryption of data packets according to the forwarding table established by the control plane. In this embodiment, the distributed rack device is used as the data plane device. Therefore, in this embodiment, the network device including the above control plane device and the distributed rack device can be used as a switch or a router.

[0141] To make the solution provided by this embodiment clearer, Figure 7 Each step of the method is described in detail. However, it should be understood that the operations of the flowchart may not be implemented in order, and steps without logical contextual relationships may be reversed in order or implemented simultaneously. In addition, those skilled in the art may add one or more other operations to the flowchart, or remove one or more operations from the flowchart under the guidance of the content of this application. Figure 7 As shown, the method includes:

[0142] S1, obtaining a first IFIT flow table to be configured.

[0143] The IFIT flow table acquisition methods include static configuration and dynamic learning. For an introduction to static configuration and dynamic learning, see Figure 5 The detailed description is omitted in this embodiment.

[0144] S2: Determine whether the first IFIT flow table is associated with a target network port.

[0145] If there is no target network port associated, execute Figure 7 Step S3 in the above example, otherwise, execute Figure 7 S4 in.

[0146] S3, learning the first IFIT flow table.

[0147] S4, obtaining the target flow control unit to which the target network port belongs.

[0148] In this regard, it should be understood that, in this embodiment, according to the association between the IFIT flow table and the port, the IFIT flow table is divided into three categories: Port, Linkagg, and Global. The differences between these three types of IFIT flow tables are as follows:

[0149] Port type: The flow table is associated with only one physical port.

[0150] Linkagg type: The flow table is associated with only one Linkagg port.

[0151] Global type: The flow table is globally associated. When generating the flow table, it is not possible to clearly identify which port or link is associated. For the first and last detection points, there may be multiple associated ports at the same time; for the middle detection point, there is only one associated port at the same time.

[0152] Therefore, both the Port type and the Linkagg type are associated with clear ports. The former is a single physical port, while the latter is an aggregated Linkagg port.

[0153] Therefore, if the first IFIT flow table is not associated with a target network port, it means that when the first IFIT flow table is of the above-mentioned Global type, it is not clear which Port or Linkagg is associated with it. Therefore, it is necessary to further learn the target network port associated with the first IFIT flow table. For Port and Linkagg types, the flow table is only sent up and down on the associated PP.

[0154] S5, sending the first IFIT flow table to the target flow control unit.

[0155] It is worth noting that when the first IFIT flow table is the above-mentioned Linkagg type flow table, the control plane device determines each member port in the target network port; determines the target flow control unit to which each member port belongs; sends the first IFIT flow table to the target flow control unit, and then sends the first IFIT flow table to each target flow control unit once.

[0156] It can be understood that when the first IFIT flow table is a Linkagg type flow table, the target network port is actually aggregated by multiple member ports, and some of the member ports belong to the same target flow control unit. At this time, this embodiment only needs to send one IFIT flow table to the target flow control unit so that these member ports share the flow table, without sending it once for each member port.

[0157] for Figure 7 In step S4, it should be noted that for the first and second detection nodes, there may be multiple associated ports at the same time, and this embodiment does not learn them. Therefore, the first IFIT flow table is directly sent to each flow control unit. For the intermediate detection node, the target network port associated with the first IFIT flow table is learned. Therefore, this embodiment also provides the following optional implementation of step S4:

[0158] S4-1, determine whether the control plane device serves as an intermediate detection node.

[0159] If yes, execute step S4-2, otherwise execute step S4-3.

[0160] S4-2, sending the first IFIT flow table to each flow control unit.

[0161] S4-3, send the second IFIT flow table to each flow control unit.

[0162] Among them, the second IFIT flow table enables the message upload function based on the first IFIT flow table, which is used to instruct each flow control unit to upload the message information of the message to be analyzed, and the message to be analyzed represents the message that matches the first IFIT flow table. It can be understood that the second IFIT flow table adds a message upload function based on the first IFIT flow table, so that when the flow control unit receives the message to be analyzed that matches the Key in the second IFIT flow table, it uploads the message information of the message to be analyzed to the control plane device.

[0163] S4-4, determining the target network port associated with the second IFIT flow table according to the message information, and deleting the second IFIT flow table issued by other flow control units except the target flow control unit.

[0164] Among them, the target flow control unit is the flow control unit to which the target network port belongs. It should be noted that the message information of the message to be analyzed includes the flow table identifier (FlowId), the input port information, and the output port information. The control plane device finds the corresponding IFIT flow table (i.e., the second IFIT flow table) according to the FlowId. Since the second IFIT flow table is of Global type, it means that the second IFIT flow table has been sent to all flow control units before. Therefore, after determining the target flow control unit according to the target network port, in order to save the resources of other flow control units other than the target flow control unit, the second IFIT flow table that has been sent needs to be deleted.

[0165] If the control plane device determines that the target network port associated with the second IFIT flow table is a Linkagg port after analyzing the inbound port information and the outbound port information, the second IFIT flow table is considered as a Linkagg type, and all corresponding target PPs are searched based on all Linkagg member ports. On the contrary, if it is not a Linkagg port, it is considered as a Port type, and the corresponding target PP is searched based on the Port. Then, for other PPs other than the target PP, the second IFIT flow table that has been issued is deleted.

[0166] It can be understood that, for the Global type IFIT flow table, this embodiment attempts to learn the input port and output port information; if the learning is successful, it will be converted into a Port type or Linkagg type according to the learned information, so that the flow table is only sent to the associated PP, so as to achieve the purpose of accurate sending and saving chip flow table resources.

[0167] In addition, after determining the target network port associated with the second IFIT flow table according to the message information, the method further includes:

[0168] S4-5, close the message upload function of the target flow control unit to which the target network port belongs.

[0169] In this way, the target flow control is prevented from continuing to report the message information of the message to be analyzed, which wastes additional computing resources.

[0170] After the above configuration, the control plane device enters the stable stage from the learning stage. At this time, the control plane device performs conventional IFIT packet loss detection and delay detection processing. Then, due to routing changes or ECMP path selection changes, the path that the traffic passes through will change. In this regard, Figure 8 As shown in the figure, Flow 1 represents the IFIT flow in the stable stage, and its path changes are mainly divided into two scenarios:

[0171] (1) Changes in the equipment being passed (Flow 2 in the figure)

[0172] (2) The device passed through remains unchanged, but the inlet or outlet port changes (Flow 3 in the figure)

[0173] It should be noted that the scenario of "the device passing through changes" is not within the scope of this embodiment because the traffic no longer passes through this device. This implementation mainly provides a solution for the scenario of "the device passing through remains unchanged, but the inlet or outlet port changes".

[0174] like Fig. 9 As shown in the figure, the port changes can be divided into four scenarios:

[0175] (1) Both the inlet and outlet PP remain unchanged (Flow 2 in the figure)

[0176] (2) The input PP changes, but the output PP remains unchanged (Flow 3 in the figure)

[0177] (3) The input PP remains unchanged, but the output PP changes (Flow 4 in the figure)

[0178] (4) Both the in-PP and out-PP change (Flow 5 in the figure)

[0179] Therefore, it is necessary to perceive the changes in the IFIT flow forwarding port in the update phase after the stabilization phase. Research has found that there are at least two events in distributed rack devices, namely new flow learning events and D-bit timestamp reporting events. Therefore, this embodiment reuses the above two events, and carries additional inbound and outbound port information in the information originally reported to the control plane device, helping the control plane device to perceive the changes in the inbound and outbound ports of the traffic, thereby further perceiving the changes in the inbound PP and outbound PP.

[0180] For a new flow learning event, this embodiment provides the following optional implementation methods for sensing port changes:

[0181] S6A, receiving reported new flow learning information.

[0182] The new flow learning information includes the message information, input port information, and output port information of the new IFIT flow.

[0183] S7A, generating a third IFIT flow table to be configured according to the new flow learning information.

[0184] S8A, if the original flow table corresponding to the third IFIT flow table is detected, a newly added flow control unit is determined.

[0185] In a specific implementation manner, a newly added flow control unit is determined according to a comparison result between a network port associated with the third IFIT flow table and a network port associated with the original flow table.

[0186] S9A, sends the third IFIT flow table to the newly added flow control unit.

[0187] Exemplarily, the control plane device receives new flow learning information, including message information, ingress port information, and egress port information; then, parses and learns the message to generate a third IFIT flow table.

[0188] Next, the control plane device detects whether the third IFIT flow table already exists. If not, the conventional IFITFlow delivery process is performed.

[0189] If the original flow table already exists, it is considered that the port has changed. Therefore, the control plane device compares the newly received inlet and outlet information with the inlet and outlet information saved in the original flow table to determine the PP change.

[0190] If the input PP changes and the output PP changes, the control plane device sends the third IFIT flow table to the newly added PP, and then deletes the third IFIT flow table that has been sent in the PP to be removed.

[0191] If both the input PP and the output PP change, the processing method is the same as "the input PP changes, the output PP changes", so it will not be described in detail. However, it should be noted that the new flow learning will not appear "the input PP and the output PP are unchanged" and "the input PP is unchanged, the output PP changes" scenario, which will not be discussed.

[0192] For event monitoring information such as D-bit timestamp reporting events, this implementation provides the following optional implementation methods for sensing port changes:

[0193] S6B, receiving reported event monitoring information, where the event monitoring information includes the flow table identifier of the configured fourth IFIT flow table and the actual port through which the message that triggers the event passes.

[0194] S7B, determine the fourth IFIT flow table according to the flow table identifier.

[0195] S8B, compare the network port associated with the fourth IFIT flow table with the actual port to determine a newly added flow control unit.

[0196] S9B, send the fourth IFIT flow table to the flow increase control unit.

[0197] Exemplarily, the control plane device receives event monitoring information of a D-bit timestamp reporting event, including message information, flow table identifier (FlowId), timestamp, input port information, output port information, and other information; then, the fourth IFIT flow table is searched according to FlowId.

[0198] Since it is a D-bit timestamp reporting event, the control plane device also needs to perform the regular D-bit timestamp processing process;

[0199] Next, the control plane device compares the newly received inbound port and outbound port information with the inbound port and outbound port information stored in the fourth IFIT flow table to determine the PP change.

[0200] If the inbound PP and the outbound PP remain unchanged, there is no need to process the IFIT Flow in the distributed rack device.

[0201] If the inbound PP remains unchanged but the outbound PP changes, the fourth IFIT flow table is sent to the newly added PP, and then the fourth IFIT flow table sent in the PP to be removed is deleted. It should be noted that the D-bit timestamp reporting will not have the scenarios of "inbound PP changes but outbound PP remains unchanged" and "both inbound PP and outbound PP change", which will not be discussed further.

[0202] Based on the same inventive concept as the distributed IFIT flow table sending method provided in this embodiment, this embodiment also provides a distributed IFIT flow table sending device, which is applied to a control plane device that is communicatively connected to a distributed rack device, wherein the distributed rack device includes a plurality of line card boards, each line card board includes a plurality of flow control units, each flow control unit includes a network port and an IFIT flow table engine that monitors the network port. In addition, the device includes at least one software function module that can be stored in the memory 21 in software form or solidified in the control plane device. The processor 22 in the control plane device is used to execute the executable module stored in the memory 21. For example, the software function modules and computer programs included in the device. Please refer to Fig.10 , functionally speaking, the device may include:

[0203] The flow table acquisition module 11 is used to acquire the first IFIT flow table to be configured;

[0204] A target determination module 12 is used to obtain a target flow control unit to which the target network port belongs if the first IFIT flow table is associated with the target network port;

[0205] The flow table sending module 13 sends the first IFIT flow table to the target flow control unit.

[0206] In this embodiment, the flow table acquisition module 11 is used to implement Figure 7 In step S1, the target determination module 12 is used to implement Figure 7 S2, S3, S4 in the flow table sending module 13 is used to implement Figure 7 S5 in. Therefore, for the detailed description of the above modules, please refer to the specific implementation of the corresponding steps. In addition, in view of the same inventive concept as the distributed IFIT flow table delivery method, the device can also implement other steps or sub-steps of the method through the above modules or other modules, which will not be repeated in this embodiment.

[0207] In addition, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0208] It should also be understood that if the above implementation is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application.

[0209] Therefore, this embodiment further provides a storage medium, which stores a computer program, and when the computer program is executed by a processor, the distributed IFIT flow table delivery method provided in this embodiment is implemented. The storage medium can be a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and other media that can store program codes.

[0210] This embodiment provides a network device, including a control plane device and a distributed rack device connected in communication. Fig.11 As shown, the control plane device includes a processor 22 and a memory 21. In addition, the memory 21 stores a computer program, and the processor implements the distributed IFIT flow table delivery method provided in this embodiment by reading and executing the computer program corresponding to the above implementation in the memory 21.

[0211] Continue to see Fig.11 The memory 21, processor 22 and other possible components are electrically connected to each other directly or indirectly through a system bus 24 to achieve data transmission or interaction.

[0212] The memory 21 may be an information recording device based on any electronic, magnetic, optical or other physical principle, used to record execution instructions, data, etc. In some embodiments, the memory 21 may be, but is not limited to, a volatile memory, a non-volatile memory, a storage drive, etc.

[0213] In some embodiments, the volatile memory may be a random access memory (RAM); in some embodiments, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable read-only memory (EEPROM), a flash memory, etc.; in some embodiments, the storage drive may be a disk drive, a solid-state drive, any type of storage disk (such as a CD, a DVD, etc.), or a similar storage medium, or a combination thereof, etc.

[0214] Understandably, Fig.11 The structure shown is for illustration only and may also have Fig.11 More or fewer components than shown, or with Fig.11 Different configurations are shown. Fig.11 The components shown can be implemented by hardware, software or a combination thereof. That is, the implementation of the processing flow in the above embodiments is not limited to the processor reading and running pure computer-readable program code from the memory, but can also be implemented by hardware or logic devices.

[0215] It should be understood here that improvements to a technology can be divided into hardware improvements (for example, improvements to circuit structures such as diodes, transistors, switches, etc.) and software improvements (improvements to method flows). However, with the development of technology, many improvements to method flows today can be regarded as direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement to a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user programming the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and make a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. Among them, VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog are currently the most commonly used. Those skilled in the art should also be aware that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0216] It should be understood that the apparatus and method disclosed in the above-mentioned embodiments can also be implemented in other ways. The apparatus embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the apparatus, methods and computer program products according to the multiple embodiments of the present application. In this regard, each block in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each block in the block diagram and / or the flowchart, and the combination of the blocks in the block diagram and / or the flowchart, can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0217] The above are only various implementations of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A distributed IFIT flow table delivery method, characterized in that: A control plane device applied to a communication connection with a distributed rack device, wherein the distributed rack device includes at least one line card board, each of the line card boards includes at least one multi-core chip, each of the multi-core chips includes multiple flow control units, each of the flow control units includes a network port and an IFIT flow table engine for monitoring the network port, and the method includes: Obtain the first IFIT flow table to be configured; If the first IFIT flow table is associated with a target network port, obtaining a target flow control unit to which the target network port belongs; Send the first IFIT flow table to the target flow control unit.

2. The distributed IFIT flow table delivery method according to claim 1, characterized in that: The obtaining of the target flow control unit to which the target network port belongs includes: If the target network port is an aggregation port, then determining each member port in the aggregation port; Determine the target flow control unit to which each member port belongs respectively; The sending the first IFIT flow table to the target flow control unit includes: The first IFIT flow table is sent once to each target flow control unit respectively.

3. The distributed IFIT flow table delivery method according to claim 1, characterized in that: The method further comprises: If the first IFIT flow table is not associated with a target network port, and the control plane device serves as an intermediate detection point, a second IFIT flow table is issued to each flow control unit, wherein the second IFIT flow table enables a message upload function based on the first IFIT flow table, and is used to instruct each flow control unit to upload message information of a message to be analyzed, and the message to be analyzed is a message matching the first IFIT flow table; Determine, according to the message information, a target network port associated with the second IFIT flow table; Delete the second IFIT flow table issued by other flow control units other than the target flow control unit, wherein the target flow control unit is the flow control unit to which the target network port belongs.

4. The distributed IFIT flow table delivery method according to claim 3 is characterized in that: After determining the target network port associated with the second IFIT flow table according to the message information, the method further includes: Disable the message upload function of the target flow control unit to which the target network port belongs.

5. The distributed IFIT flow table delivery method according to claim 1, characterized in that: The method further comprises: Receiving reported new flow learning information, wherein the new flow learning information includes message information, input port information, and output port information of the new IFIT flow; Generate a third IFIT flow table to be configured according to the new flow learning information; If an existing flow table corresponding to the third IFIT flow table is detected, a newly added flow control unit is determined; The third IFIT flow table is sent to the newly added flow control unit.

6. The distributed IFIT flow table delivery method according to claim 5, characterized in that: The determining of a newly added flow control unit includes: The newly added flow control unit is determined according to a comparison result between the network port associated with the third IFIT flow table and the network port associated with the original flow table.

7. The distributed IFIT flow table delivery method according to claim 1, characterized in that: The method further comprises: Receive reported event monitoring information, wherein the event monitoring information includes a flow table identifier of a configured fourth IFIT flow table and an actual port through which a message that triggers the event passes; Determine the fourth IFIT flow table according to the flow table identifier; Compare the network port associated with the fourth IFIT flow table with the actual port to determine a newly added flow control unit; The fourth IFIT flow table is sent to the flow increase control unit.

8. A distributed IFIT flow table delivery device, characterized in that: A control plane device applied to a communication connection with a distributed rack device, wherein the distributed rack device includes a plurality of line cards, each of which includes a plurality of flow control units, each of which includes a network port and an IFIT flow table engine for monitoring the network port, wherein the device includes: A flow table acquisition module, used to acquire a first IFIT flow table to be configured; a target determination module, configured to obtain a target flow control unit to which the target network port belongs if the first IFIT flow table is associated with the target network port; A flow table sending module sends the first IFIT flow table to the target flow control unit.

9. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the distributed IFIT flow table sending method described in any one of claims 1 to 7 is implemented.

10. A network device, characterized in that: The network device includes a control plane device and a distributed rack device that are communicatively connected. The control plane device includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, the distributed IFIT flow table sending method described in any one of claims 1-7 is implemented.

Images