Dynamically discover service nodes in the network

Abstract

The present disclosure describes various methods, systems, and devices related to dynamic service node discovery in a network. In one example method, an intermediate node receives a Link Layer Discovery Protocol (LLDP) message from a first node. The LLDP message includes a discovery type-length-value (TLV), and the discovery TLV indicates the location of a service node in the network. The method also includes forwarding the LLDP message to a second node.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Application No. 16 / 598,919, filed on October 10, 2019, which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure generally relates to generating messages that can be used to notify devices in a network that a service node is connected to the network, and dynamically discovering and monitoring service nodes in the network. Background Art

[0004] Various network topologies are designed to be efficient, scalable, and enable fast communication between various network devices. In some cases, these network topologies can be applied to data center environments. The devices in many modern data center environments are arranged according to a spine-leaf configuration. A leaf-spine network may include two layers: a spine layer and a leaf layer. The spine layer may include one or more top-level switches. The leaf layer may include multiple lower-level switches connected to the top-level switches in a fully interconnected mesh topology. The lower-level switches may be connected to host servers with various computer resources that may be used for various purposes, such as hosting tenants, hosting virtual machines (VMs), storing data, performing calculations, and the like. Due to the interconnectivity within the spine and leaf layers, data packets transmitted between devices within the network are transmitted through the same number of nodes and interfaces. Therefore, data traffic can travel through the leaf-spine network at consistent speeds and latency.

[0005] The computing resources of the host servers can be controlled and managed by a central controller connected to the leaf-spine network. The central controller can be a software-defined network controller that can manage, configure, and enable communications between devices in the network. For example, the central controller can manage the lower-layer switches and the top-layer switches within the leaf-spine network, and can also enable communications between host servers connected to the lower-layer switches.

[0006] When a new host server joins the network, the central controller must first discover the server before it can manage resources in the host server and enable communications to and from the host server. In various networks, the lower-layer switch can send a Link Layer Discovery Protocol (LLDP) message to the host server connected to the lower-layer switch. Once the host server receives the LLDP message, the host server can be aware of the lower-layer switch. However, the host server may not be able to communicate directly with the central controller. Therefore, some networks require additional resource controllers to receive messages indicating their connections from the host servers, and the network controller may have to individually query the resource controllers to have them individually report the connection of the host server to the network controller. In addition, LLDP messages are typically designed to travel only a single hop in the network. Therefore, if there are any nodes between the lower-layer switch and the host server, the host server may not be able to receive the LLDP message directly from its nearest lower-layer switch. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The following detailed description is made with reference to the accompanying drawings. In the figures, the leftmost (one or more) digits of a reference number identify the figure in which the reference number first appears. The use of the same reference number in different figures indicates similar or identical items. The systems depicted in the figures are not drawn to scale, and the components in the figures may be depicted as not drawn to scale with each other.

[0008] Figure 1 An example environment for implementing service node discovery and monitoring is shown.

[0009] Figure 2 Example signaling associated with an intermediate node is shown.

[0010] Figure 3 Examples of Link Layer Discovery Protocol (LLDP) messages according to various embodiments of the present disclosure are shown.

[0011] Figure 4A An example of a discovery type-length-value (TLV) in an LLDP message generated by a service node is shown.

[0012] Figure 4B Another example of a discovery TLV in an LLDP message generated by a service node is shown.

[0013] Figure 5A An example of a Hop Count TLV in an LLDP message generated by a service node is shown.

[0014] Figure 5B Another example of a Hop Count TLV in an LLDP message generated by a service node is shown.

[0015] Figure 6An example process for forwarding LLDP messages is shown.

[0016] Figure 7 An example process for relaying LLDP messages is shown.

[0017] Figure 8 An example process is shown by which a node in a leaf-spine network can discover and / or confirm the presence of a service node in a cluster network connected to the leaf-spine network.

[0018] Fig. 9 An example process is shown by which a network controller in a leaf-spine network can discover and monitor service nodes.

[0019] Fig.10 is a computing system diagram illustrating the configuration of a data center that can be used to implement aspects of the technology disclosed herein.

[0020] Fig.11 An example computer architecture is shown for a computer capable of executing program components for implementing the above-described functionality. DETAILED DESCRIPTION

[0021] Overview

[0022] Various aspects of the invention are set out in the independent claims and preferred features are set out in the dependent claims. Features of one aspect may be applicable to any aspect alone or in combination with other aspects.

[0023] Various embodiments of the present disclosure relate to link layer discovery protocol (LLDP) messages generated by service nodes for dynamically discovering service nodes in a network. Certain embodiments enable a network controller associated with a leaf-spine network to dynamically discover service nodes without the assistance of a third-party resource controller.

[0024] In an example implementation, LLDP messages are generated, relayed, and / or received by network devices. These network devices may include servers, switches, etc. In various implementations, the techniques described herein may be performed by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the methods described herein.

[0025] Example Embodiments

[0026] In a particular embodiment, the service node is configured to generate and send LLDP messages. The LLDP message may include a "discovery" type-length-value (TLV) that may identify the service node, indicate how the service node is connected to the network, specify the capabilities of the service node, etc. When a leaf node in a leaf-spine network receives the LLDP message, the leaf node may advertise the service node to a network controller within the leaf-spine network. Therefore, the LLDP message may enable the network controller to efficiently identify when the service node is connected to the leaf-spine network. In some cases where the service node periodically sends LLDP messages, the network controller may also use the LLDP message as a health check to identify whether the service node remains connected to the network.

[0027] In some embodiments, one or more intermediate nodes may exist between the service node and the leaf node. These intermediate nodes may be configured to relay LLDP messages from the service node to the leaf node. The LLDP message may also include a "hop count" TLV (also referred to as a "relay hop count" TLV). The hop count TLV in a particular LLDP message may specify a count value that may be modified each time the intermediate node relays the LLDP message. When the count value in the hop count TLV reaches a specific number (e.g., zero), the intermediate node may avoid relaying LLDP to another network node. Therefore, the hop count TLV may prevent the LLDP message generated by the service node from being relayed indefinitely by the intermediate node.

[0028] Embodiments of the present disclosure may provide various improvements to computer networks. When a leaf-spine network relies on LLDP messages generated by leaf nodes to service nodes to discover service nodes, a network controller associated with the leaf-spine network may have to rely on a resource controller to determine the presence of the service node. The resource controller may be external to the network structure and / or managed by a third party. However, in specific embodiments described herein, the LLDP messages generated by the service node can be used to notify the leaf node that a service node exists in the network, thereby eliminating the need for a resource controller to discover the service node in the network.

[0029] Various embodiments of the present disclosure will now be described with reference to the accompanying drawings.

[0030] Figure 1An example environment 100 for implementing service node discovery and monitoring is shown. As shown, the environment includes a leaf-spine network 102. The leaf-spine network includes multiple leaf nodes 104-1 to 104-3 connected to multiple spine nodes 106-1 and 106-2. As used herein, the terms "node", "network node" and their equivalents may refer to any entity within a network that can send data packets to at least one other node and / or receive data packets from at least one other node. A node may be a device, a software instance, a virtual machine (VM), a network switch, etc. In some examples, a node may be a client, a server, or a combination thereof. In various examples, each of the multiple leaf nodes 104-1 to 104-3 may be a lower layer network switch, and each of the multiple spine nodes 106-1 and 106-2 may be an upper layer network switch. As used herein, the term "network switch" may refer to a multi-port bridge that is configured to receive data, process data, and selectively forward data to another device connected to the network switch. As used herein, the term "layer" may refer to a plurality of network nodes that are connected to other nodes within a network but are not directly interconnected to each other. Thus, leaf nodes 104-1 through 104-3 are part of a layer (e.g., a lower layer or leaf layer) within leaf-spine network 102, and spine nodes 106-1 and 106-2 are part of a layer (e.g., an upper layer or spine layer) within leaf-spine network 102.

[0031] Each of the leaf nodes 104-1 to 104-3 is connected to each of the spine nodes 106-1 and 106-2 via a network interface. As used herein, the terms "interface", "link" and their equivalents may refer to the connection between two nodes in a network. In some cases, the interface may directly connect two nodes and / or may omit any intermediate nodes. The interface may be connected to a first port of a first device and a second port of a second device. In some cases, the interface between the two nodes may be a wired interface so that data may be transmitted as a conducted signal through a solid medium (e.g., an Ethernet cable, an optical fiber cable, etc.) connecting the two nodes. In some examples, the interface between the nodes may be a wireless interface so that data packets may be transmitted as a signal (e.g., electromagnetic waves, ultrasonic waves, etc.) through a fluid medium (e.g., air, water, etc.) connecting the two nodes. An interface (e.g., one of the interfaces between one of the leaf nodes 104-1 to 104-3 and one of the spine nodes 106-1 and 106-2) may interconnect two ports. As used herein, the term "port" and its equivalents may refer to a hardware and / or software connection between a device or software instance and a communication interface. A given software-based port can be identified by its port number. Figure 1Three leaf nodes 104-1 to 104-3 and two spine nodes 106-1 and 106-2 are shown, but the embodiments are not limited thereto. Additional leaf nodes and / or spine nodes may be included in the leaf-spine network 102. However, regardless of the number of leaf nodes and / or spine nodes, each leaf node within the leaf-spine network may be directly connected to all spine nodes within the leaf-spine network.

[0032] In various embodiments, a network controller 108 (also referred to as a "network fabric controller," "fabric controller," or equivalent) may be configured to manage communications within the leaf-spine network 102. The network controller 108 may be connected to any leaf node of the leaf nodes 104-1 to 104-3 and / or any spine node of the spine nodes 106-1 and 106-2. In various embodiments, the network controller 108 and the leaf-spine network 102 may be part of an internal network having a common security policy. The network controller 108 may be configured to directly connect to any node within the leaf-spine network 102. The network controller 108 may also be configured to manage at least some elements of a cluster network (e.g., cluster network 110) connected to the leaf nodes 104-1 to 104-3. The network controller 108 may be configured to control various nodes within a data center fabric including the leaf-spine network 102 and any nodes connected to the leaf-spine network 102.

[0033] The cluster network 110 may include a service node 114 and a plurality of intermediate nodes 112-1 to 112-3. As used herein, the term "cluster network" may refer to one or more service nodes connected to at least one leaf node in a leaf-spine network. In some examples, a cluster network (e.g., Figure 1 The cluster network 110 shown in ) may include one or more intermediate nodes that interconnect (one or more) service nodes and (one or more) leaf nodes. As used herein, the terms "service node", "extended leaf node", "initiator" and their equivalents may refer to a network node in a cluster network that is configured to store, generate and / or process data. According to various embodiments, the leaf-spine network 102 and the cluster network 110 may be considered to be part of the same network or network structure. In some cases, a service node (e.g., service node 114) may include one or more computing resources (e.g., memory, processing power, etc.) that can be used to host tenants, virtual machines (VMs), etc. For example, a service node may be a server.

[0034] As used herein, the terms "intermediate node", "repeater" and their equivalents may refer to a network node in a cluster network that is configured to receive data and send data to other nodes in the network. An example of an intermediate node may be a top-of-rack (ToR) switch. In a particular embodiment, an intermediate node may be connected to a single leaf node. For example, Figure 1As shown in FIG. 1 , the first intermediate node 112-1 is directly connected to the first leaf node 104-1. In some embodiments, the intermediate node may be connected to multiple (e.g., one or two) leaf nodes. For example, Figure 1 As shown in , the second intermediate node 112-2 is connected to both the first leaf node 104-1 and the second leaf node 104-2. The intermediate node can be connected to one or more service nodes. For example, Figure 1 The third intermediate node 112-3 shown in is connected to the service node 114. In some cases, the intermediate node can be connected to other intermediate nodes. For example, the third intermediate node 112-3 is connected to both the first intermediate node 112-1 and the second intermediate node 112-2 in the uplink direction. Similarly, each of the first intermediate node 112-1 and the second intermediate node 112-2 is connected to the third intermediate node 112-3 in the downlink direction. As used herein, the term "uplink" may refer to the direction of the interface and / or data transmission extending toward the spine node in the leaf spine network (e.g., toward the spine nodes 106-1 to 106-2 in the leaf spine network 102), and is opposite to the downlink direction. As used herein, the term "downlink" may refer to the direction of the interface and / or data transmission extending toward the service node in the cluster network (e.g., toward the service node 114 in the cluster network 110), and is opposite to the uplink direction.

[0035] The intermediate nodes 112-1 to 112-3 may be arranged in one or more layers in the cluster network 110. For example, the first intermediate node 112-1 and the second intermediate node 112-2 may be part of the first layer, and the third intermediate node 112-3 may be part of the second layer. Figure 1 Only two layers of intermediate nodes are shown in FIG. 1 , but in various embodiments, the cluster network 110 may include more or fewer layers. Figure 1 Only three intermediate nodes 112 - 1 to 112 - 3 are shown in FIG. 1 , but in various implementations, the cluster network 110 may include more or fewer intermediate nodes.

[0036] In some embodiments, network controller 108 may be able to remotely manage computing resources in service node 114. However, network controller 108 may not be able to manage intermediate nodes 112-1 to 112-3. Cluster network 110 may be an external network. In some cases, although Figure 1 Not shown, one or more firewalls may be provided between the intermediate nodes 112 - 1 to 112 - 3 and the leaf nodes 104 - 1 and 104 - 2 , or within the leaf nodes 104 - 1 to 104 - 3 themselves, thereby protecting the internal network from external security threats, such as security threats from the cluster network 110 .

[0037] The service node 114 may join the cluster network 110 by connecting to at least one of the intermediate nodes in the cluster network 110 (e.g., the third intermediate node 112-3). Once the service node 114 is connected to the cluster network 110, the service node 114 may begin sending at least one link layer discovery protocol (LLDP) message 116 to the leaf-spine network 102. The LLDP message 116 may be an LLDP frame having one or more custom type-length-value (TLV) fields that enable discovery of the service node 114. For example, the LLDP message 116 may include a discovery TLV and / or a hop count TLV, examples of which are described below with respect to Figures 3 to 5B Describe in more detail.

[0038] In various embodiments of the present disclosure, the intermediate nodes within the cluster network 110 may receive the LLDP message 116 from the service node 114. For example, the third intermediate node 112-3 may first receive the LLDP message 116 sent from the service node 114. Typically, the LLDP message is transmitted only one hop in the network, that is, from one node to another across a single interface. However, in various embodiments described herein, the third intermediate node 112-3 may be configured to relay the LLDP message 116 to at least one other node in the network. For example, the third intermediate node 112-3 may resend the LLDP message 116 to both the first intermediate node 112-1 and the second intermediate node 112-2 in the uplink direction. Similarly, the first intermediate node 112-1 and the second intermediate node 112-2, when receiving the LLDP message 116, may both relay the LLDP message 116 to another network node in the uplink direction. The LLDP message 116 from the service node 114 may thereby travel through the cluster network 110 and may be received by at least one leaf node in the leaf-spine network 102. Figure 1 , the first leaf node 104-1 can receive the LLDP message 116 from the first intermediate node 112-1 and / or the second intermediate node 112-2, and the second leaf node 104-2 can receive the LLDP message 116 from the second intermediate node 112-2. Therefore, the first leaf node 104-1 and / or the second leaf node 104-2 in the leaf-spine network 102 can recognize the existence of the service node 114.

[0039] Once the first leaf node 104-1 and / or the second leaf node 104-2 recognizes the presence of the service node 114, the first leaf node 104-1 and / or the second leaf node 104-2 can report the presence of the service node 114 to the network controller 108. In various embodiments, the first leaf node 104-1 and / or the second leaf node 104-2 can avoid relaying the LLDP message 116 to other nodes in the leaf-spine network 102. For example, if the first leaf node 104-1 receives the LLDP message 116, the first leaf node 104-1 can avoid forwarding the LLDP message 116 to the first spine node 106-1 and the second spine node 106-2. The network controller 108 can therefore manage and / or monitor the service node 114.

[0040] LLDP messages 116 may be used to discover service nodes 114 and to continually monitor the connectivity of service nodes 114. For example, an initial LLDP message 116 sent by service node 114 to leaf-spine network 102 via cluster network 110 may be used by controller 108 to discover service node 114. Subsequently, service node 114 may periodically send additional LLDP messages 116 to leaf-spine network 102 via cluster network 110. These additional LLDP messages 116 may be used by controller 108 to identify that service node 114 remains connected to cluster network 110. If controller 108 identifies that periodic LLDP messages 116 are interrupted and / or delayed, controller 108 may identify that there is an interruption in the connectivity of cluster network 110 and / or service node 114. In some cases, controller 108 may balance the load on service node 114 to another service node connected to leaf-spine network 102. In some examples, controller 108 may notify a user or central administrator that there is a problem with service node 114.

[0041] As shown, environment 100 can be associated with layer 2 (L2) network devices and layer 3 (L3) network devices. Elements of cluster network 110 (e.g., intermediate nodes 112-1 to 112-3 and service node 114) can be L2 network devices. For example, intermediate nodes 112-1 to 112-3 can include network devices configured to process and forward data at the L2 layer, such as bridges. In some cases, intermediate nodes 112-1 to 112-3 forward data packets between devices according to hardware addresses, media access control (MAC) addresses, etc. indicated by data packets. Elements of leaf-spine network 102 (e.g., leaf nodes 104-1 to 104-3 and / or spine nodes 106-1 to 106-2) can be L3 network devices. In some cases, elements of leaf-spine network 102 can support routing functions. In various embodiments, leaf nodes 104-1 to 104-3 can be multilayer switches configured to interconnect L2 and L3.

[0042] According to various embodiments of the present disclosure, network controller 108 may be authorized to directly discover and / or monitor the existence of service node 114 without separately querying another device (e.g., a resource controller connected to service node 114). Therefore, network controller 108 may be able to efficiently manage computing resources within service node 114.

[0043] Figure 2 The intermediate node 112 (eg, the above reference Figure 1 1 to 112-3) is associated with an example signaling 200. The signaling 200 involves relaying a link layer discovery protocol (LLDP) message, such as LLDP message 116, by the intermediate node 112. The intermediate node 112 may be part of a cluster network, such as the one described above with reference to FIG. Figure 1 A portion of cluster network 110 is depicted.

[0044] As shown, the intermediate node 112 receives the LLDP message 116 from the previous node 202. The intermediate node 112 is located in the uplink direction relative to the previous node 202. In various examples, the previous node 202 can be another intermediate node or a service node. If the previous node 202 is an intermediate node, the previous node 202 is located between the intermediate node 112 and the service node.

[0045] LLDP message 116 may include at least two type-length-value (TLV) fields: a discovery TLV 204 and a hop count TLV. Discovery TLV 204 indicates various information about the service node from which LLDP message 116 originates. In some cases, the value of discovery TLV 204 may indicate at least one of the location of the service node, the type of the service node, and the capabilities of the service node. Discovery TLV 204 includes information that enables a network controller (e.g., as described above in reference to FIG. 1 ) to discover the service node. Figure 1 The described network controller 108) is capable of discovering, monitoring and / or managing information of computing resources in the service node.

[0046] The value of the hop count TLV 206 may include a count value indicating the remaining number of hops that the LLDP message 116 is designed to travel through the cluster network. The hop count TLV 206 includes a count value n-1 208 when received by the intermediate node 112. The count value may be initialized by the service node. In an example where the previous node 202 is a service node, the count value n-1 208 may be an initial count value. Some examples of the initial count value may be values ​​in the range of 2 to 10, but embodiments are not limited to these values. In some cases, the initial count value is set based on the number of layers in the cluster network. For example, if the cluster network is a two-layer network, the initial count value may be initialized to 3 to ensure that the LLDP message 116 is forwarded to at least one leaf node connected to the cluster network.

[0047] When receiving the LLDP message 116, the intermediate node 112 may generate a count value n 210 based on the count value n-1 208. In some cases, the count value n 210 is calculated according to the following formula 1:

[0048] V n =V n-1 -1

[0049] Among them, V n is the count value n 210, V n-1 is the count value n-1 208. In other words, the intermediate node 112 may subtract 1 from the count value n-1 208 to generate the count value n 210.

[0050] In various embodiments, the intermediate node 112 may determine whether the count value n 210 is above a certain threshold. In some cases, the threshold may be 0, but embodiments are not limited thereto. If the intermediate node 112 determines that the count value n 210 is equal to or less than the threshold, the intermediate node 112 may avoid forwarding the LLDP message 116 to the next node. However, if the intermediate node 112 determines that the count value n 210 is greater than the threshold, the intermediate node 112 may replace the count value n-1 208 in the hop count TLV 206 with the count value n 210 and forward the LLDP message 116 (and the count value n 210) to the next node 212.

[0051] The next node 212 may be another intermediate node in the cluster network or a leaf node (e.g., leaf node 104-1 or 104-2) in a leaf-spine network (e.g., leaf-spine network 102). In an example where the next node 212 is another intermediate node, the next node 212 may update the hop count TLV 206 similarly to the intermediate node 112, check whether the updated hop count TLV 206 indicates that the LLDP message 116 should be forwarded, and forward or avoid forwarding the LLDP message 116 to another node.

[0052] In the case where the next node 212 is a leaf node, the leaf node may forward the LLDP message 116, at least in part, to a network controller (e.g., the network controller 108) of the leaf-spine network. According to some examples, the leaf node may avoid forwarding the entire LLDP message 116. However, in some cases, the leaf node may forward information based at least on the value of the discovery TLV 204 to the network controller. For example, the leaf node may forward at least one of the location of the service node, the type of the service node, and the capabilities of the service node to the network controller. The network controller may use the information in the value of the discovery TLV 204 to discover the service node, manage computing resources in the service node, and / or confirm that the service node is connected to the cluster network.

[0053] According to various embodiments, relaying the LLDP message 116 by the intermediate node 112 may enable the leaf-spine network to discover and / or confirm the presence of a service node in the network. In addition, the process of modifying the hop count TLV 206, confirming that the value of the hop count TLV 206 is above a certain threshold, and forwarding the LLDP message 116 with the modified hop count TLV 206 ensures that the LLDP message 116 is not forwarded indefinitely between intermediate nodes in the cluster network.

[0054] Figure 3 An example of a link layer discovery protocol (LLDP) message 300 is shown. The LLDP message 300 may be generated and sent by a service node in a cluster network and / or relayed by an intermediate node. As shown, the LLDP message 300 may include a chassis identification (ID) type-length-value (TLV) 302, a port ID TLV 304, a lifetime TLV 306, a discovery TLV 308, a hop count TLV 310, and an LLDP data unit (LLDPDU) end TLV 312. The LLDP message 300 may be an LLDPDU.

[0055] Chassis ID TLV 302, Port ID TLV 304, and Time to Live TLV 306 may be mandatory TLVs in LLDP message 300. Chassis ID TLV 302 may identify the device sending LLDP message 300 and may be a Type 1 mandatory TLV. In various examples, when LLDP message 300 is relayed by an intermediate node in a cluster network, chassis ID TLV 302 indicates the service node that generated LLDP message 300, rather than the intermediate node.

[0056] Port ID TLV 304 may identify the port that sent LLDP message 300 and may be a Type 2 mandatory TLV. In some examples, when LLDP message 300 is relayed by an intermediate node in a cluster network, Port ID TLV 304 indicates the service node that generated the LLDP message, rather than the port ID of the intermediate node.

[0057] Time to Live TLV 306 may identify how long a receiving device should consider the information in LLDP message 300 valid and may be a Type 3 mandatory TLV. In some cases, Time to Live TLV 306 remains the same when LLDP message 300 is relayed through the cluster network.

[0058] Both the discovery TLV 308 and the hop count TLV 310 are optional TLVs within the LLDP message 300. In some cases, the hop count TLV 310 may be omitted from the LLDP message 300. The discovery TLV 308 may indicate at least one of the location, type, or capability of the service node. The hop count TLV 310 may indicate the remaining number of hops that the LLDP message 300 should also traverse the cluster network. According to a specific example, one or both of the discovery TLV 308 and the hop count TLV 310 may be a type 127 custom TLV. For example, at least one of the discovery TLV 308 and the hop count TLV 310 may be an organization-specific type 127 TLV. In some cases, other optional TLVs may be included in the LLDP message 300. In some cases, one or both of the discovery TLV 308 and the hop count TLV 310 may be a reserved TLV (e.g., one of type 9-126).

[0059] The LLDPU End TLV 312 may indicate the end of the LLDPU frame structure. The LLDPU End TLV 312 may be a Type 0 TLV with a length of 0 and no value.

[0060] In various examples, LLDP message 300 may be generated and sent periodically by the service node. For example, LLDP message 300 may be sent every minute, every 30 seconds, every 20 seconds, every 10 seconds, every 5 seconds, every 2 seconds, etc.

[0061] Figure 4A An example of a discovery type-length-value (TLV) 400 in a link layer discovery protocol (LLDP) message generated by a service node is shown. In some cases, the LLDP message may be relayed by one or more intermediate nodes in a cluster network and received by a leaf node in a leaf-spine network.

[0062] The discovery TLV 400 may include at least one of the following three fields: a type field, a length field, and a value field. The type field includes a TLV type 402, which may be a 7-bit identifier of the type of data within the value field. In some embodiments, the TLV type 402 of the discovery TLV 400 is type 127, which refers to a custom TLV. However, in some cases, the TLV type 402 is one of types 9-126. Types 9-126 are reserved TLV types.

[0063] The length field includes a TLV length 404 that identifies the length of the value field. In various examples, the TLV length 404 is represented by a 9-bit value.

[0064] The value field may include service node identifier 406, service node location 408, service node type 410, and / or service node capabilities 412. In some cases, service node identifier 406, service node location 408, service node type 410, and / or service node capabilities 412 may be collectively represented by 0-511 octets.

[0065] Service node identifier 406 may indicate the identity of the service node. For example, service node identifier 406 may represent a domain name and / or a domain name system (DNS) name of the service node. In some cases, service node identifier 406 may include service node location 408.

[0066] Service node location 408 may indicate at least one location of a service node. For example, service node location 408 may represent an Internet Protocol (IP) address of the service node, a Media Access Control (MAC) address of the service node, a port number associated with the service node, etc. Service node location 408 may allow a discovery device (e.g., a network controller of a leaf-spine network) to enable communication with the service node.

[0067] Service node type 410 may indicate the type of the service node. For example, service node 410 may identify whether the service node is a server, a network switch, etc. In some cases, service node type 410 may indicate the provider of the service node.

[0068] Service node capabilities 412 may indicate at least one software or hardware capability of the service node. In some cases, service node capabilities 412 may indicate available memory capacity of the service node, processing power of the service node, an operating system running on the service node, and the like.

[0069] Figure 4BAnother example of a discovery type-length-value (TLV) 414 in a link layer discovery protocol (LLDP) message generated by a service node is shown. In some cases, the LLDP message may be relayed by one or more intermediate nodes in a cluster network and received by a leaf node in a leaf-spine network. The discovery TLV 414 may be a custom type 127 TLV. The discovery TLV 414 may include multiple fields: a type field, a length field, and a value field, the value field including an organization unique identifier, an organization defined subtype, and an organization defined information string.

[0070] The Type field includes a TLV Type 416, which may be a 7-bit identifier of the type of data within the Value field. Figure 4B In the embodiment shown in , the TLV type 416 of the discovery TLV 414 is type 127, which is a custom TLV.

[0071] The length field includes a TLV length 418 that identifies the length of the value field. That is, the TLV length 418 may represent the total length of the organization unique identifier, the organization defined subtype, and the organization defined information string. In various examples, the TLV length 418 is represented by a 9-bit value.

[0072] The organization unique identifier may specify identifier 420. Identifier 420 may identify an organization using its organization unique identifier (as defined in IEEE Std. 802-2001). Identifier 420 may have a length of 24 bits.

[0073] An organization-defined subtype may specify a subtype 422. The subtype 422 may identify a discovery TLV 414 among various TLVs used by the organization. In some cases, the subtype 422 may have a length of 8 bits.

[0074] The organization-defined information string may include a service node identifier 424, a service node location 426, a service node type 428, and / or a service node capability 430. In some cases, the service node identifier 424, the service node location 426, the service node type 428, and / or the service node capability 430 may be collectively represented by 0-507 octets.

[0075] Service node identifier 424 may indicate the identity of the service node. For example, service node identifier 424 may represent a domain name and / or a domain name system (DNS) name of the service node. In some cases, service node identifier 424 may include service node location 426.

[0076] Service node location 426 may indicate at least one location of a service node. For example, service node location 426 may represent an Internet Protocol (IP) address of the service node, a Media Access Control (MAC) address of the service node, a port number associated with the service node, etc. Service node location 426 may allow a discovery device (e.g., a network controller of a leaf-spine network) to enable communication with the service node.

[0077] Service node type 428 may indicate the type of the service node. For example, service node type 428 may identify whether the service node is a server, a network switch, etc. In some cases, service node type 428 may indicate the provider of the service node.

[0078] Service node capabilities 430 may indicate at least one software or hardware capability of the service node. In some cases, service node capabilities 430 may indicate available memory capacity of the service node, processing power of the service node, an operating system running on the service node, and the like.

[0079] Figure 5A An example of a hop count type-length-value (TLV) 500 in a link layer discovery protocol (LLDP) message generated by a service node is shown. In some cases, the LLDP message can be relayed by one or more intermediate nodes in a cluster network and received by a leaf node in a leaf-spine network. When an intermediate node relays the LLDP message, the intermediate node can modify the hop count TLV 500.

[0080] The hop count TLV 500 may include at least one of the following three fields: a type field, a length field, and a value field. The type field includes a TLV type 502, which may be a 7-bit identifier of the type of data in the value field. In some embodiments, the TLV type 502 of the hop count TLV 500 is type 127, which refers to a custom TLV. However, in some cases, the TLV type 502 is one of types 9-126. Types 9-126 are reserved TLV types.

[0081] The length field includes a TLV length 504 that identifies the length of the value field. In various examples, the TLV length 504 is represented by a 9-bit value.

[0082] The value field may include a count value 506. The count value 506 may represent the number of remaining hops that the LLDP message can still pass through the network. In some cases, the count value 506 may have an integer value in the range of 0 to 10. The count value 506 may be initialized by the service node. In some cases, the initial value of the count value 506 may depend on the number of layers within the cluster network. For example, the initial value of the count value 506 may be equal to or greater than the number of layers within the cluster network. In some examples, the count value 506 may be initialized to a value of 2 to 10. Each time an intermediate node relays an LLDP message in the cluster network, the count value 506 may be modified. In some cases, the relay intermediate node may reduce the count value 506 by 1 when receiving the LLDP message. In various embodiments, the count value 506 may be represented by 0-511 octets.

[0083] Figure 5B Another example of a hop count type-length-value (TLV) 508 in a link layer discovery protocol (LLDP) message generated by a service node is shown. In some cases, the LLDP message can be relayed by one or more intermediate nodes in the cluster network and received by a leaf node in the leaf-spine network. When the intermediate node relays the LLDP message, the intermediate node can modify the hop count TLV 508.

[0084] The hop count TLV 508 may include multiple fields: a type field, a length field, and a value field, the value field including an organization unique identifier field, an organization defined subtype field, and an organization defined information string field. The type field includes a TLV type 510, which may be a 7-bit identifier of the type of data in the value field. In some implementations, the TLV type 510 of the hop count TLV 508 is type 127, which refers to a custom TLV.

[0085] The length field includes a TLV length 512 that identifies the length of the value field. In various examples, the TLV length 512 is represented by a 9-bit value.

[0086] The organization unique identifier may specify identifier 514. Identifier 514 may identify the organization using its organization unique identifier (as defined in IEEE Std. 802-2001). Identifier 514 may have a length of 24 bits.

[0087] An organization-defined subtype may specify a subtype 516. The subtype 516 may identify the Hop Count TLV 508 among the various TLVs used by the organization. In some cases, the subtype 516 may have a length of 8 bits.

[0088] The information string field may include a count value 506. The count value 506 may represent the number of remaining hops that the LLDP message can still pass through the network. In some cases, the count value 506 may have an integer value in the range of 0 to 10. The count value 506 may be initialized by the service node. In some cases, the initial value of the count value 506 may depend on the number of layers within the cluster network. For example, the initial value of the count value 506 may be equal to or greater than the number of layers within the cluster network. In some examples, the count value 506 may be initialized to a value of 2 to 10. Each time an intermediate node relays an LLDP message in the cluster network, the count value 506 may be modified. In some cases, the relay intermediate node may reduce the count value 506 by 1 when receiving the LLDP message. In various embodiments, the count value 506 may be represented by 0-511 octets.

[0089] Figures 6 to 9 Various processes associated with embodiments of the present disclosure are shown.

[0090] Figure 6 An example process 600 for forwarding a link layer discovery protocol (LLDP) message is shown. In various embodiments, the process 600 may be performed by a service node (e.g., as described above with reference to FIG. Figure 1 described service node 114), intermediate nodes (eg, Figure 1 and Figure 2 any one of the intermediate nodes 112, 112-1, 112-2 and 112-3 described above) or the like to execute.

[0091] At 602, an LLDP message including a discovery type-length-value (TLV) is identified. In some examples where process 600 is performed by a service node in a cluster network, 602 may include generating an LLDP message with a discovery TLV. In various examples where process 600 is performed by an intermediate node in a cluster network, 602 may include receiving an LLDP message from a service node or another intermediate node in the cluster network.

[0092] The discovery TLV may be a specific TLV indicating information about the service node. In various embodiments, the discovery TLV may indicate at least one of a service node identifier, a service node location, a service node type, and service node capabilities. In some embodiments, the discovery TLV is a type 127 custom TLV. In some cases, the LLDP message may also include a hop count TLV.

[0093] At 604, the LLDP message including the discovery TLV is sent to the network node. In some implementations where process 600 is performed by an intermediate node, one or more elements in the LLDP message may be modified before the LLDP message is sent at 604. However, whether process 600 is performed by a service node, an intermediate node, etc., the discovery TLV may not be modified.

[0094] In various implementations, 602 and 604 may be repeated. For example, the service node may periodically generate LLDP messages with a discovery TLV. The intermediate node may periodically receive LLDP messages from the service node or from another intermediate node in the cluster network.

[0095] Figure 7 An example process 700 for relaying a Link Layer Discovery Protocol (LLDP) message is shown. In various implementations, process 700 may be performed by an intermediate node (e.g., Figure 1 and Figure 2 any one of the intermediate nodes 112, 112-1, 112-2 or 112-3 described above) or the like to execute.

[0096] At 702, an LLDP message is received from a first node. The LLDP message includes a hop count TLV. The first node may be a service node, an intermediate node, etc. in a cluster network. In various embodiments, the hop count TLV may be a specific TLV including a count value. The count value may specify an integer representing the number of remaining hops that the LLDP message may still pass through the cluster network. In some cases, the hop count TLV is a type 127 custom TLV.

[0097] In some cases, the LLDP message may also include a discovery TLV. The discovery TLV may be a specific TLV indicating information about a service node in a cluster network. In various embodiments, the discovery TLV may indicate at least one of a service node identifier, a service node location, a service node type, and service node capabilities. In some embodiments, the discovery TLV is a type 127 custom TLV.

[0098] At 704, the count value is modified. In some cases, the count value may be decremented by 1, which may represent the previous hop from the first node to the entity performing process 700.

[0099] At 706, it is confirmed that the count value is greater than a threshold. In some cases, the threshold is a predetermined integer, such as zero. If the count value is not greater than the threshold, the LLDP message can be discarded and not forwarded. However, if it is determined that the count value is greater than the threshold, the LLDP message can be forwarded to another node.

[0100] At 708, an LLDP message with the modified count value is sent to the second node. In some cases, the second node may be an intermediate node in a cluster network. In some cases, the second node may be a leaf node in a leaf-spine network.

[0101] Figure 8 An example process 800 is shown in which a node in a leaf-spine network can discover and / or confirm the presence of a service node in a cluster network connected to the leaf-spine network. In various embodiments, the process 800 can be performed by a leaf node (e.g., Figure 1 The leaf node 104-1, 104-2 or 104-3) described above is executed.

[0102] At 802, a link layer discovery protocol (LLDP) message identifying a service node in the cluster network is received from an intermediate node in the cluster network. The LLDP message may include a discovery type length value (TLV). The discovery TLV may be a specific TLV indicating information about a service node in the cluster network. In various embodiments, the discovery TLV may indicate at least one of a service node identifier, a service node location, a service node type, and a service node capability. In some embodiments, the discovery TLV is a type 127 custom TLV.

[0103] At 804, the service nodes in the cluster network are notified to the network controller. In some cases, the network controller is a software defined network (SDN) controller, which is connected to the entity performing process 800 through one or more interfaces. The network controller can be represented by software, hardware, or a combination thereof. In some cases, a data packet indicating the information in the discovery TLV can be sent to the network controller. However, in various embodiments, the entity (e.g., leaf node) performing process 800 can avoid forwarding the entire LLDP message to the network controller. For example, the data packet sent to the network controller can indicate at least one of a service node identifier, a service node location, a service node type, and a service node capability. In some cases, the data packet can be forwarded according to a proprietary packet-based mechanism and / or a control path mechanism. In some cases, the data packet can also identify the entity performing process 800. For example, if process 800 is performed by a leaf node, the data packet can identify the leaf node.

[0104] Fig. 9 An example process 900 is shown in which a network controller in a leaf-spine network can discover and monitor service nodes. In various embodiments, process 900 can be performed by a controller, such as the one described above with reference to Figure 1 A network controller 108 is described.

[0105] At 902, based on a first link layer discovery protocol (LLDP) message received by a leaf node in the leaf spine network, it is determined that the service node has joined the cluster network. In various embodiments, the entity performing process 900 may be part of the leaf spine network, connected to the leaf spine network, etc. After receiving the first LLDP message, the leaf node may send a message indicating the first LLDP message to the entity performing process 900. The message may indicate, for example, at least one of an identifier of the service node that generated the first LLDP message, the location of the service node, the type of the service node, and the capabilities of the service node. The message may also identify the leaf node. In some cases, the first LLDP message is generated by the service node in response to the service node being connected to a cluster network, which is connected to the leaf spine network. Therefore, the service node can be connected to the leaf spine network.

[0106] At 904, the service node is managed. In various embodiments, the entity performing process 900 can manage computing resources in the service node. For example, the entity can control, store, manage, extract or delete data in the computing resources. The computing resources may include virtual machine (VM) instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, network resources, etc. In some embodiments, the entity can communicate with the service node using a leaf node. In various examples, the service node can be managed by updating the network configuration of the leaf-spine network. For example, various virtual local area networks (VLANs) (or other network policies) can be activated on leaf nodes and / or intermediate nodes.

[0107] At 906, based on the second LLDP message received by the leaf node in the leaf-spine network, it is determined that the service node remains connected to the network. In various embodiments, the service node may periodically generate and send a second LLDP message in the event that the service node is connected to the leaf-spine network. Thus, the leaf node may receive multiple second LLDP messages indicating that the service node remains connected to the leaf-spine network. The leaf node may forward the message to the entity performing process 900, indicating that the service node remains connected to the leaf-spine network. Thus, process 900 may loop back to 904 so that the service node is managed as long as it is determined that the service node remains connected to the leaf-spine network.

[0108] Fig.10 is a computing system diagram illustrating a configuration of a data center 1000 that can be used to implement aspects of the technology disclosed herein. Fig.10The example data center 1000 shown in 1000 includes several server computers 1002A-1002C (which may be referred to herein as "server computer 1002" in the singular or "server computers 1002" in the plural) for providing computing resources 1004. In some examples, resources 1004 and / or server computers 1002 may include or correspond to service nodes (e.g., service nodes 114) described herein.

[0109] The server computer 1002 may be a standard tower, rack, or blade server computer that is appropriately configured to provide the computing resources described herein. The computing resources 1004 may be data processing resources, such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, network resources, and the like. Some or all of the server computers 1002 may also be configured to execute a resource manager that can instantiate and / or manage computing resources. In the case of a VM instance, for example, the resource manager may be a hypervisor or other type of program that is configured to be able to execute multiple VM instances on a single server computer 1002. The server computers 1002 in the data center 1000 may also be configured to provide network services and other types of services.

[0110] In the example data center 1000, an appropriate local area network (LAN) including a leaf-spine network 102 and switches 1006A-1006C is also used to interconnect the server computers 1002A-1002C. It should be understood that the configuration and network topology described herein have been greatly simplified, and that more computing systems, software components, networks, and network devices may be used to interconnect the various computing systems disclosed herein and provide the functionality described above. Appropriate load balancing devices or other types of network infrastructure components may also be used to balance the load between the data centers 1000, between the individual server computers 1002A-1002C in each data center 1000, and potentially between the computing resources in each server computer 1002. It should be understood that reference to Fig.10 The described configuration of data center 1000 is illustrative only, and other implementations may be used.

[0111] like Fig.10 As shown, some of the server computers 1002 (e.g., server computers 1002A and 1002B) can each execute a link layer discovery protocol (LLDP) generator 1008, which is configured to generate LLDP messages. Each LLDP message can include a discovery type-length-value (TLV) field and / or a hop count TLV field. The server computer 1002 can send the generated LLDP message to the switch 1006.

[0112] In addition, each switch 1006 can implement an LLDP repeater 1010. Using the LLDP repeater 1010, the switch 1006 can relay LLDP messages from the server computer 1002 to the leaf-spine network 102. In some cases, the switch 1006 can modify the hop count TLV field in each relayed LLDP message. The switches 1006 can also each include a buffer 1012. The buffer 1012 can be used to temporarily store data packets forwarded by the switch 1006 between the server computer 1002 and the leaf-spine network 102.

[0113] At least one of the server computers 1002 (e.g., server computer 1002C) may also execute a controller 1012. The controller 1012 may be responsible for managing the leaf-spine network 102 and / or the computing resources 1004 in the server computers 1002. When the leaf-spine network 102 receives an LLDP message generated by the server computer 1002 and forwarded by the switch 1006, the leaf-spine network 102 may forward the message to the server computer 1002C executing the controller 1012. The controller 1012 may discover and / or confirm the presence of the server computer 1002 by receiving the message from the leaf-spine network 102.

[0114] In some cases, computing resources 1004 may provide application containers, VM instances, storage devices, etc. permanently or on demand. Among other types of functions, computing resources 1004 may be used to implement the various services described above. Computing resources may include various types of computing resources, for example, data processing resources (such as application containers and VM instances), data storage resources, network resources, data communication resources, network services, etc.

[0115] Each type of computing resource 1004 may be general purpose or may be available in multiple specific configurations. For example, data processing resources may be used as physical computers or VM instances in a variety of different configurations. VM instances may be configured to execute applications, including network servers, application servers, media servers, database servers, some or all of the above network services, and / or other types of programs. Data storage resources may include file storage devices, block storage devices, etc. Data center 1000 may also be configured to provide other types of computing resources not specifically mentioned herein.

[0116] In one embodiment, computing resources 1004 may be enabled by one or more data centers 1000 (referred to herein as "data center 1000" in the singular or "data centers 1000" in the plural). A data center 1000 is a facility for housing and operating computer systems and associated components. A data center 1000 typically includes redundant and backup power, communications, cooling, and security systems. Data centers 1000 may also be located in geographically different locations.

[0117] Fig.11 An example computer architecture is shown for a computer 1100 capable of executing program components for implementing the functionality described above. Fig.11 The computer architecture shown in shows a conventional server computer, workstation, desktop computer, laptop computer, tablet computer, network device, e-reader, smart phone, network switch or other computing device, and can be used to execute any software components presented herein. In some examples, computer 1100 can correspond to a network node described herein (e.g., service node 114, intermediate node 112, leaf node 104, etc.).

[0118] The computer 1100 includes a baseboard 1102 or "motherboard," which is a printed circuit board to which multiple components or devices may be connected via a system bus or other electrical communication path. In one illustrative configuration, one or more central processing units ("CPUs") 1104 operate in conjunction with a chipset 1106. The CPU 1104 may be a standard programmable processor that performs the arithmetic and logic operations required for the operation of the computer 1100.

[0119] The CPU 1104 performs operations by switching from one discrete, physical state to the next by manipulating switch elements that distinguish and change these states. Switch elements typically include electronic circuits that maintain one of two binary states (e.g., flip-flops) and electronic circuits that provide output states based on logical combinations of the states of one or more other switch elements (e.g., logic gates). These basic switch elements can be combined to create more complex logic circuits, including registers, adder-subtractors, arithmetic logic units, floating point units, etc.

[0120] Chipset 1106 provides an interface between CPU 1104 and the remaining components and devices on substrate 1102. Chipset 1106 can provide an interface to RAM 1108, which is used as main memory in computer 1100. Chipset 1106 can also provide an interface to a computer-readable storage medium, such as read-only memory ("ROM") 1010 or non-volatile RAM ("NVRAM"), for storing basic routines that help start computer 1000 and transfer information between various components and devices. ROM 1110 or NVRAM can also store other software components required for the operation of computer 1100 according to the configuration described herein.

[0121] The computer 1100 can operate in a network environment using logical connections to remote computing devices and computer systems through a network (e.g., network 1108). Chipset 1106 may include functionality for providing network connectivity through a network interface controller (NIC) 1112 (e.g., a Gigabit Ethernet adapter). NIC 1112 is capable of connecting the computer 1100 to other computing devices through network 1108. It should be understood that multiple NICs 1112 may be present in the computer 1100 to connect the computer to other types of networks and remote computer systems. In some cases, NIC 1112 may include at least one ingress port and / or at least one egress port.

[0122] The computer 1100 may be connected to a storage device 1118 that provides non-volatile storage for the computer. The storage device 1118 may store an operating system 1120, programs 1122, and data that have been described in more detail herein. The storage device 1118 may be connected to the computer 1100 via a storage controller 1114 connected to the chipset 1106. The storage device 1118 may include one or more physical storage units. The storage controller 1114 may interface with the physical storage unit via a serial attached SCSI ("SAS") interface, a serial advanced technology connection ("SATA") interface, a fiber channel ("FC") interface, or other types of interfaces for physically connecting and transferring data between a computer and a physical storage unit.

[0123] The computer 1100 can store data on the storage device 1118 by converting the physical state of the physical storage unit to reflect the information being stored. In different embodiments of the present description, the specific conversion of the physical state can depend on various factors. Examples of such factors can include, but are not limited to: the technology used to implement the physical storage unit, whether the storage device 1118 is characterized as a primary storage device or a secondary storage device, etc.

[0124] For example, the computer 1100 can store information to the storage device 1118 by issuing instructions via the storage controller 1114 to change the magnetic properties of specific locations within the disk drive unit, the reflective or refractive properties of specific locations in the optical storage unit, or the electrical properties of specific capacitors, transistors, or other discrete components in the solid-state storage unit. Other transformations of the physical media are possible without departing from the scope and spirit of the present description, and the foregoing examples are provided only to facilitate the present description. The computer 1100 can also read information from the storage device 1118 by detecting the physical state or properties of one or more specific locations within the physical storage unit.

[0125] In addition to the mass storage device 1118 described above, the computer 1100 may also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It will be appreciated by those skilled in the art that a computer-readable storage medium is any available medium that provides non-transitory storage of data and can be accessed by the computer 1100. In some examples, operations performed by a leaf node (e.g., 104), a spine node (e.g., 106), a controller (e.g., a network controller 108), an intermediate node (e.g., 112), a service node (e.g., 114), a previous node (e.g., 202), a next node (e.g., 212), or a combination thereof may be supported by one or more devices similar to the computer 1100. In other words, some or all of the operations performed by a leaf node, a spine node, a controller, an intermediate node, a service node, a previous node, a next node, etc. may be performed by one or more computer devices 1100 running in a cloud-based arrangement.

[0126] By way of example and not limitation, computer-readable storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically erasable programmable ROM ("EEPROM"), flash memory or other solid-state storage technology, compact disk ROM ("CD-ROM"), digital versatile disk ("DVD"), high-definition DVD ("HD-DVD"), Blu-ray or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory manner.

[0127] As described above, the storage device 1118 may store an operating system 1120 for controlling the operation of the computer 1100. According to one embodiment, the operating system comprises a LINUX operating system. According to another embodiment, the operating system comprises Microsoft Corporation from Redmond, Washington. SERVER operating system. According to another embodiment, the operating system may include a UNIX operating system or one of its variants. It should be understood that other operating systems may also be used. Storage device 1118 may store other systems or applications and data used by computer 1100.

[0128] In one embodiment, storage device 1118 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into computer 1100, convert the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform computer 1100 by specifying how CPU 1104 transitions between states. According to one embodiment, computer 1100 can access a computer-readable storage medium storing computer-executable instructions that, when executed by computer 1100, perform the above-described Figures 1 to 10 The computer 1100 may also include a computer-readable storage medium having stored thereon instructions for performing any other computer-implemented operations described herein.

[0129] like Fig.11 As shown, the storage device 1118 also stores a link layer discovery protocol (LLDP) repeater 1124. In some embodiments, the LLDP repeater 1124 may be omitted. Using instructions stored in the LLDP repeater 1124, the CPU(s) 1104 may cause the computer 1100 to relay LLDP messages generated by the service node to the leaf nodes.

[0130] The computer 1100 may also include one or more input / output controllers 1116 for receiving and processing input from a plurality of input devices, such as a keyboard, a mouse, a touch pad, a touch screen, an electronic pen, or other types of input devices. Similarly, the input / output controller 1116 may provide output to a display, such as a computer monitor, a flat panel display, a digital projector, a printer, or other types of output devices. It will be appreciated that the computer 1100 may not include all of the Fig.11 Components shown in Fig.11 Other components explicitly shown in the Fig.11 A completely different architecture than the one shown in .

[0131] In summary, the present disclosure describes various methods, systems, and devices related to dynamic service node discovery in a network. In one example method, an intermediate node receives a Link Layer Discovery Protocol (LLDP) message from a first node. The LLDP message includes a discovery type-length-value (TLV), and the discovery TLV indicates the location of a service node in the network. The method also includes forwarding the LLDP message to a second node.

[0132] In some cases, one or more components may be referred to herein as being "configured to," "configurable to," "operable / capable of operating to," "suitable / capable of being adapted to," "capable of," "conforming / conforming to," etc. Those skilled in the art will recognize that, unless the context requires otherwise, these terms (e.g., "configured to") may generally encompass active state components and / or inactive state components and / or standby state components.

[0133] As used herein, the term "based on" may be used synonymously with "based at least in part on" and "based at least in part on."

[0134] As used herein, the terms "include / comprise / comprising" and "include / include / comprising" and their equivalents may be used interchangeably. An apparatus, system, or method "comprising A, B, and C" has A, B, and C, but may also have other components (e.g., D). That is, the apparatus, system, or method is not limited to components A, B, and C.

[0135] Although the present invention has been described with respect to specific examples, it should be understood that the scope of the present invention is not limited to these specific examples. Since other modifications and changes that vary to suit specific operating requirements and environments will be apparent to those skilled in the art, the present invention is not considered to be limited to the examples selected for disclosure purposes, but encompasses all changes and modifications that are not considered to depart from the true spirit and scope of the present invention.

[0136] Although the present application describes embodiments with specific structural features and / or methodological actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Rather, the specific features and actions only illustrate some embodiments that fall within the scope of the claims of the present application.

Claims

1. A method for network communication, comprising: Periodically receiving a Link Layer Discovery Protocol (LLDP) message from a first node in a network, the LLDP message comprising a discovery type-length-value TLV and a hop count TLV, the discovery TLV indicating an identifier of a service node in the network, and the hop count TLV comprising a count value; Decrementing the count value; determining that the decremented count value exceeds a predetermined level; as well as In response to the reduced count value exceeding the predetermined level, forwarding the LLDP message to a second node in the network, wherein the LLDP message is periodically generated and sent by the service node and is destined for a leaf node associated with a network controller used to manage the service node, and wherein the discovery TLV also includes at least one of the following items: the type of the service node, the current available memory capacity of the service node, and the processing capability of the service node.

2. The method according to claim 1, wherein: the discovery TLV is a type 127 TLV having a value indicating an identifier of the serving node, The hop count TLV is a type 127 TLV having a value including the count value.

3. The method according to claim 1, wherein: The first node is the service node.

4. The method according to claim 1, wherein: The second node is a leaf node in a leaf-spine network.

5. The method according to claim 1, wherein: At least one of the first node and the second node comprises an intermediate node in a cluster network.

6. The method according to claim 1, wherein: The identifier of the service node includes at least one of: an Internet Protocol (IP) address of the service node, a Media Access Control (MAC) address of the service node, and a Domain Name Service (DNS) name of the service node.

7. A service node, comprising: at least one processor; as well as a memory storing instructions that, when executed by the at least one processor, cause the processor to perform operations comprising: periodically generating a link layer discovery protocol LLDP message, the LLDP message comprising a discovery type-length-value TLV and a hop count TLV, the discovery TLV indicating an identifier of the service node, and the hop count TLV comprising a count value; and periodically sending the LLDP message to an intermediate node so that the intermediate node decrements the count value and forwards the LLDP message to a second node based on the decremented count value exceeding a predetermined level, wherein the LLDP message is destined for a leaf node associated with a network controller used to manage the service node, and wherein the discovery TLV also includes at least one of the following items: the type of the service node, the current available memory capacity of the service node, and the processing capability of the service node.

8. The service node according to claim 7, wherein: The operations also include: connected to the intermediate node, Wherein, the LLDP message is sent in response to connecting to the intermediate node.

9. The service node according to claim 7, wherein: the discovery TLV is a type 127 TLV having a value indicating an address of the service node, The hop count TLV is a type 127 TLV having a value including the count value.

10. The service node according to any one of claims 7 to 9, wherein: The identifier of the service node includes at least one of: an Internet Protocol (IP) address of the service node, a Media Access Control (MAC) address of the service node, and a Domain Name Service (DNS) name of the service node.

11. An intermediate node in a cluster network, the intermediate node comprising: at least one processor; as well as a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations comprising: Periodically receiving a link layer discovery protocol LLDP message from a previous node in the cluster network, the LLDP message comprising a discovery type-length-value TLV and a hop count TLV, the discovery TLV comprising an identifier of a service node in the cluster network, and the hop count TLV comprising a count value; Decrease the count value in the hop count TLV; In response to decrementing the count value, confirming that the count value is greater than zero; and In response to the count value being greater than zero, forwarding the LLDP message to at least one next node, wherein the LLDP message is periodically generated and sent by the service node and is destined for a leaf node associated with a network controller used to manage the service node, and wherein the discovery TLV also includes at least one of the following items: the type of the service node, the current available memory capacity of the service node, and the processing capability of the service node.

12. The intermediate node according to claim 11, wherein: The previous node in the cluster network is the service node or another intermediate node in the cluster network.

13. The intermediate node according to claim 11 or 12, wherein: The at least one next node includes at least one of: another intermediate node in the cluster network, and a leaf node in a leaf-spine network.

14. The intermediate node according to claim 11 or 12, wherein: The intermediate node is arranged between the previous node in the cluster network and the leaf node in the leaf-spine network.

15. An intermediate node, comprising: Means for periodically receiving a Link Layer Discovery Protocol (LLDP) message from a first node in a network, wherein the LLDP message comprises a discovery type-length-value TLV and a hop count TLV, the discovery TLV indicating an identifier of a service node in the network, and the hop count TLV comprising a count value; means for decreasing the count value in the hop count TLV; means for determining that the decremented count value exceeds a predetermined level; and means for forwarding the LLDP message to a second node in the network in response to the decremented count value exceeding the predetermined level, wherein the LLDP message is periodically generated and sent by the service node and is destined for a leaf node associated with a network controller used to manage the service node, and wherein the discovery TLV also includes at least one of the following items: the type of the service node, the current available memory capacity of the service node, and the processing capability of the service node.

16. A service node, comprising: Means for periodically generating a Link Layer Discovery Protocol (LLDP) message, wherein the LLDP message comprises a discovery type-length-value TLV and a hop count TLV, the discovery TLV indicating an identifier of the service node, and the hop count TLV comprising a count value; and means for periodically sending the LLDP message to an intermediate node so that the intermediate node decrements the count value and forwards the LLDP message to a second node based on the decremented count value exceeding a predetermined level, wherein the LLDP message is destined for a leaf node associated with a network controller used to manage the service node, and wherein the discovery TLV also includes at least one of the following items: the type of the service node, the current available memory capacity of the service node, and the processing capability of the service node.

17. A method for network communication, comprising: Periodically generating a link layer discovery protocol LLDP message, the LLDP message including a discovery type-length-value TLV and a hop count TLV, the discovery TLV indicating an identifier of a service node, and the hop count TLV including a count value; as well as periodically sending the LLDP message to an intermediate node so that the intermediate node decrements the count value and forwards the LLDP message to a next node based on the decremented count value exceeding a predetermined level, wherein the LLDP message is destined for a leaf node associated with a network controller used to manage the service node, and wherein the discovery TLV also includes at least one of the following items: the type of the service node, the current available memory capacity of the service node, and the processing capability of the service node.

18. The method according to claim 17, further comprising: connected to the intermediate node, Wherein, the LLDP message is sent in response to connecting to the intermediate node.

19. A computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method of any one of claims 1 to 6, 17 and 18.

Images