Method and device for determining port attributes

Abstract

The present application provides a method and apparatus for determining port attributes, which can be applied to data center networks, such as fat-tree networks. The method includes: a first network device receives a protocol data unit PDU sent by a second network device through a first port; the first network device determines whether the first port is an uplink port or a downlink port based on the PDU. In an embodiment of the present application, the first network device can determine whether the first port is an uplink port or a downlink port based on the PDU sent by the second network device, providing a basis for subsequently helping the SDN controller to reduce the load. This avoids the situation in the prior art where the network device is unable to obtain the above configuration, resulting in the inability to help the SDN controller reduce the load.

Description

Technical Field

[0001] The present application relates to the field of information technology, and more particularly, to a method and apparatus for determining port attributes. Background Art

[0002] Software Defined Network (SDN) is a method of implementing network virtualization that aims to separate the control plane from the data plane of network devices, thereby achieving flexible control of data flow, making the network as a pipeline more intelligent, and providing a good platform for innovation in core networks and applications.

[0003] Currently, SDN technology is widely used in data center networks, with SDN controllers managing switches within these networks. For example, they obtain the data center network topology and, based on this topology, generate flow control policies for the data flows within the data center. These policies are then sent to network devices, which then control the data flows based on these flow control policies. This means that the SDN controller needs to understand the data center network configuration, such as the network topology and the port properties of network devices. However, network devices do not need to know the data center configuration; they simply transmit data flows based on the SDN controller's instructions.

[0004] As data center networks continue to expand, the load on SDN controllers is increasing, impacting data center performance. To reduce the load on SDN controllers, it's desirable to transfer functions previously performed by SDN controllers to network devices. However, currently, network devices lack access to these configurations, making it impossible to help reduce the SDN controller load. Summary of the Invention

[0005] The present application provides a method and apparatus for determining port attributes, so that a network device can learn the port attributes of its own port, providing a basis for subsequently helping an SDN controller reduce the load.

[0006] In a first aspect, a method for determining port attributes is provided, including: a first network device receives a protocol data unit (PDU) sent by a second network device through a first port; and the first network device determines whether the first port is an uplink port or a downlink port based on the PDU.

[0007] In this embodiment of the present application, the first network device can determine whether the first port is an uplink port or a downlink port based on the PDU sent by the second network device, providing a basis for subsequently helping the SDN controller reduce the load. This avoids the problem in the prior art where the network device is unable to know the above configuration and is unable to help the SDN controller reduce the load.

[0008] In one possible implementation, the PDU carries the level of the second network device in the network, and / or the PDU carries the port attributes of the second port used by the second network device to send the PDU, and the port attributes of the second port include that the second port is an uplink port or the second port is a downlink port.

[0009] In an embodiment of the present application, by carrying the level of the second network device and at least one information of the port attribute of the second port in the PDU, it is helpful to more intuitively assist the first network device in determining whether the first port is an uplink port or a downlink port.

[0010] In a possible implementation, the first network device determines, based on the PDU, that the first port is an uplink port or a downlink port, including: the first network device determines, based on the PDU, the level of the first network device in the network; and the first network device determines, based on the level of the first network device, that the first port is an uplink port or a downlink port.

[0011] In the embodiment of the present application, the first network device determines whether the first port is an uplink port or a downlink port according to the level of the first network device, which is conducive to improving the accuracy of determining the port attribute of the first port.

[0012] In one possible implementation, the network includes multiple network devices, the multiple network devices include the second network device, and the first network device receives the protocol data unit PDU sent by the second network device through the first port, including: the first network device receives multiple PDUs sent by the multiple network devices through multiple ports, the multiple ports include the first port, and the multiple PDUs include the PDU sent by the second network device; the first network device determines the level of the first network device in the network based on the PDU, including: the first network device determines the level of the multiple network devices in the network based on the multiple PDUs; the first network device selects a target level from the levels of the multiple network devices; the first network device determines the level of the first network device based on the target level and preset rules.

[0013] In an embodiment of the present application, the first network device determines a target level based on the levels of multiple network devices, and then determines the level of the first network device according to the target level and preset rules, so that the first network device can determine the level of the first network device based on the levels of multiple network devices, which is conducive to improving the reliability of determining the level of the first network device.

[0014] Optionally, the above-mentioned multiple network devices are network devices directly connected to the first network device, that is, the layers where the multiple network devices are located in the network are adjacent to the layer where the first network device is located.

[0015] It should be noted that the layer where the above-mentioned multiple network devices are located can be one layer or multiple layers. When the layer where the multiple network devices are located can be one layer, that is, the multiple network devices are located at the same layer, and the layer is adjacent to the layer of the first network device. When the layer where the multiple network devices are located can be multiple layers, at least two of the multiple network devices are located at different layers, and the multiple layers are adjacent to the layer of the first network device. For example, the multiple layers may include a layer in the network located north of the layer where the first network device is located, and a layer south of the layer where the first network device is located.

[0016] Optionally, the aforementioned multiple network devices may be network devices that are not adjacent to the first network device. For example, multiple network devices may be root nodes, and the hierarchy of the first network device is separated from the hierarchy of the multiple network devices by one or more layers. In this case, the multiple network devices may send the root node hierarchy number to the first network device via multiple PDUs. Each of the multiple PDUs may record the number of network devices passed when transmitting the corresponding PDU to the first network device, i.e., the number of hops required to transmit the PDU to the first network device. The first network device may determine the hierarchy number of the first network device based on the PDU and the hop count.

[0017] Optionally, the preset rule may be based on the target level and increase a preset value, for example, 1. The preset rule may also be based on the target level and decrease a preset value, for example, 1. The preset rule may also be represented by a nonlinear function.

[0018] In a possible implementation, the first network device determines that the first port is the uplink port or the downlink port according to the level of the first network device, including: the first network device determines that the first port is the uplink port or the downlink port according to the level of the first network device and the level of the second network device.

[0019] In the embodiment of the present application, the first network device determines whether the first port is an uplink port or a downlink port based on the level of the first network device and the level of the second network device, which is conducive to improving the reliability of determining the port attribute of the first port.

[0020] In a possible implementation, the first network device determines, based on the PDU, that the first port is an uplink port or a downlink port, including: the first network device determines, based on the PDU, the level of the second network device; and the first network device determines, based on the level of the second network device, that the first port is an uplink port or a downlink port.

[0021] In the embodiment of the present application, the first network device can directly determine whether the first port is an uplink port or a downlink port based on the level of the second network device, which is conducive to simplifying the process of determining whether the first port is an uplink port or a downlink port.

[0022] In one possible implementation, the second network device is a root node in the network, and the first network device receives a PDU sent by the second network device through a first port, including: the first network device receives the PDU sent by the second network device through the first port, and the level of the second network device carried in the PDU is a preset value; the first network device determines that the first port is an uplink port or a downlink port according to the level of the second network device, including: the first network device determines that the first port is an uplink port according to the preset value.

[0023] In an embodiment of the present application, if the second network device is a root node, the level of the second network device is a preset value. In this way, when the first network device determines through the PDU that the level of the second network device is a preset value, it can directly determine that the second network device is the root node. Accordingly, the first port communicating with the second network device is the uplink port, which is conducive to simplifying the process of determining whether the first port is an uplink port or a downlink port.

[0024] In a possible implementation, the method further includes: the first network device determining the level of the first network device according to the preset value, wherein, in the network, the level represented by the level of the first network device is adjacent to the level where the root node is located.

[0025] In an embodiment of the present application, if the second network device is a root node, the level of the second network device is a preset value. In this way, when the first network device determines through the PDU that the level of the second network device is a preset value, it can be directly determined that the level of the first network device is adjacent to the level of the root node (i.e., the second network device), which is conducive to simplifying the process of determining the level of the first network device in the network.

[0026] In one possible implementation, the first network device determines, based on the PDU, that the first port is an uplink port or a downlink port, including: the first network device determines, based on the PDU, that the second network device is a server, the PDU carries a first TLV, and the first TLV indicates that the second network device is a server; and the first network device determines that the first port is a downlink port.

[0027] In an embodiment of the present application, the first TLV is carried in the PDU to indicate that the second network device is a server. In this way, when the first network device determines that the second network device is a server through the PDU, it can directly determine that the first port communicating with the second network device is the downlink port, which is conducive to simplifying the process of determining the port attributes of the first port.

[0028] Optionally, the first TLV may occupy an optional TLV in the PDU, or occupy a reserved TLV in the PDU.

[0029] Optionally, the PDU is a Link Layer Discovery Protocol LLDP PDU.

[0030] In one possible implementation, the first network device determines that the first port is an uplink port or a downlink port based on the PDU, including: the first network device determines that the second network device is a server based on the subtype of the port ID in the LLDP PDU; and the first network device determines that the first port is a downlink port.

[0031] In an embodiment of the present application, based on the rule that the subtype of the port ID used by the switch is different from the subtype of the port ID used by the server as specified in the LLDP protocol, the second network device can be determined to be a server through the subtype of the port ID carried in the LLDP PDU. In this way, the first port communicating with the second network device is the downlink port, which is conducive to simplifying the process of determining the port attributes of the first port.

[0032] In one possible implementation, the method further includes: the first network device determines the level of the first network device based on the subtype of the port ID in the LLDPPDU, wherein the level represented by the level of the first network device in the network is adjacent to the level where the server is located.

[0033] In an embodiment of the present application, based on the rule that the subtype of the port ID used by the switch is different from the subtype of the port ID used by the server as specified in the LLDP protocol, the second network device can be determined to be a server through the subtype of the port ID carried in the LLDP PDU. In this way, the hierarchy of the first network device in the network is adjacent to the server, which is conducive to simplifying the process of determining the hierarchy of the first network device in the network.

[0034] In one possible implementation, before the first network device receives the protocol data unit PDU sent by the second network device, the method further includes: the first network device sends an LLDP request to the second network device, and the LLDP request is used to request the port attributes of the second port of the second network device, and / or the level of the second network device in the network.

[0035] In an embodiment of the present application, an LLDP request is sent by the first network device to the second network device to trigger the second network device to feed back an LLDP PDU to the first network device, so as to request the port attributes of the second port and / or the level of the second network device in the network by actively requesting, which is conducive to improving the flexibility of the first network device in obtaining the above information.

[0036] In a possible implementation, the first network device sends the LLDP request to the second network device, including: if the port attribute of the first port is unknown, the first network device sends the LLDP request to the second network device.

[0037] In an embodiment of the present application, when the port attributes of the first port are unknown, the first network device sends an LLDP request to the second network device to trigger the second network device to feedback LLDP PDU to the first network device, that is, the first network device sends an LLDP request to the second network device only when the port attributes of a port need to be determined, which is beneficial to reducing the transmission resources occupied by the communication between the first network device and the second network device.

[0038] In a possible implementation, the LLDP PDU includes a second TLV, where the second TLV is used to indicate the level of the second network device, and / or the LLDP PDU includes a third TLV, where the third TLV is used to indicate a port attribute of the second port.

[0039] In an embodiment of the present application, the level of the above-mentioned second network device and / or the port attributes of the second port can be carried in the LLDP PDU in the TLV format, that is, the encapsulation format of the traditional LLDP PDU is reused to carry the above-mentioned information, so as to avoid the need for network devices provided by various manufacturers to be compatible with the new mechanism to support the method for determining the port attributes of the port provided by the present application, which is conducive to reducing the changes made to the network devices provided by various manufacturers to be compatible with the method provided by the present application.

[0040] Optionally, the second TLV or the third TLV may occupy an optional TLV in the LLDP PDU, for example, the system capability TLV, so as to reduce the modification to the encapsulation format of the traditional LLDP PDU.

[0041] Optionally, the second TLV or the third TLV may occupy a reserved TLV in the LLDP PDU to reduce changes to available TLVs in a traditional LLDP PDU.

[0042] In one possible implementation, the first network device includes multiple sending queues, the multiple sending queues include a first sending queue and a second sending queue, the first sending queue is the original sending queue corresponding to the data flow, and the method also includes: the first network device determines that the first port and the third port of the first network device are uplink ports; the first network device generates an anti-priority flow control PFC deadlock rule, the anti-PFC deadlock rule is used to indicate that the data flow is cached to the first sending queue, the ingress port of the first data flow is the first port, and the egress port of the first data flow is the third port.

[0043] In this embodiment of the present application, the first network device can learn that the first port and the third port are uplink ports and generate anti-PFC deadlock rules for the first port and the third port to prevent the first data flow transferred from the first port and dumped from the third port from forming a PFC deadlock with other data flows in the network. This avoids the need for the SDN controller to generate anti-PFC deadlock rules for the first port and the third port and ultimately deploy them to the first network device in traditional anti-PFC deadlock rule deployment methods. This helps reduce the load on the SDN controller in deploying anti-PFC deadlock rules.

[0044] In one possible implementation, the method further includes: the first network device determining, within a preset time period, the number of times the first port and the third port are ports associated with PFC deadlock; and the first network device generating an anti-PFC deadlock rule, including: when the number is higher than a preset threshold, the first network device determining to generate the anti-PFC deadlock rule.

[0045] In the embodiment of the present application, the first network device generates an anti-PFC deadlock rule for the first port and the third port only when the number of occurrences exceeds a preset threshold within a preset time period. This helps reduce the storage space occupied by the first network device for storing the anti-PFC deadlock rule. This avoids the first network device generating the anti-PFC deadlock rule for the first port and the third port regardless of whether a PFC deadlock occurs, which would result in a large amount of storage space occupied by the first network device for storing the anti-PFC deadlock rule.

[0046] In one possible implementation, the method further includes: the first network device receives indication information sent by the second network device through the first port, the indication information is used to indicate that the capacity of the cache corresponding to the third sending queue in the second network device exceeds a threshold, and the inflow flow of the third sending queue is 0, and the priority of the data flow cached by the third sending queue is the same as the priority of the first data flow; the first network device determines the number of times based on the indication information.

[0047] In an embodiment of the present application, when the capacity of the buffer corresponding to the third transmit queue in the second network device exceeds a threshold and the inbound flow of the third transmit queue is 0, the second network device can send an indication to the first network device. Accordingly, the first network device can determine, based on the indication, to deploy an anti-PFC deadlock rule for traffic (i.e., the first data flow) having the same priority as the traffic buffered in the third transmit queue. This helps reduce the possibility of PFC deadlock in the network.

[0048] Optionally, the above indication information may be the priority of the data flow buffered by the third sending queue.

[0049] Optionally, the above-mentioned indication information can be carried in a PDU. Specifically, it can be encapsulated as a TLV in the PDU. It should be noted that the PDU carrying the above-mentioned indication information and the PDU for determining the port attributes of the port mentioned above can be the same PDU or different PDUs, and this application does not limit this.

[0050] In a possible implementation, in the network topology of the network, the levels of network devices increase from north to south.

[0051] In a possible implementation, in the network topology of the network, the levels of network devices decrease from north to south.

[0052] The north-to-south direction can also be understood as the direction from the root node to the top-of-rack switch. Generally, the top-of-rack switch is a type of network device in the network. Usually, the top-of-rack switch is located at a level adjacent to the server in the network.

[0053] The northbound-to-southbound direction is the same as the northbound interface to the southbound interface. The northbound interface is used for vendors or carriers to access and manage their networks, and is the interface provided upward. The southbound interface is used for vendors to manage other vendors' network devices, and is the interface provided downward.

[0054] In a second aspect, a method for determining port attributes is provided, including: a second network device generates a protocol data unit PDU, wherein the PDU is used to determine whether a first port of a first network device is an uplink port or a downlink port; and the second network device sends the PDU to the first network device.

[0055] In this embodiment of the present application, the first network device can determine whether the first port is an uplink port or a downlink port based on the PDU sent by the second network device, providing a basis for subsequently helping the SDN controller reduce the load. This avoids the problem in the prior art where the network device is unable to know the above configuration and is unable to help the SDN controller reduce the load.

[0056] In one possible implementation, the PDU carries the level of the second network device in the network, and / or the PDU carries the port attributes of the second port used by the second network device to send the PDU, and the port attributes of the second port include that the second port is an uplink port or the second port is a downlink port.

[0057] In an embodiment of the present application, by carrying the level of the second network device and at least one information of the port attribute of the second port in the PDU, it is helpful to more intuitively assist the first network device in determining whether the first port is an uplink port or a downlink port.

[0058] In a possible implementation, the second network device is a root node in the network, and the level of the second network device carried in the PDU is a preset value.

[0059] In an embodiment of the present application, if the second network device is a root node, the level of the second network device is a preset value. In this way, when the first network device determines through the PDU that the level of the second network device is a preset value, it can directly determine that the second network device is the root node. Accordingly, the first port communicating with the second network device is the uplink port, which is conducive to simplifying the process of determining whether the first port is an uplink port or a downlink port.

[0060] In a possible implementation, the second network device is a server, the PDU carries a first TLV, and the first TLV indicates that the second network device is a server.

[0061] In an embodiment of the present application, the first TLV is carried in the PDU to indicate that the second network device is a server. In this way, when the first network device determines that the second network device is a server through the PDU, it can directly determine that the first port communicating with the second network device is the downlink port, which is conducive to simplifying the process of determining the port attributes of the first port.

[0062] Optionally, the first TLV may occupy an optional TLV in the PDU, or occupy a reserved TLV in the PDU.

[0063] In a possible implementation, the PDU is a Link Layer Discovery Protocol (LLDP) PDU.

[0064] In one possible implementation, before the second network device sends the PDU to the first network device, the method further includes: the second network device receives an LLDP request sent by the first network device, the LLDP request being used to request port attributes of the second port and / or the level of the second network device.

[0065] In an embodiment of the present application, an LLDP request is sent by the first network device to the second network device to trigger the second network device to feed back an LLDP PDU to the first network device, so as to request the port attributes of the second port and / or the level of the second network device in the network by actively requesting, which is conducive to improving the flexibility of the first network device in obtaining the above information.

[0066] In a possible implementation, the LLDP PDU includes a second TLV, where the second TLV is used to indicate the level of the second network device, and / or the LLDP PDU includes a third TLV, where the third TLV is used to indicate a port attribute of the second port.

[0067] In an embodiment of the present application, the level of the above-mentioned second network device and / or the port attributes of the second port can be carried in the LLDP PDU in the TLV format, that is, the encapsulation format of the traditional LLDP PDU is reused to carry the above-mentioned information, so as to avoid the need for network devices provided by various manufacturers to be compatible with the new mechanism to support the method for determining the port attributes of the port provided by the present application, which is conducive to reducing the changes made to the network devices provided by various manufacturers to be compatible with the method provided by the present application.

[0068] Optionally, the second TLV or the third TLV may occupy an optional TLV in the LLDP PDU, for example, the system capability TLV, so as to reduce the modification to the encapsulation format of the traditional LLDP PDU.

[0069] Optionally, the second TLV or the third TLV may occupy a reserved TLV (or reserved bit) in the LLDP PDU, so as to reduce the modification of available TLVs in the traditional LLDP PDU.

[0070] In one possible implementation, the method also includes: the second network device sends an indication message to the first network device, wherein the indication message is used to indicate that the capacity of the cache corresponding to the third sending queue in the second network device exceeds a threshold, and the inflow flow of the third sending queue is 0, and the priority of the data flow cached by the third sending queue is the same as the priority of the first data flow.

[0071] In an embodiment of the present application, when the capacity of the buffer corresponding to the third transmit queue in the second network device exceeds a threshold and the inbound flow of the third transmit queue is 0, the second network device can send an indication to the first network device. Accordingly, the first network device can determine, based on the indication, to deploy an anti-PFC deadlock rule for traffic (i.e., the first data flow) having the same priority as the traffic buffered in the third transmit queue. This helps reduce the possibility of PFC deadlock in the network.

[0072] Optionally, the above indication information may be the priority of the data flow buffered by the third sending queue.

[0073] Optionally, the above-mentioned indication information can be carried in a PDU. Specifically, it can be encapsulated as a TLV in the PDU. It should be noted that the PDU carrying the above-mentioned indication information and the PDU for determining the port attributes of the port mentioned above can be the same PDU or different PDUs, and this application does not limit this.

[0074] In a third aspect, a first network device is provided, comprising modules for implementing the functions that the first network device needs to perform in the above method.

[0075] In a fourth aspect, a second network device is provided, comprising modules for implementing the functions that the second network device needs to perform in the above method.

[0076] In a fifth aspect, a first network device is provided, comprising a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that the first network device executes the method in the above-mentioned first aspect.

[0077] In a sixth aspect, a second network device is provided, comprising a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that the second network device executes the method in the above-mentioned second aspect.

[0078] In a seventh aspect, a computer program product is provided, comprising: a computer program code, which enables the computer to execute the methods in the above aspects when the computer program code is run on a computer.

[0079] It should be noted that the above-mentioned computer program code can be stored in whole or in part on the first storage medium, wherein the first storage medium can be packaged together with the processor or separately packaged with the processor, and the embodiments of the present application do not specifically limit this.

[0080] In an eighth aspect, a computer-readable medium is provided, wherein the computer-readable medium stores a program code, and when the computer program code is run on a computer, the computer executes the methods in the above aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0081] Figure 1 It is a schematic diagram of the network topology of a fat-tree network applicable to the embodiments of the present application.

[0082] Figure 2 This is a schematic flowchart of a method for determining port attributes according to an embodiment of the present application.

[0083] Figure 3 A schematic diagram showing the encapsulation format of the PDU according to an embodiment of the present application is shown.

[0084] Figure 4 A schematic diagram showing the encapsulation format of LLDP messages in an embodiment of the present application is shown.

[0085] Figure 5 A schematic diagram showing the encapsulation format of the PDU according to an embodiment of the present application is shown.

[0086] Figure 6 A schematic diagram showing the encapsulation format of the PDU according to an embodiment of the present application is shown.

[0087] Figure 7 The encapsulation format of the LLDP request in an embodiment of the present application is shown.

[0088] Figure 8 The method for determining the port attributes of a port based on the LLDP protocol provided in the embodiment of the present application is shown.

[0089] Figure 9 A method for determining port attributes of a port based on the LLDP protocol provided by another embodiment of the present application is shown.

[0090] Figure 10 A schematic diagram showing the network topology of a fat-tree network to which an embodiment of the present application is applicable is shown.

[0091] Figure 11 A flow chart of a method for deploying anti-PFC deadlock rules according to an embodiment of the present application is shown.

[0092] Figure 12 A schematic block diagram of an apparatus for determining port attributes of a port according to an embodiment of the present application is shown.

[0093] Figure 13 A schematic block diagram of an apparatus for determining port attributes according to another embodiment of the present application is shown.

[0094] Figure 14 It is a schematic block diagram of a network device according to another embodiment of the present application. DETAILED DESCRIPTION

[0095] To facilitate understanding, the terms involved in the embodiments of the present application are first introduced.

[0096] 1. Network devices are physical entities connected to a network. Examples include switches, routers, and servers. Network devices may include multiple ports for communicating with other network devices.

[0097] It should be understood that the above-mentioned ports can be ports used when network devices are cascaded, for example, they can be ports used when switches are cascaded, or they can be ports used when switches are cascaded and servers are cascaded.

[0098] Second, port attributes, also known as "port roles," can be used to describe the role of a network device port in the network topology. Specifically, they can include uplinks and downlinks.

[0099] An uplink port is a port used by network devices to send uplink data. Uplink data can be understood as data transmitted in the same direction as from the server to the root node.

[0100] Downlink port refers to the port used by network devices to send downlink data. Downlink data can be understood as data transmitted in the same direction as the root node to the leaf node.

[0101] 3. The level of a network device indicates the layer of the network (or network topology) at which it resides. For example, in a data center network, the shortest number of hops from a network device to the root node can be used as the level of the network device. Alternatively, the shortest number of hops from a network device to a server can be used as the level of the network device.

[0102] It should be noted that the above-mentioned root node is also called a spine node in the spine-leaf network architecture.

[0103] 4. Protocol Data Unit (PDU) refers to the unit of data transferred between peer layers. A PDU at the physical layer can refer to a data bit, a PDU at the data link layer can refer to a data frame, a PDU at the network layer can refer to a data packet, a PDU at the transport layer can refer to a data segment, and PDUs at higher layers can refer to messages.

[0104] The technical solution in this application will be described below with reference to the accompanying drawings.

[0105] For ease of understanding, the following text will first combine Figure 1 The fat tree network to which the embodiments of the present application are applicable is introduced. It should be understood that Figure 1 The network shown is only one possible network architecture applicable to the embodiments of the present application. The embodiments of the present application can also be applied to other network forms of data center networks, such as the traditional three-layer network architecture of a data center.

[0106] Figure 1 It is a schematic diagram of the network topology of a fat-tree network applicable to the embodiments of the present application. Figure 1 The fat tree network shown includes multiple root nodes 110, multiple leaf nodes 120, multiple servers 130 and an SDN controller 140. It should be noted that, Figure 1 Only some nodes in the CLOS are shown, for example, some leaf nodes among the multiple leaf nodes, namely leaf node 1, leaf node 2, and leaf node 3. Some root nodes among the multiple root nodes, namely root node 1 and root node 2. The embodiments of the present application do not limit the specific number of network devices in the fat tree network.

[0107] In this fat-tree network architecture, network devices belonging to the same layer cannot communicate directly, and each root node is connected to all leaf nodes in a fully connected manner.

[0108] The server 130 is used to process data and provide storage services.

[0109] The leaf node 120 is used to read data from the server or write data to the server.

[0110] The root node 110 is used to help the leaf nodes in the same layer forward data flows. For example, the root node 1 can forward the data flow of the leaf node 1 to the leaf node 2.

[0111] Typically, the leaf node or root node is a switch or other network device with a data forwarding function.

[0112] The SDN controller 140 is used to manage network devices (eg, switches) in the data center network.

[0113] As data center networks continue to expand, SDN controllers are required to manage an increasing number of network devices, placing an increasing load on SDN controllers. The processing speed of SDN controllers can impact data center performance. To reduce the load on SDN controllers, it is desirable to transfer functions previously implemented by SDN controllers to network devices for autonomous implementation. For example, SDN controllers can be freed from the function of generating anti-priority flow control (PFC) deadlock rules, allowing network devices to autonomously generate these rules. However, when network devices implement certain functions (for example, generating anti-PFC deadlock rules), they need to know whether each port is an uplink or downlink port.

[0114] Therefore, the embodiment of the present application provides a method for determining port attributes so that the network device can know the port attributes of its own port, providing a basis for subsequently helping the SDN controller to reduce the load. Figure 2 A method for determining port attributes according to an embodiment of the present application is introduced.

[0115] Figure 2 This is a schematic flowchart of a method for determining port attributes according to an embodiment of the present application. Figure 2 The method shown includes steps 200 to 220. It should be noted that the first network device and the second network device in the following text may be Figure 2 Any two network devices in the network architecture shown.

[0116] 200. The second network device generates a PDU.

[0117] The above-mentioned PDU may be used by the first network device to determine the port attribute of the first port of the first network device.

[0118] 210. The second network device sends a PDU to the first network device through the second port. Correspondingly, the first network device receives the PDU through the first port.

[0119] The first port may be any one of multiple ports of the first network device.

[0120] The second port may be any one of multiple ports of the second network device.

[0121] 220. The first network device determines, according to the PDU, whether the first port is an uplink port or a downlink port.

[0122] Optionally, the above PDU may carry the level of the second network device in the network, or the PDU may carry the port attribute of the second port, wherein the second port is the port used by the second network device to send the PDU. Alternatively, the above

[0123] The PDU may carry the level number of the second network device and the port attribute of the second port. The PDU may also carry a first TLV, which is used to indicate whether the second network device is a server or a switch.

[0124] Based on the information carried in the PDU, the first network device can determine the port attribute of the first port, that is, determine whether the first port is an uplink port or a downlink port. The following describes a method for determining the port attribute of the first port based on the information carried in the PDU.

[0125] For ease of understanding, before introducing the method for determining port attributes, the method for determining the level of the first network device provided in the embodiment of the present application is first introduced. It should be noted that the method for determining the level of the first network device described below can be used alone to determine the level of the first network device; it can also be combined with the method for determining port attributes to assist the first network device in determining the port attributes of the first port. The embodiment of the present application does not limit this.

[0126] There are many ways for the first network device to determine the level of the first network device based on the PDU. Based on the different information carried in the PDU, they can be mainly divided into the following five ways. Of course, in addition to being combined with the method for determining port data, the following five ways of determining the level can also be used independently, and this application does not limit this.

[0127] Method 1 for determining the level: if the PDU carries the level of the second network device, the first network device can determine the level of the first network device according to the level of the second network device.

[0128] For example, Figure 1 Taking the network architecture shown as an example, the levels of network devices at different levels increase from the root node to the server, with the first network device being leaf node 1 and the second network device being the root node. Network devices in the preconfigured network send PDUs layer by layer, starting from the root node and ending at the server. Specifically, the root node first sends a PDU through all ports, and this PDU carries the root node's level 0. Upon receiving the PDU, leaf node 1 adds 1 to level 0, setting its level 1 as leaf node 1.

[0129] For example, Figure 1Taking the network architecture shown as an example, the levels of network devices at different levels decrease from the root node to the server, and the first network device is leaf node 1, and the second network device is the root node. The network devices in the preconfigured network send PDUs layer by layer in the direction from the root node to the server. That is, the root node first sends the PDU through all ports (i.e., the downlink port), and carries the root node's level max in the PDU. After receiving the PDU, the leaf node 1 can subtract 1 from the level max as the basis, as the leaf node 1's level max-1.

[0130] It should be noted that the above-mentioned max can be the maximum level of the network architecture in the network, or can be any preset value greater than the maximum level.

[0131] The second method for determining the level is that if the PDU carries the level of the network device sending the PDU, the first network device can determine the level of the first network device based on the PDUs sent by multiple network devices, and the multiple network devices can include the second network device mentioned above.

[0132] That is, the first network device receives multiple PDUs sent by multiple network devices through the first port, and the first network device determines the levels of the multiple network devices in the network based on the multiple PDUs; the first network device selects a target level from the levels of the multiple network devices; the first network device determines the level of the first network device based on the target level and preset rules.

[0133] The preset rule may include, if the target level is the maximum level among the levels of the plurality of network devices, reducing the target level to obtain the level of the first network device. Alternatively, the preset rule may also include, if the target level is the minimum level among the levels of the plurality of network devices, increasing the target level to obtain the level of the first network device. Of course, other rules may also be configured to determine the level of the first network device, and this embodiment of the present application is not limited thereto.

[0134] The aforementioned increasing or decreasing the target level may refer to increasing or decreasing the target level based on a preset change amount, for example, the preset change amount may be 1 or other values.

[0135] It should be noted that in the above method, the steps of selecting a target level and determining the level of the first network device can also be replaced by the first network device first adjusting the levels of multiple network devices based on a preset rule to obtain multiple adjusted levels, and then selecting the target level from the multiple adjusted levels. For example, the first network device first adds 1 to the levels of multiple network devices to obtain multiple adjusted levels, and then selects the smallest level from the multiple adjusted levels as the target level.

[0136] Optionally, the above-mentioned multiple network devices are network devices directly connected to the first network device, that is, the layers where the multiple network devices are located in the network are adjacent to the layer where the first network device is located.

[0137] It should be noted that the layer where the above-mentioned multiple network devices are located can be one layer or multiple layers. When the layer where the multiple network devices are located can be one layer, that is, the multiple network devices are located at the same layer, and the layer is adjacent to the layer of the first network device. When the layer where the multiple network devices are located can be multiple layers, at least two of the multiple network devices are located at different layers, and the multiple layers are adjacent to the layer of the first network device. The multiple layers can include a layer in the network that is located to the north of the layer where the first network device is located, and a layer to the south of the layer where the first network device is located. For example, the first network device is Figure 1 When the leaf node 1 is located in the network, multiple network devices may include the root node 1, that is, the root node 1 is located in the layer north of the layer where the first network device is located in the network, and the multiple network devices may include the server a, that is, the server a is located in the layer south of the layer where the first network device is located in the network.

[0138] The following text Figure 1 Taking the network architecture shown as an example, the method for determining the level of network devices in an embodiment of the present application is introduced. Assume that the levels of network devices at different levels increase from the root node to the server. The level of the root node is configured to 0 by pre-configuration, and the initial value of the level of the leaf node is max. And the above-mentioned preset change amount is 1. Each network device periodically sends a PDU through all ports with a period of T. The PDU carries the level of the network device sending the PDU.

[0139] Because the total number of network layers is usually unknown, the initial value max can be the maximum value that can be represented by the bits in the PDU that represent the network device level. For example, if the PDU uses 2 bits to represent the network device level, the initial value max can be configured as 4. This means that 2 bits can represent a maximum of 4 network layers. If more network layers need to be represented, the number of bits representing the network device level can be increased.

[0140] For each root node in the network, it actively sends out PDUs from all ports at a period T. The PDUs carry the level 0 of the root node.

[0141] It should be noted that since each network device needs to send PDUs through all ports, the root node will also receive PDUs sent by other nodes. In this case, the root node can be configured to discard PDUs.

[0142] For any leaf node in the network (e.g., leaf node 3), during cycle 1, it receives PDUs from multiple leaf nodes through multiple ports. Each PDU carries the level number of the leaf node that sent it. Because the initial value of the level number of leaf nodes in the network is max, the levels of the multiple leaf nodes received by leaf node 3 may include the initial value max.

[0143] In this way, leaf node 3 can select the smallest level from the received leaf node levels as the target level, and then increment the target level by 1 to set this as the level of leaf node 3 in cycle 1. In the next cycle 2, leaf node 3 encapsulates the level determined in cycle 1 in a PDU and sends it to other leaf nodes. After a preset number of cycles, each leaf node in the network can determine its own level in the network through this method.

[0144] Optionally, the aforementioned multiple network devices may be network devices that are not adjacent to the first network device. For example, multiple network devices may be root nodes, and the hierarchy of the first network device is separated from the hierarchy of the multiple network devices by one or more layers. In this case, the multiple network devices may send the root node hierarchy number to the first network device via multiple PDUs. Each of the multiple PDUs may record the number of network devices passed when transmitting the corresponding PDU to the first network device, i.e., the number of hops required to transmit the PDU to the first network device. The first network device may determine the hierarchy number of the first network device based on the PDU and the hop count.

[0145] A third method for determining the level is that if the level of the network device that sends the PDU and is carried in the PDU is a preset value, the first network device directly determines its own level according to the preset value.

[0146] For a root node, the root node's level is typically configured to a preset value, such as 0 as described above. In this case, if the PDU carries the preset value for the level of the network device that sent the PDU, the first network device can determine that its own level is adjacent to the root node's level, and the level of the first network device is adjusted by a preset amount based on the preset value. It should be noted that the description of the preset amount can be found in the second method for determining the level above.

[0147] Of course, the level of servers in the network can also be set to a preset value, so that the first network device can determine that its own level is adjacent to the level of the server, and the level of the first network device is based on the preset value and adjusts the preset change amount.

[0148] Method 4 for determining the level: if the above PDU is a Link Layer Discovery Protocol

[0149] If a LLDP (License Link Protocol) PDU is received, the first network device determines the level of the first network device according to the subtype of the port ID in the LLDP PDU.

[0150] Typically, the link layer discovery protocol stipulates that switches follow IETF RFC 2863 and use the interface name as the subtype of the port ID. In this case, the subtype of the port ID carried in the PDU is 5. Servers follow IEEE Std 802 and use the media access control address as the subtype of the port ID. In this case, the subtype of the port ID carried in the PDU is 3.

[0151] In this way, when the first network device receives the LLDP PDU, if the subtype of the port ID carried in the PDU is 3, the first network device can determine that its own level is adjacent to the level of the server, and can record its own level as a preset value, for example, 0.

[0152] Method five for determining the level: if the PDU carries a first TLV, and the first TLV indicates that the network device sending the PDU (i.e., the second network device) is a server, the first network device can determine that its own level is adjacent to the level of the server, and can record its own level as a preset value, for example, 0.

[0153] It should be noted that Methods 3 through 5 for determining the level are typically used to determine the level of a specific node in a network, such as a root node or a node located in a layer adjacent to the server. The level of network devices in other layers of the network can be determined using other methods, such as those described in Method 2.

[0154] The following describes five methods for determining port attributes provided by embodiments of the present application. Regarding the methods for determining the level of the first network device and / or the level of the second network device described in Method 1, Method 2, and Method 3, respectively, the above descriptions can be found. Of course, the level of the first network device and / or the level of the second network device may also be indicated to the first and second network devices by the SDN controller, which is not limited in the present embodiment.

[0155] In a first manner of determining the port attribute, the first network device determines the level of the first network device, and determines the port attribute of the first port based on the level of the first network device.

[0156] The first network device can determine the port attributes of the first port based only on the level of the first network device. For example, after determining that the first network device is the root node, it can directly determine that the port attributes of all ports are downlink ports. For another example, after determining that the level at which the first network device is located is adjacent to the level at which the server is located, it can directly determine that the downlink port of the first port that receives the PDU sent by the server. Of course, the first network device can also determine the port attributes of the first port in combination with the level of the first network device and other information. The specific determination method is specifically introduced in the second method for determining the port attributes of a port.

[0157] Method 2 for determining port attributes of a port: The first network device determines the port attributes of the first port based on the level of the first network device and the level of the second network device. Determining the level of the first network device can refer to Methods 1 to 6 for determining the level of the first network device, and for the sake of brevity, they are not further described here. The level of the second network device can be carried in the PDU.

[0158] When the levels of network devices at different levels increase from the root node to the server, if the level of the first network device is smaller than the level of the second network device, the first network device may determine the first port as a downlink port. If the level of the first network device is larger than the level of the second network device, the first network device may determine the first port as an uplink port.

[0159] When the levels of network devices at different levels decrease from the root node to the server, if the level of the first network device is greater than the level of the second network device, the first network device may determine the first port as an uplink port. If the level of the first network device is less than the level of the second network device, the first network device may determine the first port as a downlink port.

[0160] Method three for determining the port attribute of a port: the first network device determines the port attribute of the first port according to the level of the second network device.

[0161] It should be understood that the above-mentioned determination of the port attributes of the first port by the first network device based on the level of the second network device may include the first network device determining the port attributes of the first port based solely on the level of the second network device, or the first network device determining the port attributes of the first port based on the level of the second network device and other information. For example, the port attributes of the first port may be determined based on the level of the second network device and the level of the first network device. The specific determination method can be referred to the description of Method 2 for Determining the Port Attributes of a Port, and this embodiment of the present application is not limited to this.

[0162] For example, based on the above introduction, if the second network device is a root node or a server, the level of the second network device can be configured as a preset value. Then, when the first network device determines that the second network device is the preset value, the second network device can directly determine the first port as the uplink port.

[0163] Method 4 for determining the port attribute of a port: The first network device determines the port attribute of the first port according to the first TLV.

[0164] Based on the above description, if the second network device is a server, the first TLV can be carried in the PDU, and the first TLV indicates that the second network device is a server. In this way, after the first network device receives the PDU through the first port, it can directly determine the first port as the downlink port.

[0165] Method 5 for determining the port attribute of a port: The first network device may determine the port attribute of the first port according to the subtype of the port ID in the PDU.

[0166] As mentioned above, the link layer discovery protocol stipulates that switches follow IETF RFC 2863 and use the interface name as the subtype of the port ID. In this case, the subtype of the port ID carried in the PDU is 5. Servers follow IEEE Std 802 and use the media access control address as the subtype of the port ID. In this case, the subtype of the port ID carried in the PDU is 3.

[0167] In this way, when the PDU received by the first network device is an LLDP PDU, if the subtype of the port ID carried in the PDU is 3, the first network device can determine that the first port is a downlink port.

[0168] In the methods described above for determining port attributes and determining the level of a network device, multiple network devices in the network (e.g., the second network device) can periodically and autonomously send PDUs to facilitate the determination of port attributes or levels by other network devices in the network (e.g., the first network device). Of course, the first network device can also utilize a request-response mechanism to obtain PDUs from the second network device. This request-response mechanism can be applied to a variety of protocols; the following description will only use the LLDP protocol as an example.

[0169] Optionally, the PDU is an LLDP PDU. Before step 210, the method further includes: the first network device sending an LLDP request to the second network device, wherein the LLDP request is used to request port attributes of a second port of the second network device and / or the level of the second network device in the network. Accordingly, the second network device may reply to the LLDP PDU to the first network device, i.e., respond to the LLDP request.

[0170] Of course, the first network device can periodically send the LLDP request to the second network device. However, to reduce the number of communications between the first and second network devices and reduce the transmission resources occupied by sending LLDP requests, the first network device can also send LLDP requests to the second network device on demand. That is, if the port attributes of the first port are unknown, the first network device sends the LLDP request to the second network device.

[0171] As mentioned above, the port attributes and / or the level of the network device can be carried in the PDU. It should be noted that there are many standardized protocols for PDU, which makes the encapsulation format in different standards different. Figures 3 to 6 , mainly introduces several possible encapsulation formats in the slow protocol and LLDP protocol. It should be noted that, Figures 3 to 6 The encapsulation format shown may also include other fields already specified in the communication protocol, or other fields specified in future communication protocols, which is not limited in the embodiments of the present application.

[0172] Combined with the following Figure 3 and Figure 4 Introduce the PDU format or message format that carries the level of network equipment. Figure 5 and Figure 6 This section describes the PDU format or message format that carries the network device level and port attributes.

[0173] Figure 3 A schematic diagram showing the encapsulation format of the PDU according to an embodiment of the present application is shown. Figure 3 The PDU shown includes: destination address (DA) 310, source address (SA) 320, type (Type) 330, subtype (Subtype) 340, flag (Flag) field 350, code (Code) 360, data (Data) field 370, frame check sequence (FCS) 380.

[0174] DA 310 indicates the destination MAC address of the PDU. Typically, it is the multicast MAC address 0180c2000002.

[0175] SA 320 indicates the source MAC address of the PDU, typically a unicast MAC address.

[0176] Type 330 indicates the protocol type of the PDU, usually 0x8809.

[0177] Subtype 340 indicates the protocol subtype of the PDU, usually 0x03.

[0178] Flags field 350: contains status information of network devices in the network.

[0179] Code 360 ​​indicates the type of PDU. For example, if the value of this field is 0x00, it means that the PDU is a message (Information) PDU; if the value of this field is 0x01, it means that the PDU is an event notification (Event

[0180] Notification) PDU; the value of this field is 0x04, indicating that the PDU is a loop control (LoopbackControl) PDU.

[0181] The data field 370 is used to carry the payload of the OAM PDU.

[0182] FCS 380 is the tail field of the PDU, commonly known as the "frame tail." It is used to verify the integrity of the PDU during transmission. It is usually a 4-byte cyclic redundancy check code.

[0183] In the embodiment of the present application, the TLV indicating the level of the network device (also called the "second TLV") can be carried in Figure 3 Any fields preceding the FCS 380 in the PDU shown. For example, Figure 3 As shown, the second TLV 390 may occupy the field before the FCS 380 and be adjacent to the FCS 380 .

[0184] It should be noted that the above Figure 3 The encapsulation format of the PDU shown may also carry only the port attributes of the port (ie, the third TLV), that is, the "second TLV" in the above text is replaced with the "third TLV". For the sake of brevity, it will not be repeated here.

[0185] Figure 4 A schematic diagram showing the encapsulation format of LLDP messages in an embodiment of the present application is shown. Figure 4The encapsulation format of the LLDP message shown includes: DA 410, SA 420, type (Type) 430, LLDP PDU 440, and FCS 440.

[0186] DA 410 is used to represent the Media Access Control (MAC) address of the receiving end of the LLDP message, and can usually be set to a multicast MAC address, for example, 0x0180-C200-000E.

[0187] SA 420 is used to indicate the MAC address of the sender of the LLDP message.

[0188] Type 430 is used to indicate the type of LLDP message. Usually in LLDP message, the value of this field is

[0189] 0x88CC.

[0190] LLDP PDU 440 is used to carry information or data, and can be understood as the main body of information exchange in LLDP messages. Generally, LLDP PDU uses the type-length-value (TLV) format to encapsulate data or information. Specifically, it may include: Chassis ID TLV 441, Port ID TLV

[0191] 442, Time to Live (TTL) TLV 443, and End of LLDP PDU TLV 444. Chassis ID TLV 441 indicates the chassis MAC address of the sender. Port ID TLV 442 indicates the port that sent the PDU. TTL TLV 443 limits the lifetime of a PDU in the network to prevent PDU loops. End of LLDP PDU 444 indicates the end of the LLDP PDU.

[0192] To improve the scalability of the protocol, the LLDP PDU 440 also reserves multiple reserved TLVs 449, for example, reserved TLV#1 to reserved TLV#n, where n is a positive integer. Generally, the TLV types corresponding to the reserved TLVs are 9 to 126. In an embodiment of the present application, the TLV representing the level of the network device (i.e., the "second TLV") can be carried in any one of the above-mentioned multiple reserved TLVs, for example, it can occupy reserved TLV#1 445. Specifically, the second TLV can include a second TLV type 446, a second TLV length (TLV length) 447, and a second TLV value (value) 448. Among them, the second TLV type 446 can be the TLV type corresponding to the reserved TLV#1, that is, 9. The second TLV length 447 is used to indicate the length of the data carried in the value of the second TLV. The second TLV value 448 represents the actual numerical value, that is, the level of the network device.

[0193] FCS 440, the tail field of the LLDP message, commonly known as the "frame trailer," is used to verify the integrity of the LLDP message during transmission. It is typically a 4-byte cyclic redundancy check code.

[0194] Optionally, only some of the TLVs included in the LLDP PDU 440 are listed above. Currently, LLDP stipulates that the TLVs in the LLDP PDU can be divided into two types, namely mandatory TLVs and optional TLVs. Among them, the mandatory TLVs mainly include the chassis ID TLV 441, the port ID TLV 442, and the time to live (TTL) TLV 443. The optional TLVs mainly include the port description (port description)

[0195] TLV, system name TLV, system description TLV, system capabilities TLV, etc. In order to reduce the changes to the reserved TLVs in the LLDP PDU, the embodiment of the present application also provides a method of carrying the level of the network device TLV (i.e., the second TLV), that is, configuring the second TLV to occupy the field corresponding to any of the above optional TLVs.

[0196] It should be noted that the above Figure 4 The encapsulation format of the LLDP message shown may also carry only the port attributes of the port (ie, the third TLV), that is, the "second TLV" in the above text is replaced with the "third TLV", which is not described here for brevity.

[0197] Figure 5 A schematic diagram showing the encapsulation format of the PDU of an embodiment of the present application is shown. It should be noted that, Figure 5 The PDU encapsulation format shown is the same as Figure 3 In the encapsulation format of the PDU shown, fields with the same meaning use the same number. For their specific meanings, please refer to the above introduction. For the sake of brevity, they will not be repeated here.

[0198] Figure 5 The PDU shown includes: Destination Address (DA) 310, Source Address (SA) 320, Type (Type) 330, Subtype (Subtype) 330, Flag (Flag) field 350, Code (Code) 360, Data (Data) 370, Frame Check Sequence (FCS) 380. In the embodiment of the present application, the TLV indicating the level of the network device (also called the "second TLV") and the TLV indicating the port attribute of the port (also called the "third TLV") can be carried in Figure 5 Any fields preceding the FCS 380 in the PDU shown. For example, Figure 5 As shown, the second TLV 510 and the third TLV 520 may occupy the field before the FCS 380 and be adjacent to the FCS 380 .

[0199] It should be noted that the positions of the second TLV 510 and the third TLV 520 can be swapped, that is, the third TLV can be located in the field before the second TLV. The second TLV and the third TLV can be adjacent or non-adjacent. This embodiment of the application does not limit this.

[0200] Figure 6 A schematic diagram showing the encapsulation format of the PDU of an embodiment of the present application is shown. It should be noted that, Figure 6 The PDU encapsulation format shown is the same as Figure 4 In the encapsulation format of the PDU shown, fields with the same meaning use the same number. For their specific meanings, please refer to the above introduction. For the sake of brevity, they will not be repeated here.

[0201] Figure 6 The encapsulation format of the LLDP message shown includes: DA 410, SA 420, Type 430,

[0202] LLDP PDU 440, FCS 440. The LLDP PDU 440 reserves multiple reserved TLVs (reservedTLVs) 449, for example, reservedTLV#1 to reservedTLV#n, where n is a positive integer. Typically, reservedTLVs correspond to TLV types 9 to 126.

[0203] In an embodiment of the present application, a TLV indicating the level of a network device (i.e., a "second TLV") can be carried in any one of the above-mentioned multiple reserved TLVs, for example, it can occupy reserved TLV#1 445. Specifically, the second TLV may include a second TLV type 446, a second TLV length (TLV length) 447, and a second TLV value (value) 448. Among them, the second TLV type 446 can be the TLV type corresponding to the reserved TLV#1, that is, 9. The second TLV length 447 is used to indicate the length of the data carried in the value of the second TLV. The second TLV value 448 represents the actual numerical value, that is, the level of the network device.

[0204] The TLV representing the port attributes of a port (i.e., the "third TLV") can be carried in any of the multiple reserved TLVs described above. For example, it can occupy reserved TLV #2 610. Specifically, the third TLV can include a TLV type 611, a TLV length 612, and a TLV value 613. The third TLV type 612 can be the TLV type corresponding to reserved TLV #2, i.e., 10. The third TLV length 612 indicates the length of the data carried in the third TLV value. The third TLV value 613 represents the actual value, i.e., the port attributes of the port.

[0205] Optionally, only some of the TLVs included in the LLDP PDU 440 are listed above. Currently, LLDP stipulates that the TLVs in the LLDP PDU can be divided into two types, namely mandatory TLVs and optional TLVs. Among them, the mandatory TLVs mainly include chassis ID TLV 441, port ID TLV 442, time to live (TTL) TLV 443, etc. The optional TLVs mainly include port description TLV, system name TLV, system description TLV, system capabilities TLV, etc. In order to reduce the changes to the reserved TLVs in the LLDP PDU, the embodiment of the present application also provides a method of carrying a second TLV and a third TLV, that is, configuring the second TLV and the third TLV to occupy the fields corresponding to any two of the above optional TLVs.

[0206] Combined with the following Figure 7 The encapsulation format of the LLDP request in the embodiment of the present application is introduced. Figure 7 The LLDP request shown includes: DA 710 , SA 720 , Type 730 , LLDP PDU 740 , and FCS 770 .

[0207] DA 710 is used to represent the Media Access Control (MAC) address of the receiving end of the LLDP request, and can usually be set to a multicast MAC address, for example, 0x0180-C200-000E.

[0208] SA 720 is used to indicate the MAC address of the sender that sends the LLDP request.

[0209] Type 730 is used to indicate the type of LLDP request.

[0210] LLDP PDU 740 is used to carry information or data, etc., and can be understood as the main body of LLDP information exchange. Generally, LLDP PDU uses the type-length-value (TLV) format to encapsulate data or information. Specifically, it may include: chassis ID TLV 741, port ID TLV 742, time to live (TTL) TLV 743 and end of LLDP PDU TLV 744. Among them, chassis ID TLV 741 is used to indicate the chassis MAC address of the sender. Port ID TLV 742 is used to indicate the port of the sender of the LLDP request. TTL TLV 743 is used to limit the time that the LLDP request exists in the network to prevent LLDP request loops. End of LLDP PDU 744 is used to mark the end of the LLDP PDU.

[0211] To improve the scalability of the protocol, the LLDP PDU 740 also reserves multiple reserved TLVs 749, for example, reserved TLV#1 to reserved TLV#n, where n is a positive integer. Typically, the TLV types corresponding to reserved TLVs range from 9 to 126. In embodiments of the present application, a TLV for requesting the level of a network device and / or a TLV for requesting port attributes of a port (collectively referred to as "request TLVs") can be carried in any of the multiple reserved TLVs.

[0212] For example, the request TLV may only occupy reserved TLV #1 745. Specifically, the request TLV may include a request TLV type 746, a request TLV length 747, and a request TLV value 748. The request TLV type 746 may be the TLV type corresponding to reserved TLV #1, i.e., 9. The request TLV length 747 indicates the length of the data carried in the request TLV value. The request TLV value 748 represents the actual value, i.e., the level of the network device and / or the port attributes of the port.

[0213] FCS 740, the tail field of an LLDP message, commonly known as the "frame trailer," is used to verify the integrity of the LLDP message during transmission. It is typically a 4-byte cyclic redundancy check code.

[0214] Optionally, only some of the TLVs included in the LLDP PDU 740 are listed above. Currently, LLDP stipulates that the TLVs in the LLDP PDU can be divided into two types, namely mandatory TLVs and optional TLVs. Among them, the mandatory TLVs mainly include chassis ID (Chassis ID TLV) 741, port ID TLV (Port ID TLV) 742, time to live (TTL) TLV 743, etc. The optional TLVs mainly include port description TLV, system name TLV, system description TLV, system capabilities TLV, etc. In order to reduce the changes to the reserved TLVs in the LLDP PDU, the embodiment of the present application also provides a method of carrying a request TLV, that is, configuring the request TLV to occupy the field corresponding to any of the above optional TLVs.

[0215] It should be noted that the encapsulation format of the LLDP request in the above text corresponds to the encapsulation format of the LLDP message. For example, when the above LLDP request is used to request the level of a network device, the LLDP message can be encapsulated in the form of Figure 4 When the above LLDP request is used to request the level of the network device and the port type of the port, the LLDP message can be used Figure 5 The packaging format shown.

[0216] The following text Figure 1 The network architecture shown is used as an example to introduce the method for determining the port attributes of a port in an embodiment of the present application in combination with specific examples. It should be noted that the specific examples below are only for facilitating the understanding of the present application and do not limit the scope of the present application.

[0217] Figure 7 This is a schematic flowchart of a method for determining port attributes of a port according to an embodiment of the present application. Figure 7 The method shown includes steps 710 to 750. Assume that the levels of network devices at different levels increase in steps of 1 from the root node to the server. The level of the root node is configured to be 0, the initial value of the level of the leaf node is max, and the initial port attribute of the port of each node (including the root node and the leaf node) in the preconfigured network is a downlink port. Each network device periodically sends a PDU through all downlink ports with a period of T. The PDU carries the level of the network device sending the PDU.

[0218] Because the total number of network layers is usually unknown, the initial value max can be the maximum value that can be represented by the bits in the PDU that represent the network device level. For example, if the PDU uses 2 bits to represent the network device level, the initial value max can be configured as 4. This means that 2 bits can represent a maximum of 4 network layers. If more network layers need to be represented, the number of bits representing the network device level can be increased.

[0219] For each root node in the network, it actively sends PDUs from all ports at a period of T. The PDUs carry the root node's level 0. It should be noted that for the root node, all ports are downlink ports.

[0220] It should also be understood that since each network device (including root nodes and leaf nodes) needs to send PDUs through all ports, the root node will also receive PDUs sent by leaf nodes. At this time, the root node can be configured to discard PDUs sent by other nodes.

[0221] Each leaf node in the network is configured with a variable called switch_level, which stores the node's level and has an initial value of max. Each leaf node also has a variable called port_level, which stores the node's level, determined based on the level of the network device carried in the PDU received from the port. This variable also has an initial value of max.

[0222] The following describes the method for determining the port attributes of a port using leaf node 3 as an example. The method for determining the port attributes of other leaf nodes in the network is similar and is omitted for brevity. Assuming that leaf node 3 has three ports, represented by P1, P2, and P3, the variable corresponding to P1 is port_level1, the variable corresponding to P2 is port_level2, and the variable corresponding to P1 is port_level3.

[0223] 710. In cycle 1, leaf node 3 receives PDU1, PDU2 and PDU3 through P1, P2 and P3 respectively, where the level of network devices carried in PDU1 is X1, the level of network devices carried in PDU2 is X2, and the level of network devices carried in PDU3 is X3.

[0224] 720, leaf node 3 saves X1 in port_level1, X2 in port_level2, and X3 in port_level3.

[0225] It should be noted that if the above-mentioned cycle 1 is the initial cycle for determining the port attributes of the port, and the initial value of the level of the leaf node is max, then the value of the level of the leaf node in the above X1, X2, and X3 is max, and the value of the level of the leaf node is 0.

[0226] 730, leaf node 3 selects the minimum value X from X1, X2, and X3 min , and X min +1 is stored in the variable switch_level.

[0227] It should be noted that if X1, X2, and X3 are equal, then X min Equal to any value among X1, X2, and X3.

[0228] 740, leaf node 3 according to X i and X min +1, determine the port attributes of P1, P2, and P3, where i = 1, 2, 3.

[0229] Specifically, if i <X min +1, then you can determine X i The corresponding leaf node 3 port is the uplink port; if X i >X min +1, then you can determine X i The corresponding port of leaf node 3 is the downlink port.

[0230] 750, in cycle 2, X min +1 is encapsulated in the PDU as the level of leaf node 3 and sent through all downlink ports carrying X min +1 for the PDU.

[0231] It should be noted that the above cycle 2 is the next cycle of cycle 1. Leaf node 3 will still receive PDUs sent by other nodes through the downlink port in cycle 2. Leaf node 3 can re-execute steps 710 to 750 to determine the port attributes of each port.

[0232] After a plurality of preset cycles, the port attributes of the ports of each leaf node in the network tend to be stable, and the sending of PDUs can be stopped. At this time, the port attributes of the ports determined by each leaf node are relatively accurate.

[0233] The following text Figure 1 Taking the network architecture shown as an example, combined with specific examples, the method for determining the port attributes of a port based on the LLDP protocol provided in an embodiment of the present application is introduced. Figure 8The illustrated method includes steps 810 to 830. Assume that the levels of nodes at different levels decrease in steps of 1 from the root node toward the server, and that if a network device is adjacent to a server, its level is predetermined to be 1. The following example uses leaf node 3 sending an LLDP request as an example. Assume that the port attributes of port P1 on leaf node 3 are unknown.

[0234] 810 , the leaf node 3 sends an LLDP request to the adjacent node through the port P1 to request the level and port attributes of the adjacent node.

[0235] When the adjacent node is a leaf node, the leaf node 2 receives the first LLDP request through the port Q1. The first LLDP request is used to request the level of the leaf node 2 and the port attribute of the second port.

[0236] If the level of leaf node 2 and the port attributes of port Q1 are known, leaf node 2 sends a first LLDP message to leaf node 3 through port Q1. The first LLDP message carries the level of leaf node 2 and the port attributes of port Q1. If the level of leaf node 2 and the port attributes of port Q1 are unknown, leaf node 2 is configured to ignore the first LLDP request.

[0237] When the neighboring node is a server, leaf node 3 sends a second LLDP request to server 1 via P2, requesting the level of server 1 and the port attributes of the port of server 1. Accordingly, the server feeds back a second LLDP message to leaf node 2.

[0238] 820 , the leaf node 3 receives the first LLDP message or the second LLDP message through the port P1 .

[0239] 830 , the leaf node 3 determines the level of the leaf node 3 and the port attribute of the port that sends the LLDP message according to the received LLDP message.

[0240] The above-mentioned LLDP message is the first LLDP message. If leaf node 3 obtains from the first LLDP message that the level of leaf node 2 is M, and the port attribute of port Q1 is a downlink port, then leaf node 3 can determine that the level of leaf node 3 is M+1, and port P1 is an uplink port, where M is a positive integer.

[0241] If leaf node 3 obtains from the first LLDP message that the level of leaf node 2 is Z, and the port attribute of port Q1 is an uplink port, then leaf node 3 can determine that the level of leaf node 3 is Z-1, and port P1 is a downlink port, where Z is a positive integer greater than or equal to 1.

[0242] When the LLDP message is the second LLDP message, leaf node 3 can determine that the adjacent node is a server according to the subtype of the port ID in the second LLDP message. At this time, leaf node 3 can determine that port P1 is a downlink port, and the level of leaf node 3 is 1.

[0243] It should be noted that, as mentioned above, the LLDP protocol stipulates that the subtype of the port ID applicable to servers is generally a MAC address. That is, the subtype value of the port ID carried in the second LLDP message is 5. This is different from the subtype of the port ID used by switches. Therefore, leaf node 3 can directly determine that the sender of the second LLDP message is a server based on the subtype of the port ID in the second LLDP message.

[0244] It should also be understood that when the adjacent node is a server, since leaf node 3 can directly determine the level of leaf node 3 and the port attributes of port P1 based on the subtype of the port ID, the second LLDP message does not need to carry the server's level 0 and the port attributes of the port used by the server to send the second LLDP message. Of course, to improve the accuracy of leaf node 3's determination of the level and port attributes of the port, the second LLDP message may also carry the server's level and the port attributes of the port used to send the second LLDP message.

[0245] It should be noted that before the process described in steps 810 to 830 above, leaf node 3 may obtain multiple levels of leaf node 3. For example, before determining the port attribute of port P1, leaf node 3 has already learned that the level of leaf node 3 is m, where m is a positive integer and is different from the level determined by leaf node 3 in step 830 above. Alternatively, if the port attributes of multiple ports of leaf node 3 are unknown, leaf node 3 may obtain multiple different adjacent node levels from multiple adjacent nodes, resulting in leaf node 3 determining different levels of multiple leaf nodes 3. In this case, leaf node 3 can select the largest level from the multiple levels of leaf nodes 3 as the level of leaf node 3.

[0246] The following text Figure 1 Taking the network architecture shown as an example, combined with specific examples, a method for determining port attributes of a port based on the LLDP protocol provided by another embodiment of the present application is introduced. Figure 9 The method shown includes steps 910 to 916.

[0247] 920. Assume that the levels of nodes at different levels decrease in a step of 1 from the root node to the server, and it is predetermined that if a network device is adjacent to a server, the level of the network device is 1. Within a preset time period, Figure 9The network devices in the network send LLDP messages to adjacent network devices through all ports.

[0248] The following describes a method for determining the port attributes of a port using leaf node 3 as an example. The methods for determining the port attributes of other leaf nodes in the network are similar and are omitted for brevity. Assume that leaf node 3 has three ports, denoted by P1, P2, and P3.

[0249] 910. Leaf node 3 receives an LLDP message sent by a neighboring node through port P1.

[0250] If the subtype of the port ID carried in the LLDP message is the same as the subtype of the port ID used by the server, leaf node 3 can directly determine that port P1 is a downlink port, and the level of leaf node 3 is 1.

[0251] It should be noted that the introduction to the subtypes of the above-mentioned port ID can be found in the above description, and for the sake of brevity, it will not be repeated here.

[0252] If the LLDP message carries the level A' of the neighboring node and the port attribute is a downlink port, and the level B' recorded by leaf node 3 is leaf node 3, where A' is a positive integer greater than 1 and B' is a positive integer. If A'-1 < B', leaf node 3 updates A'-1 to the level of leaf node 3 and marks port P1 as an uplink port. If A'-1 > B', leaf node 3 does not update the level of leaf node 3 and marks port P1 as an uplink port.

[0253] Of course, in the above situation, if the leaf node 3 does not record the level of the leaf node 3, the leaf node 3 can directly use A`-1 as the level of the leaf node 3.

[0254] If the LLDP message carries the neighboring node's level A and the port's port attribute is an uplink port, and leaf node 3 records its level as B, where A is a positive integer greater than 1 and B is a positive integer. If A+1<B, leaf node 3 updates A+1 to its level and marks port P1 as a downlink port. If A+1>B, leaf node 3 does not update its level and marks port P1 as a downlink port.

[0255] Of course, in the above situation, if the leaf node 3 does not record the level of the leaf node 3, the leaf node 3 can directly use A+1 as the level of the leaf node 3.

[0256] 920 , the leaf node 3 sends an LLDP message to the neighboring node through each port. The message carries the level number of the leaf node 3 and the port attribute of the port used to send the LLDP message.

[0257] The above-mentioned method for determining the level of network devices and determining the port attributes of ports can be applied in various scenarios. The following takes the method for determining the port attributes of ports as an example to apply the method for deploying anti-PFC deadlock rules to introduce the method of the embodiment of the present application. Figure 1 The network topology shown in FIG1 is used to first introduce the priority-based flow control (PFC) strategy and the formation of PFC deadlock.

[0258] exist Figure 1 In the network shown, the aforementioned PFC policy can be used to transmit data traffic. PFC is a priority-based traffic control policy. PFC allows the creation of eight virtual channels on an Ethernet link, assigning a priority to each virtual channel and allowing each virtual channel to be individually suspended and restarted while allowing traffic on other virtual channels to pass uninterrupted. This approach enables the network to create a lossless class of service for a single virtual channel, allowing it to coexist with other traffic on the same interface.

[0259] Combined with the following Figure 1 The following describes the generation of PFC deadlock using the transmission paths of data streams 1, 2, and 3 as an example. Data streams 1, 2, and 3 have the same priority and are transmitted through a virtual channel consisting of queue 5 in the network.

[0260] exist Figure 1 In the network shown, each root node is fully connected to all leaf nodes, and network devices at the same layer cannot communicate directly. Therefore, when there are no link failures in the network, the data flow direction is usually only in the up direction, or only in the down direction. Or it can be from up (up) to down (down). For example, Figure 1 Figure 2 shows the transmission paths of data stream 2 and data stream 3. Data stream 2 is the data stream that needs to be transmitted from server c to server d, and its transmission path is server c - leaf node 2 - root node 1 - leaf node 3 - server d. Data stream 3 is the data stream that needs to be transmitted from server e to server b, and its transmission path is server e - leaf node 3 - root node 2 - leaf node 2 - server c.

[0261] However, when the link between two network devices at different layers fails, data flow from downstream to upstream will occur in the network. For example, when the link between root node 2 and leaf node 4 fails, data flow 1 that needs to be transmitted from server a to server f can only go along the Figure 1The transmission path of data flow 1 shown is server a - leaf node 1 - root node 1 - leaf node 3 - root node 2 - leaf node 4 - server f. Data flow 1 is a downlink data flow between root node 1 and leaf node 3, and an uplink data flow between leaf node 3 and root node 2.

[0262] Once the above-mentioned downlink-uplink data flow is generated in the network, the data flow in this direction may form a loop with other data flows of the same priority in the network that are transmitted in the normal direction. The shape type of the loop is number 8. For example, Figure 1 The loop formed by data stream 1, data stream 2 and data stream 3 among root node 1, root node 2, leaf node 2 and leaf node 3.

[0263] To illustrate PFC deadlock, Figure 10 Only shown Figure 1 The loop in involves 4 nodes and 3 data flows that make up the loop. Figure 10 In the loop shown, when the capacity consumption of the buffer corresponding to queue 5 in leaf node 3 exceeds a threshold, indicating transient congestion, leaf node 3 sends backpressure information (also known as a "PFC pause frame") in the direction of incoming data. Specifically, leaf node 3 sends the backpressure information to root node 1 along the incoming direction of data streams 1 and 2. Accordingly, upon receiving the backpressure information, root node 1 stops or delays sending the remaining data of data streams 1 and 2, as instructed by the backpressure information, and caches the remaining data in the buffer corresponding to queue 5 on its own side. If the capacity consumption of the buffer corresponding to queue 5 in root node 1 exceeds a threshold, the backpressure information is sent to leaf node 2 along the incoming direction of data stream 2. Accordingly, leaf node 2 stops or delays sending the remaining data of data stream 2, as instructed by the backpressure information, and caches the remaining data in the buffer corresponding to queue 5 on its own side. If the capacity consumption of the buffer corresponding to queue 5 in leaf node 2 exceeds a threshold, the backpressure information is sent to root node 2 along the incoming direction of data stream 3. Accordingly, after receiving the back pressure information, root node 2 will stop sending or delay sending the remaining data of data flow 3 according to the back pressure information, and cache the remaining data in the cache corresponding to the queue 5 on the local end. If the consumption of the cache corresponding to the queue 5 of root node 2 exceeds the threshold, it will continue to follow the direction of the flow of data flow 3 and send the back pressure information to leaf node 3. This level of back pressure will eventually result in no data flow being transmitted in the queues 5 of root node 1, root node 2, leaf node 2, and leaf node 3. In other words, the traffic cached in the queues 5 between the above four nodes cannot be sent, causing the consumption of the cache capacity of the four nodes to exceed the threshold for a long time, resulting in a PFC deadlock.

[0264] In summary, we can see that the root cause of PFC deadlock is the generation of downlink-uplink data flow in the network. And when the downlink-uplink data flow is transmitted on a network device, it uses the two uplink ports of the network device. For example, when data flow 1 flows through leaf node 3, the inport (inport) P r , and outport P r+1 Therefore, in order to avoid the generation of data flow in the downstream-upstream direction in the network and thus prevent PFC deadlock, an anti-PFC deadlock rule can be deployed on each leaf node in the network. For example, an anti-PFC deadlock rule can be deployed in leaf node 3. The anti-PFC deadlock rule may include: if {inport = P r ,outport=P r+1 ,queue=5}, action: switch to queue 6, and modify the priority field of the data flow to the priority corresponding to queue 6. The anti-PFC deadlock rule means that when the ingress port of the data flow is P r , the output port is P r+1 , and the corresponding queue is queue 5, leaf node 3 needs to cache the data flow directly in queue 6 and change the priority of the data flow from the priority corresponding to queue 5 to the priority corresponding to queue 6. In other words, the priority of the traffic flowing through the two uplink ports of a network device is switched to prevent PFC deadlock.

[0265] As mentioned above, downlink-to-uplink data flows are typically caused by a link failure. This means that downlink-to-uplink data flows are generated with a certain degree of randomness. This randomness is unpredictable. Therefore, to prevent downlink-to-uplink data flows, an SDN controller (e.g., SDN controller 140) typically deploys anti-PFC deadlock rules for each pair of uplink ports on each network device in advance of data flow transmission. This can overload the SDN controller.

[0266] In order to reduce the pressure on the SDN controller to deploy anti-PFC deadlock rules, this application also provides a new deployment method for anti-PFC deadlock rules, that is, the network device itself generates anti-PFC deadlock rules based on the uplink port of the local end. Figure 11 A flowchart of a method for deploying anti-PFC deadlock rules according to an embodiment of the present application is introduced. Figure 11 The method shown can be performed by a first network device, which can be Figure 1In any leaf node of the network device shown, the first network device includes multiple sending queues, the multiple sending queues include a first sending queue and a second sending queue, and the first sending queue is the original sending queue corresponding to the first data flow. Figure 11 Includes steps 1110 to 1120.

[0267] 1110. The first network device determines the first port and the third port of the first network device as uplink ports.

[0268] It should be noted that the method for the first network device to determine the first port and the third port can refer to the method for determining the port attributes of the port above, and for the sake of brevity, it will not be repeated here. Of course, the SDN controller can also directly indicate to the first network device that the first port and the third port are uplink ports.

[0269] 1120. The first network device generates an anti-priority flow control (PFC) deadlock rule, where the anti-PFC deadlock rule is used to instruct that the first data flow be cached in the second sending queue, the ingress port of the first data flow be the first port, and the egress port of the first data flow be the third port.

[0270] Optionally, the priority corresponding to the first sending queue is different from the priority corresponding to the second sending queue, but in the final data scheduling process, the first sending queue and the second sending queue can be regarded as queues corresponding to the same priority, and data scheduling can be performed according to a preset ratio to avoid disordered transmission of data streams caused by switching queues.

[0271] Optionally, one or more anti-PFC deadlock rules may be deployed for the same group of uplink ports.

[0272] For example, multiple anti-PFC deadlock rules can be deployed for the different data flow directions of the two uplink ports. r And uplink port P r+1 The anti-PFC deadlock rules that can be deployed include: if {inport = P r ,outport=P r+1 ,queue=5}, action: switch to queue 6, and modify the priority field of the data flow to the priority corresponding to queue 6. And if {inport=P r+1 ,outport=P r ,queue=5}, Action: Switch to queue 6 and modify the priority field of the data flow to the priority corresponding to queue 6.

[0273] For another example, multiple anti-PFC deadlock rules can be deployed for two uplink ports according to different transmission modes.r And uplink port P r+1 The anti-PFC deadlock rules that can be deployed include: if {inport = P r ,outport=P r+1 ,queue=5}, action: switch to queue 6, and modify the priority field of the data flow to the priority corresponding to queue 6. And if {inport=P r+1 ,outport=P r ,queue=5}, Action: Switch to queue 3 and modify the priority field of the data flow to the priority corresponding to queue 3. Queues 5 and 6 are lossless queues, that is, they are used to transmit lossless traffic. Queue 3 is a lossy queue, that is, it is used to transmit lossy traffic.

[0274] It should be noted that the above traffic can determine whether to switch to lossless traffic transmission mode or lossy traffic transmission mode based on preset rules, thereby determining whether to switch to queue 6 or queue 3 based on the above anti-PFC deadlock rules.

[0275] Optionally, steps 1110 and 1120 may be triggered by a change in the network topology, such as adding or removing some network devices. Alternatively, steps 1110 and 1120 may be triggered after the network topology is established and before the data stream is transmitted. This embodiment of the present application is not limited thereto.

[0276] Optionally, the method further includes: the first network device determining the number of times that the first port and the third port are ports associated with PFC deadlock within a preset time period; the above-mentioned step 1120 includes: when the number is higher than a preset threshold, the first network device determining to generate the anti-PFC deadlock rule.

[0277] In the embodiment of the present application, the uplink port for generating the anti-PFC deadlock rule is determined based on the number of times, and there is no need to generate the anti-PFC deadlock rule for each group of uplink ports, which is beneficial to reducing the number of anti-PFC deadlock rules generated by the network device and reducing the storage space occupied by the anti-PFC deadlock rules.

[0278] Optionally, the method also includes: the first network device receives an indication message sent by the second network device through the first port, the indication message is used to indicate that the capacity of the cache corresponding to the third sending queue in the second network device exceeds a threshold, and the inflow flow of the third sending queue is 0, and the priority of the data flow cached by the third sending queue is the same as the priority of the first data flow; the first network device determines the number of times based on the indication message.

[0279] It should be noted that there are various ways to determine the number of times based on the indication information. For example, the indication information may indicate the total number of times that the capacity of the third sending queue exceeds a threshold and the inflow volume is zero within a preset time period. Alternatively, each time the capacity of the third sending queue exceeds the threshold and the inflow volume is zero, the second network device may send an indication information to the first network device, and the first network device may count the total number of times that the capacity of the third sending queue exceeds the threshold and the inflow volume is zero within the preset time period.

[0280] For example, the control plane of the first network device can maintain a linked list, in which one entry is <first port, third port, priority 1, Z>, indicating that within a preset time period, the first port serves as the ingress port and the third port serves as the egress port, and the number of times corresponding to priority 1 is Z. When the number Z is greater than a preset threshold, the first network device generates an anti-PFC deadlock rule for the first port and the third port.

[0281] For another example, the control plane of the first network device may maintain a linked list, in which one entry is <first port, third port, priority 1, Z'>, indicating that within a preset time period, the first port serves as the ingress port and the third port serves as the egress port, and the number of times corresponding to priority 1 is Z. Z' is a pre-configured initial number and is greater than 0. Each time an indication message is received, Z' is reduced by a preset number (e.g., 1). When the number Z' is 0, the first network device generates an anti-PFC deadlock rule for the first port and the third port.

[0282] Optionally, the indication information may carry the priority of the data flow cached by the third sending queue to indicate that the capacity of the cache corresponding to the third sending queue in the second network device exceeds a threshold and the inflow rate of the third sending queue is 0.

[0283] Optionally, the above indication information can be carried in the PDU, and the priority of the above data flow can be carried by the optional TLV in the PDU, or by a newly added TLV. For the specific encapsulation method, please refer to the above introduction to the encapsulation method of the PDU. For the sake of brevity, it will not be repeated here.

[0284] Combined with the above Figures 1 to 11 The method of the embodiment of the present application is described in detail below. Figures 12 to 14 The device for determining the port attribute of a port in an embodiment of the present application is described in detail. It should be noted that, Figures 12 to 14 The device shown can implement each step in the above method, and for the sake of brevity, it will not be described again here.

[0285] Figure 12 This is a schematic block diagram of an apparatus for determining port attributes of a port according to an embodiment of the present application. Figure 12The apparatus 1200 shown may be, for example, the first network device described above, and specifically includes a receiving module 1210 and a processing module 1220. Optionally, the receiving module 1210 is configured to perform the above step 210, and the processing module 1220 is configured to perform the above step 220. Optionally, the processing module 1220 is further configured to perform the above steps 1110 and 1120.

[0286] That is, the receiving module 1210 is configured to receive a protocol data unit (PDU) sent by the second network device through the first port;

[0287] The processing module 1220 is configured to determine whether the first port is an uplink port or a downlink port according to the PDU received by the receiving module.

[0288] Optionally, as an embodiment, the PDU carries the level of the second network device in the network, and / or the PDU carries the port attributes of the second port used by the second network device to send the PDU, and the port attributes of the second port include that the second port is an uplink port or the second port is a downlink port.

[0289] Optionally, as an embodiment, the processing module is specifically used to: determine the level of the first network device in the network according to the PDU; and determine whether the first port is an uplink port or a downlink port according to the level of the first network device.

[0290] Optionally, as an embodiment, the network includes multiple network devices, the multiple network devices include the second network device, and the receiving module is further used to: receive multiple PDUs sent by the multiple network devices through multiple ports, the multiple ports include the first port, and the multiple PDUs include the PDU sent by the second network device; the processing module is also used to: determine the levels of the multiple network devices in the network based on the multiple PDUs; select a target level from the levels of the multiple network devices; and determine the level of the first network device based on the target level and preset rules.

[0291] Optionally, as an embodiment, the processing module is specifically configured to: determine whether the first port is an uplink port or a downlink port according to the level of the first network device and the level of the second network device.

[0292] Optionally, as an embodiment, the processing module is specifically used to: determine the level of the second network device according to the PDU; and determine whether the first port is an uplink port or a downlink port according to the level of the second network device.

[0293] Optionally, as an embodiment, the second network device is the root node in the network, and the receiving module is also used to: receive the PDU sent by the second network device through the first port, and the level of the second network device carried in the PDU is a preset value; the processing module is also used to: determine that the first port is an uplink port according to the preset value.

[0294] Optionally, as an embodiment, the processing module is further used to: determine the level of the first network device according to the preset value, wherein, in the network, the level represented by the level of the first network device is adjacent to the level where the root node is located.

[0295] Optionally, as an embodiment, the processing module is further used to: determine, based on the PDU, that the second network device is a server, the PDU carries a first TLV, and the first TLV indicates that the second network device is a server; and determine that the first port is a downlink port.

[0296] Optionally, as an embodiment, the PDU is an LLDP PDU.

[0297] Optionally, as an embodiment, the processing module is further used to: determine that the second network device is a server according to the subtype of the port ID in the LLDP PDU; and determine that the first port is a downlink port.

[0298] Optionally, as an embodiment, the processing module is also used to: determine the level of the first network device based on the subtype of the port ID in the LLDP PDU, wherein the level represented by the level of the first network device in the network is adjacent to the level where the server is located.

[0299] Optionally, as an embodiment, the device further includes a sending module, which is used to: send an LLDP request to the second network device, wherein the LLDP request is used to request the port attributes of the second port of the second network device, and / or the level of the second network device in the network.

[0300] Optionally, as an embodiment, if the port attribute of the first port is unknown, the sending module is further configured to send the LLDP request to the second network device.

[0301] Optionally, as an embodiment, the LLDP PDU includes a second TLV, where the second TLV is used to indicate the level of the second network device, and / or the LLDP PDU includes a third TLV, where the third TLV is used to indicate a port attribute of the second port.

[0302] Optionally, as an embodiment, the second TLV or the third TLV occupies a reserved bit in the LLDP PDU.

[0303] Optionally, as an embodiment, the device also includes multiple sending queues, the multiple sending queues include a first sending queue and a second sending queue, the first sending queue is the original sending queue corresponding to the first data stream, and the processing module is also used to determine that the first port and the third port of the first network device are uplink ports; and generate an anti-priority flow control PFC deadlock rule, the anti-PFC deadlock rule is used to indicate that the first data stream is cached to the second sending queue, the inlet port of the first data stream is the first port, and the outlet port of the first data stream is the third port.

[0304] Optionally, as an embodiment, the processing module is further used to: determine the number of times that the first port and the third port are PFC deadlock-associated ports within a preset time period; when the number is higher than a preset threshold, determine to generate the anti-PFC deadlock rule.

[0305] Optionally, as an embodiment, the sending module is further used to receive indication information sent by the second network device through the first port, the indication information being used to indicate that the capacity of the cache corresponding to the third sending queue in the second network device exceeds a threshold, and the inflow flow of the third sending queue is 0, and the priority of the data flow cached by the third sending queue is the same as the priority of the first data flow; the processing module is used to determine the number of times based on the indication information.

[0306] Figure 13 is a schematic block diagram of an apparatus for determining port attributes according to another embodiment of the present application. Figure 13 The apparatus 1300 shown may be, for example, the second network device mentioned above, and may specifically include a processing module 1310 and a sending module 1320. Optionally, the processing module 1310 is configured to execute step 200, and the sending module 1320 is configured to execute the function implemented by the second network device in step 210.

[0307] That is, the processing module 1310 is configured to generate a protocol data unit (PDU), wherein the PDU is used to determine whether the first port of the first network device is an uplink port or a downlink port;

[0308] The sending module 1320 is configured to send the PDU generated by the processing module to the first network device through the second port.

[0309] Optionally, as an embodiment, the PDU carries the level of the second network device in the network, and / or the PDU carries the port attributes of the second port used by the second network device to send the PDU, and the port attributes of the second port include that the second port is an uplink port or the second port is a downlink port.

[0310] Optionally, as an embodiment, the second network device is a root node in the network, and the level of the second network device carried in the PDU is a preset value.

[0311] Optionally, as an embodiment, the second network device is a server, the PDU carries a first TLV, and the first TLV indicates that the second network device is a server.

[0312] Optionally, as an embodiment, the PDU is an LLDP PDU.

[0313] Optionally, as an embodiment, the apparatus further includes a receiving module, the receiving module being used to receive an LLDP request sent by the first network device, the LLDP request being used to request port attributes of the second port and / or the level of the second network device.

[0314] Optionally, as an embodiment, the LLDP PDU includes a second TLV, where the second TLV is used to indicate the level of the second network device, and / or the LLDP PDU includes a third TLV, where the third TLV is used to indicate a port attribute of the second port.

[0315] Optionally, as an embodiment, the second TLV or the third TLV occupies a reserved bit in the LLDP PDU.

[0316] Optionally, as an embodiment, the sending module is also used to send an indication message to the first network device, wherein the indication message is used to indicate that the capacity of the cache corresponding to the third sending queue in the device exceeds a threshold, and the inflow flow of the third sending queue is 0, and the priority of the data flow cached by the third sending queue is the same as the priority of the first data flow.

[0317] In an optional embodiment, the receiving module 1210 may be an ingress port 1430, the processing module 620 may be a processor 1420, and the network device may further include a memory 1410 and an egress port 1440. Figure 14 shown.

[0318] In an optional embodiment, the sending module 1310 may be an egress port 1440, the processing module 1320 may be a processor 1420, and the network device may further include a memory 1410 and an ingress port 1430. Figure 14 shown.

[0319] Figure 14 It is a schematic block diagram of a network device according to another embodiment of the present application. Figure 14 The illustrated network device 1400 may include a memory 1410, a processor 1420, an ingress port 1430, and an egress port 1440. The memory 1410, the processor 1420, the ingress port 1430, and the egress port 1440 are connected via an internal connection path. The memory 1410 is configured to store instructions, and the processor 1420 is configured to execute the instructions stored in the memory 1420 to control the ingress port 1430 to receive input PDUs or data streams and to control the egress port 1440 to forward PDUs or data streams to be sent.

[0320] It should be noted that the ingress port 1430 may be one of multiple ports included in the network device. The egress port 1440 may be one of multiple ports included in the network device. The ingress port 1430 and egress port 1440 may be understood as two logical ports, that is, they may correspond to two physical ports or one physical port, respectively, and this application does not limit this.

[0321] During implementation, each step of the above method can be completed by an integrated logic circuit of the hardware in the processor 1420 or by instructions in the form of software. The method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 1410, and the processor 1420 reads the information in the memory 1410 and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.

[0322] It should be understood that in the embodiments of the present application, the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0323] It should also be understood that in the embodiments of the present application, the memory may include read-only memory and random access memory, and provide instructions and data to the processor. A portion of the processor may also include non-volatile random access memory. For example, the processor may also store device type information.

[0324] It should be understood that in the embodiments of the present application, "B corresponding to A" means that B is associated with A and B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B based solely on A, but B can also be determined based on A and / or other information.

[0325] It should be understood that the term "and / or" in this document simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0326] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0327] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0328] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0329] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0330] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0331] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0332] If the functions are implemented in the form of software functional units and sold or used as independent products, they 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. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0333] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for determining port attributes, characterized in that: include: The first network device receives a protocol data unit PDU sent by the second network device through the first port; The first network device determines, according to the PDU, that the first port is an uplink port; The first network device determines that the third port of the first network device is an uplink port; The first network device generates an anti-priority flow control PFC deadlock rule, where the anti-PFC deadlock rule is used to instruct the first data stream to be switched from a first sending queue to a second sending queue, where the ingress port of the first data stream is the first port, and the egress port of the first data stream is the third port. The first sending queue and the second sending queue are sending queues on the first network device, and the first sending queue is an original sending queue corresponding to the first data stream.

2. The method according to claim 1, characterized in that The PDU carries the level of the second network device in the network, and / or, The PDU also carries the port attribute of the second port used by the second network device to send the PDU, and the port attribute of the second port includes that the second port is an uplink port or the second port is a downlink port.

3. The method according to claim 2, characterized in that The first network device determines, according to the PDU, that the first port is an uplink port, including: The first network device determines, according to the PDU, the level of the first network device in the network; The first network device determines that the first port is an uplink port according to the level of the first network device.

4. The method according to claim 3, characterized in that The network includes a plurality of network devices, the plurality of network devices including the second network device, The first network device receives a protocol data unit PDU sent by a second network device through a first port, including: The first network device receives a plurality of PDUs sent by the plurality of network devices through a plurality of ports, the plurality of ports including the first port, and the plurality of PDUs including the PDU sent by the second network device; The first network device determines, according to the PDU, the level of the first network device in the network, including: The first network device determines, according to the plurality of PDUs, the levels of the plurality of network devices in the network; The first network device selects a target level from the levels of the plurality of network devices; The first network device determines the level of the first network device according to the target level and a preset rule.

5. The method according to claim 3 or 4, characterized in that The first network device determines, according to the level of the first network device, that the first port is the uplink port, including: The first network device determines that the first port is an uplink port according to the level of the first network device and the level of the second network device.

6. The method according to claim 2, characterized in that The first network device determines, according to the PDU, that the first port is an uplink port, including: The first network device determines the level of the second network device according to the PDU; The first network device determines the first port as an uplink port according to the level of the second network device.

7. The method according to claim 6, characterized in that The second network device is a root node in the network, and the first network device receives a PDU sent by the second network device through a first port, including: The first network device receives the PDU sent by the second network device through the first port, and the level of the second network device carried in the PDU is a preset value; The first network device determines, according to the level of the second network device, that the first port is an uplink port, including: The first network device determines the first port as an uplink port according to the preset value.

8. The method according to any one of claims 1 to 4, characterized in that The PDU is a link layer discovery protocol LLDPPDU.

9. The method according to claim 8, characterized in that Before the first network device receives the protocol data unit PDU sent by the second network device, the method further includes: The first network device sends an LLDP request to the second network device, where the LLDP request is used to request the second network device to send port attributes of a second port used by the PDU and / or the level of the second network device in the network.

10. The method according to claim 9, characterized in that The first network device sending an LLDP request to the second network device includes: If the port attribute of the first port is unknown, the first network device sends the LLDP request to the second network device.

11. A first network device, characterized in that: include: A receiving module, used for receiving a protocol data unit PDU sent by the second network device through the first port; a processing module, configured to determine, according to the PDU received by the receiving module, that the first port is an uplink port; The processing module is also used for: Determine that the third port of the first network device is an uplink port; Generate an anti-priority flow control PFC deadlock rule, where the anti-PFC deadlock rule is used to instruct to switch a first data stream from a first sending queue to a second sending queue, where an ingress port of the first data stream is the first port, and an egress port of the first data stream is the third port. The first sending queue and the second sending queue are sending queues on the first network device, and the first sending queue is an original sending queue corresponding to the first data stream.

12. The first network device according to claim 11, characterized in that: The PDU carries the level of the second network device in the network, and / or, The PDU also carries the port attribute of the second port used by the second network device to send the PDU, and the port attribute of the second port includes that the second port is an uplink port or the second port is a downlink port.

13. The first network device according to claim 12, characterized in that: The processing module is also used for: determining the level of the first network device in the network according to the PDU; According to the level of the first network device, the first port is determined to be an uplink port.

14. The first network device according to claim 13, characterized in that: The network includes a plurality of network devices, the plurality of network devices including the second network device, The receiving module is further configured to receive a plurality of PDUs sent by the plurality of network devices through a plurality of ports, the plurality of ports including the first port, and the plurality of PDUs including the PDU sent by the second network device; The processing module is further used to determine the levels of the plurality of network devices in the network according to the plurality of PDUs; The processing module is further used to select a target level from the levels of the plurality of network devices; The processing module is further used to determine the level of the first network device according to the target level and a preset rule.

15. The first network device according to claim 13 or 14, characterized in that: The processing module is further used for: The first port is determined as an uplink port according to the level of the first network device and the level of the second network device.

16. The first network device according to claim 12, characterized in that: The processing module is further used for: determining the level of the second network device according to the PDU; The first port is determined as an uplink port according to the level of the second network device.

17. The first network device according to claim 16, characterized in that: The second network device is a root node in the network, The receiving module is further configured to receive the PDU sent by the second network device through the first port, wherein the level of the second network device carried in the PDU is a preset value; The processing module is further configured to determine, according to the preset value, that the first port is an uplink port.

18. The first network device according to any one of claims 11 to 14, characterized in that: The PDU is a Link Layer Discovery Protocol LLDP PDU.

19. The first network device according to claim 18, characterized in that: The first network device also includes: A sending module is used to send an LLDP request to the second network device, where the LLDP request is used to request the second network device to send the port attributes of the second port used by the PDU and / or the level of the second network device in the network.

20. The first network device according to claim 19, characterized in that: The sending module is further configured to send the LLDP request to the second network device if the port attribute of the first port is unknown.

21. A network device, characterized in that: The invention comprises a processor, wherein the processor is used to be coupled with a memory, read and execute instructions in the memory, so as to perform the method according to any one of claims 1 to 10.

22. A computer readable medium, characterized in that The computer-readable medium stores a program code, and when the computer program code is executed on a computer, the computer is caused to execute the method according to any one of claims 1 to 10.

23. A computer program product, characterized in that The computer program product stores program codes, and when the computer program codes are run on a computer, the computer is caused to execute the method according to any one of claims 1 to 10.

Images