Patent Description:
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. Devices in many modern data center environments are arranged according to a spine-leaf configuration. A spine-leaf network can include two layers: a spine layer and a leaf layer. The spine layer can include one or more top-tier switches. The leaf layer can include multiple lower-tier switches connected to the top-tier switches in a fully interconnected mesh topology. The lower-tier switches can be connected to host servers with various computer resources that can be utilized for various purposes, such as to host tenants, host Virtual Machines (VMs), store data, perform computations, and the like. Due to the interconnectivity within the spine layer and the leaf layer, data packets transmitted between devices within the network are transmitted through the same number of nodes and interfaces. Accordingly, data traffic can travel with a consistent speed and latency through a spine-leaf network.

Computing resources of host servers can be controlled and managed by a central controller connected to the spine-leaf network. The central controller can be a software-defined network controller that can manage, configure, and enable communication between devices in the network. For instance, the central controller may manage the lower-tier switches and top-tier switches within the spine-leaf network and may also enable communication between host servers connected to the lower-tier switches.

When a new host server joins the network, the central controller must discover the server before it can manage the resources in the host server and enable communication to and from the host server. In various networks, a lower-tier switch can transmit Link Layer Discovery Protocol (LLDP) messages toward host servers connected to the lower-tier switch. Once the host servers receive the LLDP messages, the host servers may be aware of the lower-tier switch. The host servers, however, may be unable to directly communicate with the central controller. Accordingly, some networks require an additional resource controller to receive messages from the host servers indicating their connectivity, and the network controller may have to separately query the resource controller to separately report the connectivity of the host servers to the network controller. In addition, LLDP messages are generally designed to only travel a single hop in a network. Accordingly, if any nodes are present between a lower-tier switch and a host server, the host server may be unable to receive an LLDP message directly from its closest lower-tier switch.

<CIT> discloses a method for monitoring traffic in a network. The method is used in a communication device, wherein the network is formed by switches and hosts. The method includes: collecting LLDP information, VLAN information, host NIC information and host-tenant mapping information to obtain a physical network topology and a plurality of virtual network topologies; detecting a plurality of physical link loads of the physical network topology; obtaining a target path between two of the hosts or between the switches by analyzing the virtual network topologies; selecting one of the switches on the target path to serve as a mirror switch according to the physical link load corresponding to the target path or a hop count; and receiving mirror traffic transmitted from the mirror switch, and performing packet payload analysis on the mirror traffic. <CIT> discloses a system for remotely monitoring and/or controlling a plurality of power distribution units and/or sensor units in a data centre The system comprises, in each one of the power distribution units and/or sensor units, a switch having three external Ethernet ports, and a daisy chain network comprising the power distribution units and/or sensor units as nodes. The switch inspects, in an incoming data packet a destination node, identification field contained in a layer higher than or equal to the Ethernet/IP layer in order to decide to switch the incoming data packet to the internal Ethernet port, or to the next node in the daisy chain via an external Ethernet port.

Various implementations of the present disclosure relate to service node-generated Link Layer Discovery Protocol (LLDP) messages for dynamic discovery of service nodes in a network. Particular implementations enable dynamic discovery of the service nodes by a network controller associated with a spine-leaf network, without the assistance of a third-party resource controller.

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

In particular implementations, a service node is configured to generate and transmit an LLDP message. The LLDP message may include a "discovery" Type-Length-Value (TLV), which can identify the service node, indicate how the service node is connected to the network, specify capabilities of the service node, or the like. When the LLDP message is received by a leaf node in a spine-leaf network, the leaf node can advertise the service node to a network controller within the spine-leaf network. Accordingly, the LLDP message can enable the network controller to efficiently identify when the service node connects to the spine-leaf network. In some cases in which the service node periodically transmits the LLDP message, the network controller can also use the LLDP message as a health check to identify whether the service node remains connected to the network.

In certain implementations, one or more intermediary nodes may be present between the service node and the leaf node. These intermediary nodes may be configured to relay LLDP messages from the service node to the leaf node. The LLDP messages may also include a "hopcount" TLV (also referred to as a "RelayHopCount" TLV). A hopcount TLV in a particular LLDP message can specify a counter that can be modified each time an intermediary node relays the LLDP message. When the counter in the hopcount TLV reaches a particular number (e.g., zero), the intermediary node may refrain from relaying the LLDP to another network node. Accordingly, the hopcount TLV may prevent service node-generated LLDP messages from being relayed indefinitely by intermediary nodes.

Implementations of the present disclosure can provide various improvements to computer networks. When a spine-leaf network relies on LLDP messages generated by the leaf nodes toward the service nodes to discover the service nodes, a network controller associated with the spine-leaf network may have to rely on a resource controller to ascertain the presence of the service nodes. The resource controller may be external to the network fabric and/or be managed by a third party. However, in particular implementations described herein, service node-generated LLDP messages can be used to notify leaf nodes of the presence of service nodes in the network, thereby eliminating the need for a resource controller to discover service nodes in the network.

Various implementations of the present disclosure will now be described with reference to the accompanying figures.

<FIG> illustrates an example environment <NUM> for implementing service node discovery and monitoring. As illustrated, the environment includes a spine-leaf network <NUM>. The spine-leaf network includes multiple leaf nodes <NUM>-<NUM> to <NUM>-<NUM> connected to multiple spine nodes <NUM>-<NUM> and <NUM>-<NUM>. As used herein, the terms "node," "network node," and their equivalents, can refer to any entity within a network that can transmit packets to and/or receive packets from at least one other node. A node may be a device, a software instance, a Virtual Machine (VM), a network switch, or the like. In some examples, a node can be a client, a server, or a combination thereof. In various examples, each of the multiple leaf nodes <NUM>-<NUM> to <NUM>-<NUM> may be lower-tier network switches, and each of the multiple spine-nodes <NUM>-<NUM> and <NUM>-<NUM> may be upper-tier network switches. As used herein, the term "network switch" can refer to a multiport network bridge configured to receive data, process the data, and selectively forward data to another device connected to the network switch. As used herein, the term "tier" can refer to multiple network nodes that are connected to other nodes within a network but are not directly interconnected to each other. Thus, the leaf nodes <NUM>-<NUM> to <NUM>-<NUM> are part of a tier (e.g., a lower tier or leaf tier) and the spine nodes <NUM>-<NUM> and <NUM>-<NUM> are part of a tier (e.g., an upper tier or a spine tier) within the spine-leaf network <NUM>.

Each one of the leaf nodes <NUM>-<NUM> to <NUM>-<NUM> is connected to every one of the spine nodes <NUM>-<NUM> to <NUM>-<NUM> via network interfaces. As used herein, the terms "interface," "link," and their equivalents, can refer to a connection between two nodes in a network. In some cases, an interface may directly connect the two nodes and/or may omit any interceding nodes. An interface may be connected to a first port of a first device and to a second port of a second device. In some cases, an interface between two nodes can be a wired interface, such that data can be transmitted as a signal conducted through a solid medium (e.g., an Ethernet cable, a fiber-optic cable, etc.) connecting the two nodes. In some examples, an interface between nodes can be a wireless interface, such that a packet can 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 <NUM>-<NUM> to <NUM>-<NUM> and one of the spine nodes <NUM>-<NUM> and <NUM>-<NUM>) may interconnect two ports. As used herein, the term "port," and its equivalents, can 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 according to its port number. Although <FIG> illustrates three leaf nodes <NUM>-<NUM> to <NUM>-<NUM> and two spine nodes <NUM>-<NUM> and <NUM>-<NUM>, implementations are not so limited. Additional leaf nodes and/or spine nodes can be included in the spine leaf network <NUM>. However, regardless of the number of leaf nodes and/or spine nodes, each leaf node within the spine-leaf network may be directly connected to all of the spine nodes within the spine-leaf network.

In various implementations, a network controller <NUM> (also referred to as a "network fabric controller," "fabric controller," or equivalent) may be configured to manage communication within the spine-leaf network <NUM>. The network controller <NUM> may be connected to any of the leaf nodes <NUM>-<NUM> to <NUM>-<NUM> and/or any of the spine nodes <NUM>-<NUM> and <NUM>-<NUM>. In various implementations, the network controller <NUM> and the spine leaf network <NUM> may be part of an internal network with a common security policy. The network controller <NUM> may be configured to directly connect any of the nodes within the spine-leaf network <NUM>. The network controller <NUM> may also be configured to manage at least some elements of cluster networks connected to the leaf nodes <NUM>-<NUM> to <NUM>-<NUM>, such as cluster network <NUM>. The internal control <NUM> may be configured to control various nodes within a datacenter fabric including the spine-leaf network <NUM> and any nodes connected to the spine-leaf network <NUM>.

Cluster network <NUM> can include a service node <NUM> and multiple intermediary nodes <NUM>-<NUM> to <NUM>-<NUM>. As used herein, the term "cluster network" can refer to one or more service nodes connected to at least one leaf node in a spine-leaf network. In some examples, such as the cluster network <NUM> illustrated in <FIG>, a cluster network can include one or more intermediary nodes interconnecting the service node(s) and the leaf node(s). As used herein, the terms "service node," "extended leaf node," "initiator," and their equivalents, can refer to a network node in a cluster network that is configured to store, generate, and/or process data. According to various implementations, the spine-leaf network <NUM> and the cluster network <NUM> can be considered part of the same network or network fabric. In some cases, a service node, such as the service node <NUM>, can include one or more computing resources (e.g., memory, processing capabilities, etc.) that can be used to host a tenant, Virtual Machine (VM), or the like. For instance, a service node can be a server.

As used herein, the terms "intermediary node,'' "relayer," and their equivalents can refer to a network node in a cluster network that is configured to receive data and transmit data to other nodes in the network. An example of an intermediary node can be a Top of Rack (ToR) switch. In particular implementations, an intermediary node can be connected to a single leaf node. For instance, as illustrated in <FIG>, a first intermediary node <NUM>-<NUM> is directly connected to a first leaf node <NUM>-<NUM>. In certain implementations, an intermediary node can be connected to multiple (e.g., one or two) leaf nodes. For instance, as illustrated in <FIG>, a second intermediary node <NUM>-<NUM> is connected to both the first leaf node <NUM>-<NUM> and a second leaf node <NUM>-<NUM>. An intermediary node can be connected to one or more service nodes. For instance, a third intermediary node <NUM>-<NUM> illustrated in <FIG> is connected to the service node <NUM>. In some cases, an intermediary node can be connected to other intermediary nodes. For instance, the third intermediary node <NUM>-<NUM> is connected to both the first intermediary node <NUM>-<NUM> and the second intermediary node <NUM>-<NUM> in an uplink direction. Similarly, each one of the first intermediary node <NUM>-<NUM> and the second intermediary node <NUM>-<NUM> is connected to the third intermediary node <NUM>-<NUM> in a downlink direction. As used herein, the term "uplink" can refer to a direction of interfaces and/or data transmission that extends toward spine nodes in a spine leaf network (e.g., toward the spine nodes <NUM>-<NUM> to <NUM>-<NUM> in the spine-leaf network <NUM>) and that is opposite to a downlink direction. As used herein, the term "downlink" can refer to a direction of interfaces and/or data transmission that extends toward a service node in a cluster network (e.g., toward the service node <NUM> in the cluster network <NUM>) and that is opposite to an uplink direction.

The intermediary nodes <NUM>-<NUM> to <NUM>-<NUM> may be arranged in one or more tiers in the cluster network <NUM>. For instance, the first and second intermediary nodes <NUM>-<NUM> and <NUM>-<NUM> may be part of a first tier and the third intermediary node <NUM>-<NUM> may be part of a second tier. Although only two tiers of intermediary nodes are illustrated in <FIG>, in various implementations, greater or fewer tiers may be included in the cluster network <NUM>. In addition, although only three intermediary nodes <NUM>-<NUM> to <NUM>-<NUM> are illustrated in <FIG>, greater or fewer intermediary nodes can be included in the cluster network <NUM> in various implementations.

In some implementations, the network controller <NUM> may be enabled to remotely manage computing resources in the service node <NUM>. However, the network controller <NUM> may be unable to manage the intermediary nodes <NUM>-<NUM> to <NUM>-<NUM>. The cluster network <NUM> may be an external network. In some cases, although not illustrated in <FIG>, one or more firewalls may be disposed between the intermediary nodes <NUM>-<NUM> to <NUM>-<NUM> and the leaf nodes <NUM>-<NUM> and <NUM>-<NUM>, or within the leaf nodes <NUM>-<NUM> to <NUM>-<NUM> themselves, thereby protecting the internal network from external security threats, such as from the cluster network <NUM>.

The service node <NUM> may join the cluster network <NUM> by connecting to at least one of the intermediary nodes in the cluster network <NUM>, such as the third intermediary network <NUM>-<NUM>. Once the service node <NUM> is connected to the cluster network <NUM>, the service node <NUM> may begin transmitting at least one Link Layer Discovery Protocol (LLDP) message <NUM> toward the spine-leaf network <NUM>. The LLDP message <NUM> can be an LLDP frame with one or more custom Type-Length-Value (TLV) fields that enable discovery of the service node <NUM>. For instance, the LLDP message <NUM> may include a discovery TLV and/or a hopcount TLV, examples of which are described below in further detail with respect to <FIG>.

In various implementations of the present disclosure, intermediary nodes within the cluster network <NUM> may receive the LLDP message <NUM> from the service node <NUM>. For instance, the third intermediary node <NUM>-<NUM> may initially receive the LLDP message <NUM> transmitted from the service node <NUM>. In general, LLDP messages are only transmitted one hop in a network, i.e., across a single interface from one node to another node. However, in various implementations described herein, the third intermediary node <NUM>-<NUM> may be configured to relay the LLDP message <NUM> to at least one other node in the network. For instance, the third intermediary node <NUM>-<NUM> may re-transmit the LLDP message <NUM> to both the first intermediary node <NUM>-<NUM> and the second intermediary node <NUM>-<NUM> in the uplink direction. Similarly, upon receiving the LLDP message <NUM>, the first intermediary node <NUM>-<NUM> and the second intermediary node <NUM>-<NUM> may each relay the LLDP message <NUM> to another network node in the uplink direction. The LLDP message <NUM> from the service node <NUM> may thereby travel through the cluster network <NUM> and may be received by at least one leaf node in the spine leaf network <NUM>. With reference to <FIG>, the first leaf node <NUM>-<NUM> may receive the LLDP message <NUM> from the first intermediary node <NUM>-<NUM> and/or the second intermediary node <NUM>-<NUM> and the second leaf node <NUM>-<NUM> may receive the LLDP message <NUM> from the second intermediary node <NUM>-<NUM>. Accordingly, the first leaf node <NUM>-<NUM> and/or the second leaf node <NUM>-<NUM> in the spine leaf network <NUM> can identify the presence of the service node <NUM>.

Once the first leaf node <NUM>-<NUM> and/or the second leaf node <NUM>-<NUM> identifies the presence of the service node <NUM>, the first leaf node <NUM>-<NUM> and/or the second leaf node <NUM>-<NUM> may report the presence of the service node <NUM> to the network controller <NUM>. In various implementations, the first leaf node <NUM>-<NUM> and/or the second leaf node <NUM>-<NUM> may refrain from relaying the LLDP message <NUM> to other nodes in the spine-leaf network <NUM>. For instance, if the first leaf node <NUM>-<NUM> receives the LLDP message <NUM>, the first leaf node <NUM>-<NUM> may refrain from forwarding the LLDP message <NUM> to the first spine node <NUM>-<NUM> and the second spine node <NUM>-<NUM>. The network controller <NUM> can therefore manage and/or monitor the service node <NUM>.

The LLDP message <NUM> can be used for both discovery of the service node <NUM> as well as for ongoing monitoring of the connectivity of the service node <NUM>. For instance, an initial LLDP message <NUM> that the service node <NUM> transmits through the cluster network <NUM> to the spine-leaf network <NUM> can be used by the controller <NUM> to discover the service node <NUM>. Subsequently, the service node <NUM> may periodically transmit additional LLDP messages <NUM> through the cluster network <NUM> to the spine-leaf network <NUM>. These additional LLDP messages <NUM> can be used by the controller <NUM> to identify that the service node <NUM> remains connected to the cluster network <NUM>. If the controller <NUM> identifies that the periodic LLDP messages <NUM> are interrupted and/or delayed, the controller <NUM> may identify that there is an interruption in the connectivity of the cluster network <NUM> and/or the service node <NUM>. In some cases, the controller <NUM> may balance a load on the service node <NUM> to another service node connected to the spine leaf network <NUM>. In certain examples, the controller <NUM> may notify a user or central administrator that there is a problem with the service node <NUM>.

As illustrated, the environment <NUM> may be associated with Layer <NUM> (L2) network devices and Layer <NUM> (L3) network devices. The elements of the cluster network <NUM> (e.g., the intermediary nodes <NUM>-<NUM> to <NUM>-<NUM> and the service node <NUM>) may be L2 network devices. For instance, the intermediary nodes <NUM>-<NUM> to <NUM>-<NUM> can include L2 network devices, such as network bridges that are configured to process and forward data at the L2 layer. In some cases, the intermediary nodes <NUM>-<NUM> to <NUM>-<NUM> forward data packets between devices according to hardware addresses, Media Access Control (MAC) addresses, or the like, indicated by the data packets. The elements of the spine-leaf network <NUM> (e.g., the leaf nodes <NUM>-<NUM> to <NUM>-<NUM> and/or the spine nodes <NUM>-<NUM> to <NUM>-<NUM>) may be L3 network devices. In some cases, the elements of the spine-leaf network <NUM> may support routing functionality. In various implementations, the leaf nodes <NUM>-<NUM> to <NUM>-<NUM> may be multilayer switches configured to interconnect L2 and L3.

According to various implementations of the present disclosure, the network controller <NUM> may be empowered to directly discover and/or monitor the presence of the service node <NUM> without separately querying another device (e.g., a resource controller connected to the service node <NUM>). Thus, the network controller <NUM> may be able to efficiently manage computing resources within the service node <NUM>.

<FIG> illustrates example signaling <NUM> associated with an intermediary node <NUM>, such as one of the intermediary nodes <NUM>-<NUM> to <NUM>-<NUM> described above with reference to <FIG>. The signaling <NUM> relates to the relaying of a Link Layer Discovery Protocol (LLDP) message, such as the LLDP message <NUM>, by the intermediary node <NUM>. The intermediary node <NUM> may be part of a cluster network, such as the cluster network <NUM> described above with reference to <FIG>.

As illustrated, the intermediary node <NUM> receives the LLDP message <NUM> from a previous node <NUM>. The intermediary node <NUM> is located in an uplink direction with respect to the previous node <NUM>. In various examples, the previous node <NUM> can be another intermediary node or a service node. If the previous node <NUM> is an intermediary node, the previous node <NUM> is located between the intermediary node <NUM> and the service node.

The LLDP message <NUM> may include at least two Type-Length-Value (TLV) fields: a discovery TLV <NUM> and a hopcount TLV. The discovery TLV <NUM> indicates various information about the service node from which the LLDP message <NUM> originated. In some cases, a value of the discovery TLV <NUM> can indicate at least one of a location of the service node, a type of the service node, or a capability of the service node. The discovery TLV <NUM> includes information that enables a network controller (e.g., the network controller <NUM> described above with reference to <FIG>) to discover, monitor, and/or manage computing resources in the service node.

A value of the hopcount TLV <NUM> may include a counter indicating a number of remaining hops that the LLDP message <NUM> is designed to traverse through the cluster network. As received by the intermediary node <NUM>, the hopcount TLV <NUM> includes a counter value n-<NUM><NUM>. The counter may be initialized by the service node. In examples in which the previous node <NUM> is the service node, the counter value n-<NUM><NUM> may be an initial counter value. Some examples of the initial counter value can be a value ranging from <NUM> to <NUM>, although implementations are not limited to these values. In some cases, the initial counter value is set based on the number of tiers in the cluster network. For instance, if the cluster network is a two-tier network, the initial counter value may be initialized at <NUM>, to ensure that the LLDP message <NUM> is forwarded to at least one leaf node connected to the cluster network.

Upon receiving the LLDP message <NUM>, the intermediary node <NUM> may generate a counter value n <NUM> based on the counter value n-<NUM><NUM>. In some cases, the counter value n <NUM> is calculated according to the following Formula <NUM>: <MAT> wherein Vn is counter value n <NUM> and Vn-<NUM> is counter value n-<NUM><NUM>. In other words, the intermediary node <NUM> may increment the counter value n-<NUM><NUM> down by one to generate the counter value n <NUM>.

In various implementations, the intermediary node <NUM> may determine whether the counter value n <NUM> is above a particular threshold. In some cases, the threshold may be <NUM>, but implementations are not so limited. If the intermediary node <NUM> determines that the counter value n <NUM> is equal to or less than the threshold, the intermediary node <NUM> may refrain from forwarding the LLDP message <NUM> to the next node. However, if the intermediary node <NUM> determines that the counter value n <NUM> is greater than the threshold, the intermediary node <NUM> may replace the counter value n-<NUM><NUM> in the hopcount TLV <NUM> with the counter value n <NUM> and forward the LLDP message <NUM> (with the counter value n <NUM>) to a next node <NUM>.

The next node <NUM> may be another intermediary node in the cluster network or a leaf node (e.g., leaf node <NUM>-<NUM> or <NUM>-<NUM>) in a spine-leaf network (e.g., spine-leaf network <NUM>). In examples in which the next node <NUM> is another intermediary node, the next node <NUM> may update the hopcount TLV <NUM> similarly to intermediary node <NUM>, check whether the updated hopcount TLV <NUM> indicates that the LLDP message <NUM> should be forwarded, and forward or refrain from forwarding the LLDP message <NUM> along to another node.

In instances in which the next node <NUM> is a leaf node, the leaf node may at least partially forward the LLDP message <NUM> to a network controller (e.g., network controller <NUM>) of the spine-leaf network. According to some examples, the leaf node may refrain from forwarding the entire LLDP message <NUM>. However, in some cases, the leaf node may forward, to the network controller, information based at least on the value of the discovery TLV <NUM>. For instance, the leaf node may forward at least one of a location of the service node, a type of the service node, or a capability of the service node to the network controller. The network controller may use the information in the value of the discovery TLV <NUM> 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.

According to various implementations, the relaying of the LLDP message <NUM> by the intermediary node <NUM> can enable the spine-leaf network to discover and/or confirm the presence of the service node in the network. In addition, the process of modifying the hopcount TLV <NUM>, confirming that the value of the hopcount TLV <NUM> is above a particular threshold, and forwarding the LLDP message <NUM> with the modified hopcount TLV <NUM> ensures that the LLDP message <NUM> is not forwarded indefinitely between intermediary nodes within the cluster network.

<FIG> illustrates an example of a Link Layer Discovery Protocol (LLDP) message <NUM>. The LLDP message <NUM> may be generated and transmitted by a service node and/or relayed by an intermediary node in a cluster network. As illustrated, the LLDP message <NUM> can include a chassis Identification (ID) Type-Length-Value (TLV), <NUM>, a port ID TLV <NUM>, a time to live TLV <NUM>, a discovery TLV <NUM>, a hopcount TLV <NUM>, and an end of LLDP Data Unit (LLDPDU) TLV <NUM>. The LLDP message <NUM> may be an LLDPDU.

The chassis ID TLV <NUM>, the port ID TLV <NUM>, and the time to live TLV <NUM> may be mandatory TLVs in the LLDP message <NUM>. The chassis ID TLV <NUM> may identify the device transmitting the LLDP message <NUM> and may be a Type <NUM> mandatory TLV. In various examples, when the LLDP message <NUM> is relayed by an intermediary node in the cluster network, the chassis ID TLV <NUM> represents the service node that generated the LLDP message <NUM>, rather than the intermediary node.

The Port ID TLV <NUM> may identify the port from which the LLDP message <NUM> is transmitted and may be a Type <NUM> mandatory TLV. In some examples, when the LLDP message <NUM> is relayed by an intermediary node in the cluster network, the port ID TLV <NUM> represents the service node that generated the LLDP message, rather than a port ID of the intermediary node.

The time to live TLV <NUM> may identify how long the receiving device should consider the information in the LLDP message <NUM> valid and may be a Type <NUM> mandatory TLV. In some cases, the time to live TLV <NUM> remains the same as the LLDP message <NUM> is relayed through the cluster network.

The discovery TLV <NUM> and the hopcount TLV <NUM> are each optional TLVs within the LLDP message <NUM>. In some cases, the hopcount TLV <NUM> can be omitted from the LLDP message <NUM>. The discovery TLV <NUM> may indicate at least one of a location, a type, or a capability of the service node. The hopcount TLV <NUM> may indicate how many remaining hops through a cluster network the LLDP message <NUM> should traverse. According to particular examples, one or both of the discovery TLV <NUM> and the hopcount TLV <NUM> can be a Type <NUM> custom TLV. For instance, at least one of the discovery TLV <NUM> or the hopcount TLV <NUM> may be an organizationally specific Type <NUM> TLV. In some cases, other optional TLVs may be included within the LLDP message <NUM>. In some cases, one or both of the discovery TLV <NUM> and the hopcount TLV <NUM> can be a reserved TLV (e.g., one of Types <NUM>-<NUM>).

The end of LLDPU TLV <NUM> may indicate the end of the LLDPU frame structure. The end of LLDPU TLV <NUM> may be a Type <NUM> TLV with a length of <NUM> and no value.

In various examples, the LLDP message <NUM> can be generated and transmitted periodically by the service node. For instance, the LLDP message <NUM> may be transmitted every minute, every <NUM> seconds, every <NUM> seconds, every <NUM> seconds, every <NUM> seconds, every <NUM> seconds, or the like.

<FIG> illustrates an example of a discovery Type-Length-Value (TLV) <NUM> in a Link Layer Discovery Protocol (LLDP) message that is generated by a service node. In some cases, the LLDP message can be relayed through one or more intermediary nodes in a cluster network and received by a leaf node in a spine-leaf network.

The discovery TLV <NUM> can include at least one of three fields: a type field, a length field, and a value field. The type field includes a TLV type <NUM>, which may be <NUM>-bit identifier of the type of data within the value field. In some implementations, the TLV type <NUM> of the discovery TLV <NUM> is type <NUM>, which refers to a custom TLV. However, in some cases, the TLV type <NUM> is one of types <NUM>-<NUM>. Types <NUM>-<NUM> are reserved TLV types.

The length field includes a TLV length <NUM> that identifies the length of the value field. In various examples, the TLV length <NUM> is represented by a <NUM>-bit value.

The value field may include a service node identifier <NUM>, a service node location <NUM>, a service node type <NUM>, and/or a service node capability <NUM>. In some cases, the service node identifier <NUM>, the service node location <NUM>, the service node type <NUM>, and/or the service node capability <NUM> may be collectively represented by <NUM>-<NUM> octets.

The service node identifier <NUM> may indicate an identity of the service node. For example, the service node identifier <NUM> may represent a domain name and/or Domain Name System (DNS) name of the service node. In some cases, the service node identifier <NUM> may include the service node location <NUM>.

The service node location <NUM> may indicate at least one location of the service node. For instance, the service node location <NUM> 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, or the like. The service node location <NUM> may allow a discovering device (e.g., a network controller of the spine-leaf network) to enable communications with the service node.

The service node type <NUM> may indicate a type of the service node. For instance, the service node <NUM> may identify whether the service node is a server, a network switch, or the like. In some cases, the service node type <NUM> may indicate a vendor of the service node.

The service node capability <NUM> may indicate at least one software or hardware capability of the service node. In some cases, the service node capability <NUM> can indicate an available memory capacity of the service node, a processing capability of the service node, an operating system running on the service node, or the like.

<FIG> illustrates another example of a discovery Type-Length-Value (TLV) <NUM> in a Link Layer Discovery Protocol (LLDP) message that is generated by a service node. In some cases, the LLDP message can be relayed through one or more intermediary nodes in a cluster network and received by a leaf node in a spine-leaf network. The discovery TLV <NUM> may be a custom type <NUM> TLV. The discovery TLV <NUM> can include multiple fields: a type field, a length field, and a value field that comprises an organizationally unique identifier, an organizationally defined subtype, and an organizationally defined information string.

The type field includes a TLV type <NUM>, which may be <NUM>-bit identifier of the type of data within the value field. In the implementation illustrated in <FIG>, the TLV type <NUM> of the discovery TLV <NUM> is type <NUM>, which is a custom TLV.

The length field includes a TLV length <NUM> that identifies the length of the value field. That is, the TLV length <NUM> can represent a total length of the organizationally unique identifier, the organizationally defined subtype, and the organizationally defined information string. In various examples, the TLV length <NUM> is represented by a <NUM>-bit value.

The organizationally unique identifier may specify an identifier <NUM>. The identifier <NUM> may identify an organization using the organization's organizationally unique identifier as defined in IEEE Std. <NUM>-<NUM>. The identifier <NUM> may have a length of <NUM> bits.

The organizationally defined subtype may specify a subtype <NUM>. The subtype <NUM> may identify the discovery TLV <NUM> among various TLVs utilized by the organization. In some cases, the subtype <NUM> may have a length of <NUM> bits.

The organizationally defined information string may include a service node identifier <NUM>, a service node location <NUM>, a service node type <NUM>, and/or a service node capability <NUM>. In some cases, the service node identifier <NUM>, the service node location <NUM>, the service node type <NUM>, and/or the service node capability <NUM> may be collectively represented by <NUM>-<NUM> octets.

The service node type <NUM> may indicate a type of the service node. For instance, the service node type <NUM> may identify whether the service node is a server, a network switch, or the like. In some cases, the service node type <NUM> may indicate a vendor of the service node.

<FIG> illustrates an example of a hopcount Type-Length-Value (TLV) <NUM> in a Link Layer Discovery Protocol (LLDP) message that is generated by a service node. In some cases, the LLDP message can be relayed through one or more intermediary nodes in a cluster network and received by a leaf node in a spine-leaf network. When an intermediary node relays the LLDP message, the intermediary node may modify the hopcount TLV <NUM>.

The hopcount TLV <NUM> can include at least one of three fields: a type field, a length field, and a value field. The type field includes a TLV type <NUM>, which may be <NUM>-bit identifier of the type of data within the value field. In some implementations, the TLV type <NUM> of the hopcount TLV <NUM> is type <NUM>, which refers to a custom TLV. However, in some cases, the TLV type <NUM> is one of types <NUM>-<NUM>. Types <NUM>-<NUM> are reserved TLV types.

The value field may include a counter <NUM>. The counter <NUM> may represent a number of remaining hops that the LLDP message can traverse through the network. In some cases, the counter <NUM> may have an integer value ranging from <NUM> to <NUM>. The counter <NUM> may be initialized by the service node. In some cases, an initial value of the counter <NUM> may depend on the number of tiers within the cluster network. For instance, the initial value of the counter <NUM> may be equal to or greater than the number of tiers within the cluster network. In some examples, the counter <NUM> may be initialized at a value of <NUM> to <NUM>. The counter <NUM> may be modified each time an intermediary node relays the LLDP message in the cluster network. In some cases, a relaying intermediary node may increment the counter <NUM> down by one upon receiving the LLDP message. In various implementations, the counter <NUM> can be represented by <NUM>-<NUM> octets.

<FIG> illustrates another example of a hopcount Type-Length-Value (TLV) <NUM> in a Link Layer Discovery Protocol (LLDP) message that is generated by a service node. In some cases, the LLDP message can be relayed through one or more intermediary nodes in a cluster network and received by a leaf node in a spine-leaf network. When an intermediary node relays the LLDP message, the intermediary node may modify the hopcount TLV <NUM>.

The hopcount TLV <NUM> can include multiple fields: a type field, a length field, and a value field that includes an organizationally unique identifier field, an organizationally defined subtype field, and an organizationally defined information string field. The type field includes a TLV type <NUM>, which may be <NUM>-bit identifier of the type of data within the value field. In some implementations, the TLV type <NUM> of the hopcount TLV <NUM> is type <NUM>, which refers to a custom TLV.

The organizationally defined subtype may specify a subtype <NUM>. The subtype <NUM> may identify the hopcount TLV <NUM> among various TLVs utilized by the organization. In some cases, the subtype <NUM> may have a length of <NUM> bits.

The information string field may include a counter <NUM>. The counter <NUM> may represent a number of remaining hops that the LLDP message can traverse through the network. In some cases, the counter <NUM> may have an integer value ranging from <NUM> to <NUM>. The counter <NUM> may be initialized by the service node. In some cases, an initial value of the counter <NUM> may depend on the number of tiers within the cluster network. For instance, the initial value of the counter <NUM> may be equal to or greater than the number of tiers within the cluster network. In some examples, the counter <NUM> may be initialized at a value of <NUM> to <NUM>. The counter <NUM> may be modified each time an intermediary node relays the LLDP message in the cluster network. In some cases, a relaying intermediary node may increment the counter <NUM> down by one upon receiving the LLDP message. In various implementations, the counter <NUM> can be represented by <NUM>-<NUM> octets.

<FIG> illustrate various processes associated with implementations of the present disclosure.

<FIG> illustrates an example process <NUM> for forwarding Link Layer Discovery Protocol (LLDP) messages. In various implementations, process <NUM> can be performed by a service node (e.g., the service node <NUM> described above with reference to <FIG>), an intermediary node (e.g., any of the intermediary nodes <NUM>, <NUM>-<NUM>, <NUM>-<NUM>, or <NUM>-<NUM> described above with reference to <FIG> and <FIG>), or the like.

At <NUM>, an LLDP message including a discovery Type-Length-Value (TLV) is identified. In some examples in which the process <NUM> is performed by a service node in a cluster network, <NUM> may include generating the LLDP message with the discovery TLV. In various examples in which the process <NUM> is performed by an intermediary node in the cluster network, <NUM> may include receiving the LLDP message from the service node or another intermediary node in the cluster network.

The discovery TLV may be a specific TLV that indicates information about the service node. In various implementations, the discovery TLV may indicate at least one of a service node identifier, a service node location, a service node type, or a service node capability. In some implementations, the discovery TLV is a Type <NUM> custom TLV. In some cases, the LLDP message may also include a hopcount TLV.

At <NUM>, the LLDP message including the discovery TLV is transmitted to a network node. In some implementations in which the process <NUM> is performed by an intermediary node, one or more elements in the LLDP message may be modified before the LLDP message is transmitted at <NUM>. However, regardless of whether the process <NUM> is performed by a service node, an intermediary node, or the like, the discovery TLV may be unmodified.

In various implementations, <NUM> and <NUM> can be repeated. For instance, a service node may periodically generate an LLDP message with the discovery TLV. An intermediary node may periodically receive the LLDP message from the service node or from another intermediary node in the cluster network.

<FIG> illustrates an example process <NUM> for relaying a Link Layer Discovery Protocol (LLDP) message. In various implementations, process <NUM> can be performed by an intermediary node (e.g., any of the intermediary nodes <NUM>, <NUM>-<NUM>, <NUM>-<NUM>, or <NUM>-<NUM> described above with reference to <FIG> and <FIG>), or the like.

At <NUM>, the LLDP message is received from a first node. The LLDP message includes a hopcount TLV. The first node may be a service node, an intermediary node, or the like in a cluster network. In various implementations, the hopcount TLV may be a specific TLV that includes a counter. The counter may specify an integer representing a number of remaining hops that the LLDP message can traverse through a cluster network. In some cases, the hopcount TLV is a Type <NUM> custom TLV.

In some cases, the LLDP message may further include a discovery TLV. The discovery TLV may be a specific TLV that indicates information about the service node in the cluster network. In various implementations, the discovery TLV may indicate at least one of a service node identifier, a service node location, a service node type, or a service node capability. In some implementations, the discovery TLV is a Type <NUM> custom TLV.

At <NUM>, the counter is modified. In some cases, the counter can be incremented down by one, which may represent the previous hop from the first node to the entity performing the process <NUM>.

At <NUM>, the counter is confirmed to be greater than a threshold. In some cases, the threshold is a predetermined integer, such as zero. If the counter is not greater than the threshold, then the LLDP message may be discarded and not forwarded. However, if the counter is determined to be greater than the threshold, the LLDP message may be forwarded to another node.

At <NUM>, the LLDP message is transmitted to a second node with the modified counter. In some cases, the second node can be an intermediary node in the cluster network. In certain instances, the second node can be a leaf node in a spine-leaf network.

<FIG> illustrates an example process <NUM> by which a node in a spine-leaf network can discover and/or confirm the presence of a service node in a cluster network connected to the spine-leaf network. In various implementations, the process <NUM> can be performed by a leaf node (e.g., leaf node <NUM>-<NUM>, <NUM>-<NUM>, or <NUM>-<NUM> described above with reference to <FIG>).

At <NUM>, a Link Layer Discovery Protocol (LLDP) message identifying a service node in a cluster network is received from an intermediary node in the cluster network. The LLDP message may include a discovery Type Length Value (TLV). The discovery TLV may be a specific TLV that indicates information about the service node in the cluster network. In various implementations, the discovery TLV may indicate at least one of a service node identifier, a service node location, a service node type, or a service node capability. In some implementations, the discovery TLV is a Type <NUM> custom TLV.

At <NUM>, a network controller is informed of the service node in the cluster network. In some cases, the network controller is a Software Defined Network (SDN) controller that is connected to the entity performing the process <NUM> by one or more interfaces. The network controller can be represented in software, hardware, or a combination thereof. In some cases, a packet indicating information within the discovery TLV can be transmitted to the network controller. However, in various implementations, the entity performing the process <NUM> (e.g., the leaf node) may refrain from forwarding the entire LLDP message to the network controller. For instance, the packet transmitted to the network controller can indicate at least one of the service node identifier, the service node location, the service node type, or the service node capability. The packet may, in some instances, be forwarded according to proprietary packet-based and/or control-path mechanisms. In some cases, the packet can further identify the entity performing the process <NUM>. For instance, if process <NUM> is performed by a leaf node, the packet can identify the leaf node.

<FIG> illustrates an example process <NUM> by which a network controller in a spine-leaf network can discover and monitor a service node. In various implementations, the process <NUM> can be performed by a controller, such as the network controller <NUM> described above with reference to <FIG>.

At <NUM>, a service node is determined to have joined a cluster network based on a first Link Layer Discovery Protocol (LLDP) message received by a leaf node in a spine-leaf network. In various implementations, the entity performing process <NUM> may be part of the spine-leaf network, connected to the spine-leaf network, or the like. Upon receiving the first LLDP message, the leaf node may transmit, to the entity performing process <NUM>, a message indicating the first LLDP message. The message may indicate, for example, at least one of an identifier of a service node that generated the first LLDP message, a location of the service node, a type of the service node, or a capability of the service node. The message may further identify the leaf node. In some cases, the first LLDP message is generated by the service node in response to the service node connecting to a cluster network, which is connected to the spine-leaf network. Accordingly, the service node may be connected to the spine-leaf network.

At <NUM>, the service node is managed. In various implementations, the entity performing the process <NUM> can manage computing resources in the service node. For instance, the entity may 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, networking resources, or the like. In some implementations, the entity may communicate with the service node using the leaf node. In various examples, the service node can be managed by updating a network configuration of the spine-leaf network. For instance, various Virtual Local Area Networks (VLANs) (or other network policies) can be activated on leaf and/or intermediary nodes.

At <NUM>, the service node is determined to remain connected to the network based on a second LLDP message received by the leaf node in the spine-leaf network. In various implementations, the service node may generate and transmit second LLDP messages periodically when the service node is connected to the spine-leaf network. Accordingly, the leaf node may receive multiple second LLDP messages indicating that the service node remains connected to the spine-leaf network. The leaf node may forward messages to the entity performing the process <NUM> indicating that the service node remains connected to the spine-leaf network. Accordingly, the process <NUM> may loop back to <NUM>, such that the service node is managed as long as the service node is determined to remain connected to the spine-leaf network.

<FIG> is a computing system diagram illustrating a configuration for a data center <NUM> that can be utilized to implement aspects of the technologies disclosed herein. The example data center <NUM> shown in <FIG> includes several server computers 1002A-1002C (which might be referred to herein singularly as "a server computer <NUM>" or in the plural as "the server computers <NUM>") for providing computing resources <NUM>. In some examples, the resources <NUM> and/or server computers <NUM> may include, or correspond to, the service nodes (e.g., service node <NUM>) described herein.

The server computers <NUM> can be standard tower, rack-mount, or blade server computers configured appropriately for providing the computing resources described herein. The computing resources <NUM> can be data processing resources such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, networking resources, and others. Some or all of the server computers <NUM> can also be configured to execute a resource manager capable of instantiating and/or managing the computing resources. In the case of VM instances, for example, the resource manager can be a hypervisor or another type of program configured to enable the execution of multiple VM instances on a single server computer <NUM>. Server computers <NUM> in the data center <NUM> can also be configured to provide network services and other types of services.

In the example data center <NUM>, an appropriate Local Area Network (LAN) including the spine-leaf network <NUM> and switches 1006A-1006C are also utilized to interconnect the server computers 1002A-1002C. It should be appreciated that the configuration and network topology described herein has been greatly simplified and that many more computing systems, software components, networks, and networking devices can be utilized to interconnect the various computing systems disclosed herein and to provide the functionality described above. Appropriate load balancing devices or other types of network infrastructure components can also be utilized for balancing a load between data centers <NUM>, between each of the server computers 1002A-1002C in each data center <NUM>, and, potentially, between computing resources in each of the server computers <NUM>. It should be appreciated that the configuration of the data center <NUM> described with reference to <FIG> is merely illustrative and that other implementations can be utilized.

As illustrated in <FIG>, some of the server computers <NUM> (e.g., server computers 1002A and 1002B) may each execute an Link Layer Discovery Protocol (LLDP) generator <NUM> configured to generate LLDP messages. Each of the LLDP messages may include a discovery Type-Length-Value (TLV) field and/or a hopcount TLV field. The server computers <NUM> may transmit the generated LLDP messages toward the switches <NUM>.

Further, each of the switches <NUM> may execute an LLDP relayer <NUM>. Using the LLDP relayer <NUM>, the switches <NUM> may relay the LLDP messages from the server computers <NUM> toward the spine-leaf network <NUM>. In some cases, the switches <NUM> may modify the hopcount TLV field in each of the relayed LLDP messages. The switches <NUM> may also respectively include buffers <NUM>. The buffers <NUM> may be used to temporarily store data packets that the switches <NUM> forward between the server computers <NUM> and the spine leaf network <NUM>.

At least one of the server computers <NUM> (e.g., server computer 1102C) may further execute a controller <NUM>. The controller <NUM> may be responsible for managing the spine leaf network <NUM> and/or the computing resources <NUM> in the server computers <NUM>. When the spine-leaf network <NUM> receives the LLDP messages generated by the server computers <NUM> and forwarded by the switches <NUM>, the spine-leaf network <NUM> may forward a message to the server computer 1002C executing the controller <NUM>. The controller <NUM> may discover and/or confirm the presence of the server computers <NUM> by receiving messages from the spine-leaf network <NUM>.

In some instances, the computing resources <NUM> may provide application containers, VM instances, and storage, or the like, on a permanent or an as-needed basis. Among other types of functionality, the computing resources <NUM> may be utilized to implement the various services described above. The computing resources can include various types of computing resources, such as data processing resources like application containers and VM instances, data storage resources, networking resources, data communication resources, network services, and the like.

Each type of computing resource <NUM> can be general-purpose or can be available in a number of specific configurations. For example, data processing resources can be available as physical computers or VM instances in a number of different configurations. The VM instances can be configured to execute applications, including web servers, application servers, media servers, database servers, some or all of the network services described above, and/or other types of programs. Data storage resources can include file storage devices, block storage devices, and the like. The data center <NUM> can also be configured to provide other types of computing resources not mentioned specifically herein.

The computing resources <NUM> may be enabled in one embodiment by one or more data centers <NUM> (which might be referred to herein singularly as "a data center <NUM>" or in the plural as "the data centers <NUM>"). The data centers <NUM> are facilities utilized to house and operate computer systems and associated components. The data centers <NUM> typically include redundant and backup power, communications, cooling, and security systems. The data centers <NUM> can also be located in geographically disparate locations.

<FIG> shows an example computer architecture for a computer <NUM> capable of executing program components for implementing the functionality described above. The computer architecture shown in <FIG> illustrates a conventional server computer, workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, network switch, or other computing device, and can be utilized to execute any of the software components presented herein. The computer <NUM> may, in some examples, correspond to a network node (e.g., a service node <NUM>, an intermediary node <NUM>, a leaf node <NUM>, or the like) described herein.

The computer <NUM> includes a baseboard <NUM>, or "motherboard," which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units ("CPUs") <NUM> operate in conjunction with a chipset <NUM>. The CPUs <NUM> can be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computer <NUM>.

The chipset <NUM> provides an interface between the CPUs <NUM> and the remainder of the components and devices on the baseboard <NUM>. The chipset <NUM> can provide an interface to a RAM <NUM>, used as the main memory in the computer <NUM>. The chipset <NUM> can further provide an interface to a computer-readable storage medium such as a read-only memory ("ROM") <NUM> or non-volatile RAM ("NVRAM") for storing basic routines that help to startup the computer <NUM> and to transfer information between the various components and devices. The ROM <NUM> or NVRAM can also store other software components necessary for the operation of the computer <NUM> in accordance with the configurations described herein.

The computer <NUM> can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the network <NUM>. The chipset <NUM> can include functionality for providing network connectivity through a Network Interface Controller (NIC) <NUM>, such as a gigabit Ethernet adapter. The NIC <NUM> is capable of connecting the computer <NUM> to other computing devices over the network <NUM>. It should be appreciated that multiple NICs <NUM> can be present in the computer <NUM>, connecting the computer to other types of networks and remote computer systems. In some instances, the NICs <NUM> may include at least on ingress port and/or at least one egress port.

The computer <NUM> can be connected to a storage device <NUM> that provides non-volatile storage for the computer. The storage device <NUM> can store an operating system <NUM>, programs <NUM>, and data, which have been described in greater detail herein. The storage device <NUM> can be connected to the computer <NUM> through a storage controller <NUM> connected to the chipset <NUM>. The storage device <NUM> can consist of one or more physical storage units. The storage controller <NUM> can interface with the physical storage units through a serial attached SCSI ("SAS") interface, a serial advanced technology attachment ("SATA") interface, a fiber channel ("FC") interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

The computer <NUM> can store data on the storage device <NUM> by transforming the physical state of the physical storage units to reflect the information being stored. The specific transformation of physical state can depend on various factors, in different embodiments of this description. Examples of such factors can include, but are not limited to, the technology used to implement the physical storage units, whether the storage device <NUM> is characterized as primary or secondary storage, and the like.

For example, the computer <NUM> can store information to the storage device <NUM> by issuing instructions through the storage controller <NUM> to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location in an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of physical media are possible without departing from the scope of the present description, with the foregoing examples provided only to facilitate this description. The computer <NUM> can further read information from the storage device <NUM> by detecting the physical states or characteristics of one or more particular locations within the physical storage units.

In addition to the mass storage device <NUM> described above, the computer <NUM> can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the computer <NUM>. In some examples, the operations performed by a leaf node (e.g., <NUM>), a spine node (e.g., <NUM>), a controller (e.g., network controller <NUM>), an intermediary node (e.g., <NUM>), a service node (e.g., <NUM>), a previous node (e.g., <NUM>), a next node (e.g., <NUM>), or a combination thereof, may be supported by one or more devices similar to computer <NUM>. Stated otherwise, some or all of the operations performed by leaf node, a spine node, a controller, an intermediary node, a service node, a previous node, a next node, or the like, may be performed by one or more computer devices <NUM> operating in a cloud-based arrangement.

By way of example, and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically-erasable programmable ROM ("EEPROM"), flash memory or other solid-state memory technology, compact disc ROM ("CD-ROM"), digital versatile disk ("DVD"), high definition DVD ("HD-DVD"), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory fashion.

As mentioned briefly above, the storage device <NUM> can store an operating system <NUM> utilized to control the operation of the computer <NUM>. According to one embodiment, the operating system comprises the LINUX operating system. According to another embodiment, the operating system comprises the WINDOWS® SERVER operating system from MICROSOFT Corporation of Redmond, Washington. According to further embodiments, the operating system can comprise the UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be utilized. The storage device <NUM> can store other system or application programs and data utilized by the computer <NUM>.

In one embodiment, the storage device <NUM> or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer <NUM>, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executable instructions transform the computer <NUM> by specifying how the CPUs <NUM> transition between states, as described above. According to one embodiment, the computer <NUM> has access to computer-readable storage media storing computer-executable instructions which, when executed by the computer <NUM>, perform the various processes described above with regard to <FIG>. The computer <NUM> can also include computer-readable storage media having instructions stored thereupon for performing any of the other computer-implemented operations described herein.

As illustrated in <FIG>, the storage device <NUM> also stores a Link Layer Discovery Protocol (LLDP) relayer <NUM>. In some implementations, the LLDP relayer <NUM> can be omitted. Using instructions stored in the LLDP relayer <NUM>, the CPU(s) <NUM> may cause the computer <NUM> to relay an LLDP message generated by a service node toward a leaf node.

In summary, this disclosure describes various methods, systems, and devices related to dynamic service node discovery in a network. In an example method, an intermediary node receives a Link Layer Discovery Protocol (LLDP) message from a first node. The LLDP message includes a discovery Type-Length-Value (TLV) that indicates a location of a service node in the network. The method further includes forwarding the LLDP message to a second node.

In some instances, one or more components may be referred to herein as "configured to," "configurable to," "operable/operative to," "adapted/adaptable," "able to," "conformable/conformed to," etc. Those skilled in the art will recognize that such terms (e.g., "configured to") can generally encompass active-state components and/or inactive-state components and/or standby-state components, unless context requires otherwise.

As used herein, the term "based on" can be used synonymously with "based, at least in part, on" and "based at least partly on.

As used herein, the terms "comprises/comprising/comprised" and "includes/including/included," and their equivalents, can be used interchangeably. An apparatus, system, or method that "comprises A, B, and C" includes A, B, and C, but also can include other components (e.g., D) as well. That is, the apparatus, system, or method is not limited to components A, B, and C.

While the invention is described with respect to the specific examples, it is to be understood that the scope of the invention is not limited to these specific examples. Since other modifications and changes varied to fit particular operating requirements and environments will be apparent to those skilled in the art, the invention is not considered limited to the example chosen for purposes of disclosure, and covers all changes and modifications which do not constitute departures from the scope of this invention.

Claim 1:
A method, performed by an intermediary node (<NUM>), from a cluster network interconnecting service node(s) and leaf nodes, in a spine-leaf network, the method comprising:
receiving (<NUM>), from a first node (<NUM>) in a network, a Link Layer Discovery Protocol, LLDP, message (<NUM>) comprising a discovery Type-Length-Value, TLV, (<NUM>) that indicates an identifier of a service node in the network and a hopcount TLV (<NUM>) comprising a counter;
decreasing (<NUM>) the counter in the hopcount TLV;
determining (<NUM>) that the counter is greater than zero; and
forwarding (<NUM>), to a second node (<NUM>) in the network, the LLDP message (<NUM>).