A device discovery method and apparatus for satellite management component devices in a cluster

Abstract

The application discloses a device discovery method and device of satellite management component equipment in a cluster, and relates to the technical field of communication. The method comprises the following steps: receiving a head node broadcast message; analyzing the head node broadcast message according to a preset mapping table, determining a cluster and a port corresponding to the head node broadcast message; forwarding the head node broadcast message to the satellite management component equipment in the corresponding cluster by using the corresponding port; receiving a device greeting message; the device greeting message is sent by the satellite management component equipment; forwarding the device greeting message that passes the check and a generated switch authentication message to the head node equipment in the corresponding cluster after merging; receiving a head node acceptance message, and forwarding the head node acceptance message to the satellite management component equipment of the corresponding device type according to the mapping table. The application can accurately isolate the messages of different clusters, distinguish and identify the SMC equipment of different device types, and ensure the high-strength communication safety of the whole interactive process.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and specifically to a method and apparatus for device discovery of satellite management component devices in a cluster. Background Technology

[0002] With the rapid development of fields such as artificial intelligence, big data analytics, and scientific computing, the scale and complexity of intelligent computing centers and high-performance computing centers have increased dramatically. These centers typically consist of a large number of heterogeneous computing, storage, and network acceleration devices, such as graphics processing units (GPUs), storage arrays, data processing units (DPUs), and power management modules. To efficiently and reliably manage these massive and diverse hardware resources, the industry generally adopts a distributed management architecture, consisting of a central management node and multiple satellite management components (SMCs) forming a logical management cluster. This central management node is usually called the head node. Each SMC is responsible for the local monitoring, configuration, and maintenance of its associated physical devices, such as GPU servers, storage racks, and DPUs. The scale of clusters has expanded from a single cluster to hundreds of clusters. Each cluster manages multiple SMCs.

[0003] However, existing SMC device discovery and management solutions have a series of significant shortcomings when dealing with large-scale, multi-type, and high-security modern intelligent computing center clusters: Administrators need to configure the IP address, Head binding relationship, and permission information of each SMC device. When a large number of SMC devices need to be deployed, only device discovery can be solved. There is a lack of deep integration with subsequent management operations. It is time-consuming and prone to cross-cluster registration due to configuration errors. Furthermore, because it cannot identify the type of SMC device, it cannot automatically classify and archive devices by type, resulting in a large workload and long time consumption for operation and maintenance. It cannot meet the needs of automated operation and maintenance and rapid fault response, and it cannot issue targeted management commands, such as issuing GPU firmware upgrade commands to storage SMC. Because device detection is currently often performed using broadcast or multicast methods, it is impossible to define clear cluster boundaries physically or logically. This can lead to confusion between SMC devices managed by different Head Nodes, which can also easily cause cross-cluster registration. For example, a GPU SMC in Cluster A may be incorrectly registered to Cluster B, resulting in chaotic SMC device management. Current clusters are increasingly biased towards one head node managing three or more SMC devices, with the head node and SMC devices communicating via I / O. 2 Interconnection via low-speed buses such as C and SMCs, with SMC devices directly interconnected via a Local Area Network (LAN), only allows for discrete management of the Head BMC and SMC. In large-scale scenarios with hundreds of clusters and thousands of SMCs, this significantly consumes the I / O bandwidth of the Head BMC. 2 The C bus resources are insufficient, and due to the severe lack of bandwidth, large files cannot be transferred, resulting in a significant data transmission bottleneck. It is impossible to achieve fragmented upgrades of SMC firmware. Moreover, it relies on a single centralized management server to poll the status of all SMCs, i.e., northbound centralized management, which leads to a linear increase in server load with the number of devices, resulting in high CPU utilization, large response latency, and inability to achieve real-time monitoring. Traditional protocol discovery mechanisms typically transmit device identification and configuration information in plaintext or through simple authentication methods. This approach cannot defend against man-in-the-middle attacks, message tampering, and replay attacks. Furthermore, because it cannot identify the type of SMC device, malicious devices can easily forge SMC messages to impersonate and register with the cluster, stealing sensitive hardware asset information, performance data, and even distributing malicious firmware or configurations, posing a serious threat to the entire computing infrastructure.

[0004] Therefore, how to achieve the discovery and full lifecycle management of large-scale, multi-type SMC devices while ensuring high performance and high security is an important issue that the industry urgently needs to address. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a device discovery method and apparatus for satellite management component devices in a cluster, thereby solving problems such as cross-cluster obfuscation, low security, and lack of management functions.

[0006] According to a first aspect, embodiments of the present invention provide a device discovery method for satellite management component devices in a cluster, applied to network devices, the method comprising: Receive head node broadcast messages; head node broadcast messages are sent by the head node devices in the cluster. Each cluster contains one head node device, several satellite management component devices, and an authorized switch for communication between the head node device and all satellite management component devices. When the authorized switch forwards messages, cross-cluster registration and cross-device type propagation are prohibited. The head node broadcast message is parsed according to the preset mapping table to determine the cluster and port corresponding to the head node broadcast message; the mapping table contains the mapping relationship between the cluster to which it belongs, the port of the authorized switch, and the device type of the satellite management component device; The header node broadcast message is forwarded to the corresponding satellite management component device in the cluster using the corresponding port. Receive device greeting messages; device greeting messages are sent by the satellite management component device; The device greeting message is verified according to the preset mapping table, and the verified device greeting message is merged with the generated switch authentication message and forwarded to the head node device in the corresponding cluster. The head node receives the message and forwards it to the corresponding satellite management component device according to the mapping table; the head node receives the message and sends it.

[0007] In conjunction with the first aspect, in the first embodiment of the first aspect, the step of parsing the head node broadcast message according to a preset mapping table to determine the cluster and port corresponding to the head node broadcast message specifically includes: The header node broadcast message is parsed to extract the cluster to which it belongs from the common header and the supported device types from the type-length-value payload; the header node broadcast message consists of a common header and a type-length-value payload. Based on the cluster it belongs to and the supported device types, query the mapping table to determine the cluster and port corresponding to the header node's broadcast message.

[0008] In conjunction with the first aspect, in the second embodiment of the first aspect, the step of verifying the device greeting message according to a preset mapping table, and merging the verified device greeting message with the generated switch authentication message before forwarding it to the corresponding head node device in the cluster, specifically includes: The device greeting message is parsed to determine the message source and the cluster authorization list; The mapping table is used to determine whether there is a match between the message source and the port of the receiving device greeting message, and whether the port is in the cluster authorization list. If the port matches and the port is in the cluster authorization list, a switch authentication message carrying the device type is generated using the switch private key. The device greeting message of the same device type is then merged with the switch authentication message and forwarded to the corresponding head node device in the cluster. The switch authentication message carries an auth_tag field, which is generated based on the switch private key. If it is determined that the port does not match or the port is not in the cluster authorization list, discard the device greeting message.

[0009] In conjunction with the first aspect, in the third embodiment of the first aspect, the receiving head node accepts the message and forwards the received message to the satellite management component device of the corresponding device type according to the mapping table, specifically including: Receive the message from the head node, parse the message, and extract the device type identifier contained in the message. The mapping table is queried based on the device type identifier to determine the port corresponding to which the head node receives messages; The head node receives and forwards messages to the corresponding satellite management component device based on the corresponding port.

[0010] According to a second aspect, embodiments of the present invention also provide a device discovery method for satellite management component devices in a cluster, applied to a server, the method comprising: Based on the preset stateless satellite self-discovery protocol structure, a header node broadcast message is constructed; the stateless satellite self-discovery protocol structure adopts a common header and TLV payload structure; Header node broadcast messages are periodically sent to the authorized switches; each cluster contains one head node device, several satellite management component devices, and an authorized switch for communication between the head node device and all satellite management component devices, and the authorized switches are prohibited from cross-cluster registration and cross-device type propagation when forwarding messages; Receive the merged and forwarded device greeting message and switch authentication message, and verify the switch authentication message and the device greeting message in sequence using the pre-stored switch public key and the pre-stored device public key, respectively. Once it is confirmed that both the device greeting message and the switch authentication message have passed verification, the session key is negotiated according to the device type, and the session key is encrypted using the device public key corresponding to the device type; different device types correspond to different session keys; Construct a header node accept message containing the device type identifier based on the encrypted session key, and send the header node accept message to the authorized switch.

[0011] In conjunction with the second aspect, in the first embodiment of the second aspect, the step of constructing a head node broadcast message according to a preset stateless satellite self-discovery protocol structure specifically includes: Load the pre-configured cluster's universally unique identifier and supported device types; Generate a single-use random number; Based on the cluster's universally unique identifier, supported device types, a single-use random number, and a pre-shared key with the authorized switch, and according to the preset interactive session message structure, a header node broadcast message is constructed.

[0012] In conjunction with the second aspect, in the second embodiment of the second aspect, the receiving and merging of the device greeting message and the switch authentication message, and the sequential verification of the switch authentication message using a pre-stored switch public key and the device greeting message using a pre-stored device public key, specifically include: Receive and merge forwarded device greeting messages and switch authentication messages; The switch authentication message is parsed to extract the first authentication message, the corresponding port, and the device type of the message source. The validity of the first authentication message is verified using the switch's public key; the first authentication message is generated by the authorized switch using the switch's private key. If the first authentication message is found to be valid, the corresponding port and the device type of the message source are determined according to the mapping table to see if they match the mapping table. If it is determined whether there is a match with the mapping table, the device greeting message is parsed to extract the second authentication message, the single-use random number, the timestamp information, and the device type of the message source. Based on the device type of the message source, the corresponding device public key is dispatched, and the device public key is used to verify whether the second authentication message is legitimate; the second authentication message is generated by the satellite management component device using the device private key. If the first authentication message is found to be valid, verify whether the random number used in a single instance is in a preset blacklist and whether the timestamp information is within its validity period. If it is determined that the device is not on the blacklist and is within the validity period, determine whether the device type of the message source is among the supported device types.

[0013] In conjunction with the second aspect, in the third embodiment of the second aspect, the method further includes the following steps: Receive device status messages, update the overall cluster status according to the device type corresponding to the message source, and synchronize the overall cluster status to the northbound system; device status messages are reported by the satellite management component devices and include abnormal status information, online rate information, and health information.

[0014] According to a third aspect, embodiments of the present invention also provide a device discovery apparatus for satellite management component devices in a cluster, applied to network devices, the apparatus comprising: The first receiving module is used to receive head node broadcast messages. Head node broadcast messages are sent by the head node devices in the cluster. Each cluster contains one head node device, several satellite management component devices, and an authorized switch for communication between the head node device and all satellite management component devices. When the authorized switch forwards messages, cross-cluster registration and cross-device type propagation are prohibited. The first parsing module is used to parse the head node broadcast message according to the preset mapping table to determine the cluster and port corresponding to the head node broadcast message; the mapping table contains the mapping relationship between the cluster to which it belongs, the port of the authorized switch, and the device type of the satellite management component device; The first forwarding module is used to forward the head node broadcast message to the corresponding satellite management component device in the cluster using the corresponding port. The second receiving module is used to receive device greeting messages; the device greeting messages are sent by the satellite management component device. The second forwarding module is used to verify the device greeting message according to the preset mapping table, and to merge the verified device greeting message with the generated switch authentication message and forward it to the head node device in the corresponding cluster. The third forwarding module is used to receive the head node accept message and forward it to the satellite management component device of the corresponding device type according to the mapping table; the head node accept message is sent by the head node device.

[0015] According to a fourth aspect, embodiments of the present invention also provide a device discovery apparatus for satellite management component devices in a cluster, applied to a server, the apparatus comprising: The message construction module is used to construct the header node broadcast message according to the preset stateless satellite self-discovery protocol structure; the stateless satellite self-discovery protocol structure adopts a common header and TLV payload structure; The first sending module is used to periodically send head node broadcast messages to the authorized switches. Each cluster contains one head node device, several satellite management component devices, and an authorized switch for communication between the head node device and all satellite management component devices. The authorized switches are prohibited from cross-cluster registration and cross-device type propagation when forwarding messages. The third receiving module is used to receive the merged and forwarded device greeting message and switch authentication message, and sequentially verify the switch authentication message using the pre-stored switch public key and verify the device greeting message using the pre-stored device public key. The session negotiation module is used to negotiate a session key according to the device type after confirming that both the device greeting message and the switch authentication message have passed verification, and to encrypt the session key using the device public key corresponding to the device type; different device types correspond to different session keys; The second sending module is used to construct a header node accept message containing a device type identifier based on the encrypted session key, and send the header node accept message to the authorized switch. Attached Figure Description

[0016] The features and advantages of the invention will be more clearly understood by referring to the accompanying drawings, which are schematic and should not be construed as limiting the invention in any way. In the drawings: Figure 1 This diagram illustrates the process of applying the device discovery method for satellite management component devices in a cluster, provided by the present invention, to network devices. Figure 2The diagram illustrates the interaction timing of the device discovery method for satellite management component devices in a cluster provided by the present invention. Figure 3 The diagram illustrates the process of applying the device discovery method for satellite management component devices in a cluster provided by the present invention to the server. Figure 4 This diagram illustrates the structure of the device discovery device for the satellite management component in a cluster provided by the present invention applied to network devices. Figure 5 This diagram illustrates the structure of the device discovery method for satellite management components in a cluster, as provided by the present invention, applied to the server. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] First, let's explain the technical terms that appear in this embodiment: Baseboard Management Controller (BMC): A hardware management controller used for monitoring, configuring, and maintaining motherboard-level hardware, such as Head BMC management logic management cluster.

[0019] Satellite Management Component (SMC): This is a management controller attached to various hardware devices and can be divided into several types, including GPU SMC (which includes GPU hardware), Storage SMC (which includes storage media / controller), DPU SMC (which includes DPU chip / network port), etc., to provide dedicated hardware resources and local management capabilities for the cluster.

[0020] Universally Unique Identifier (UUID): A 128-bit unique identifier used to uniquely identify Head BMC, SMC, and switches. It can be either a complete UUID or a UUID truncated to the lower 4 bytes.

[0021] Hash-based Message Authentication Code (HMAC): Combined with a key, it generates, for example, HMAC-SHA256, to ensure message integrity and prevent tampering.

[0022] Number used once (Nonce): Used to generate a new value for each communication to prevent replay attacks.

[0023] Type-Length-Value (TLV) is a format used in data communication protocols to encode optional information. It consists of three fields: Type, Length, and Value. It is commonly used in data interaction of smart cards, IoT devices, and network protocols, and can optimize message parsing efficiency.

[0024] Virtual Local Area Network (VLAN): When combined with port mapping, it can help achieve cluster network isolation.

[0025] Access Control List (ACL): Switches use ACLs to prohibit cross-cluster communication and only allow Head Nodes within the same cluster to interact with the SMC.

[0026] Transmission Control Protocol (TCP): A connection-oriented, reliable, byte-stream-based transport layer communication protocol used for northbound communication and the transmission of large files such as firmware and logs.

[0027] Elliptic Curve Diffie-Hellman (ECDH) is an anonymous key exchange protocol based on elliptic curve cryptography that allows two communicating parties to generate a shared key by exchanging public keys over an insecure channel. This shared key is used by the Head Node and the SMC to negotiate the Session Key.

[0028] Advanced Encryption Standard 256-bit Galois / Counter Mode (AES-256-GCM): Used for encryption of Head and SMC communication data.

[0029] With the rapid development of fields such as artificial intelligence, big data analytics, and scientific computing, the scale and complexity of Intelligent Computing Centers and High-Performance Computing Centers have increased dramatically. These centers typically consist of a large number of heterogeneous computing, storage, and network acceleration devices, such as GPUs, storage arrays, DPUs, and power management modules. To efficiently and reliably manage these massive and diverse hardware resources, the industry generally adopts a distributed management architecture, consisting of a central management node and multiple SMC devices forming a logical management cluster. This central management node is usually called the head node. Each SMC is responsible for the local monitoring, configuration, and maintenance of its physical devices, such as GPU servers, storage racks, and DPU devices. The scale of clusters has expanded from a single cluster to hundreds of clusters. Each cluster manages multiple SMC devices.

[0030] However, existing SMC device discovery and management solutions have a series of significant shortcomings when dealing with large-scale, multi-type, and high-security modern intelligent computing center clusters, including but not limited to: Administrators need to configure the IP address, Head binding relationship, and permission information of each SMC device. When a large number of SMC devices need to be deployed, only device discovery can be solved. There is a lack of deep integration with subsequent management operations. It is time-consuming and prone to cross-cluster registration due to configuration errors. Furthermore, because it cannot identify the type of SMC device, it cannot automatically classify and archive devices by type, resulting in a large workload and long time consumption for operation and maintenance. It cannot meet the needs of automated operation and maintenance and rapid fault response, and it cannot issue targeted management commands, such as issuing GPU firmware upgrade commands to storage SMC. Because device detection is currently often performed using broadcast or multicast methods, it is impossible to define clear cluster boundaries physically or logically. This can lead to confusion between SMC devices managed by different Head Nodes, which can also easily cause cross-cluster registration. For example, a GPU SMC in Cluster A may be incorrectly registered to Cluster B, resulting in chaotic SMC device management. Current clusters are increasingly biased towards one head node managing three or more SMC devices, with the head node and SMC devices communicating via I / O. 2Interconnection via low-speed buses such as C and SMCs, with SMC devices directly interconnected via a Local Area Network (LAN), only allows for discrete management of the Head BMC and SMC. In large-scale scenarios with hundreds of clusters and thousands of SMCs, this significantly consumes the I / O bandwidth of the Head BMC. 2 The C bus resources are insufficient, and due to the severe lack of bandwidth, large files cannot be transferred, resulting in a significant data transmission bottleneck. It is impossible to achieve fragmented upgrades of SMC firmware. Moreover, it relies on a single centralized management server to poll the status of all SMCs, i.e., northbound centralized management, which leads to a linear increase in server load with the number of devices, resulting in high CPU utilization, large response latency, and inability to achieve real-time monitoring. Traditional protocol discovery mechanisms typically transmit device identification and configuration information in plaintext or through simple authentication methods. This approach cannot defend against man-in-the-middle attacks, message tampering, and replay attacks. Furthermore, because it cannot identify the type of SMC device, malicious devices can easily forge SMC messages to impersonate and register with the cluster, stealing sensitive hardware asset information, performance data, and even distributing malicious firmware or configurations, posing a serious threat to the entire computing infrastructure.

[0031] Specifically, we will use several commonly used SMC device discovery and management solutions as examples to illustrate: 1. Intel Intelligent Platform Management Interface (IPMI) v2.0 device discovery mechanism: Intel IPMI is the industry-leading BMC management standard, and its device discovery is achieved through the following methods: The Head BMC uses the Remote Management Control Protocol (RMCP) and broadcasts probe messages at regular intervals, such as 60 seconds. After receiving the messages, the SMC device returns a response containing the IP address and device model (without identifying the SMC device type). Then, the administrator manually configures the binding relationship and type matching between the Head and the SMC device using tools such as MeshCommander. Firmware upgrades require downloading the complete image via HTTP (without fragmented transmission, and it is impossible to identify and distinguish SMC device types such as GPU / storage / DPU firmware). Logs also need to be retrieved by logging into each SMC device individually.

[0032] Because Intel IPMI lacks fixed and explicit definitions for Cluster and SMC types, it supports any number and type of SMCs, making it unsuitable for deployments with multiple SMC devices where specific device types are required. Broadcast probe messages lack Cluster identifiers and SMC device types, leading to potential errors in registration or management command transmission. Furthermore, all standard switches can forward IPMI messages, relying solely on username and password authentication, lacking replay protection, data encryption, and type verification mechanisms, resulting in poor security. Firmware lacks fragmented transmission, causing upgrades to fail upon network interruption, and it also cannot distinguish device types for log retrieval.

[0033] 2. Cisco Discovery Protocol (CDP): CDP is a link-layer discovery protocol natively supported by Cisco switches. It is suitable for network device interactions, and device discovery is achieved through the following methods: Network devices such as switches and routers broadcast CDP messages at regular intervals, such as every 30 seconds. The CDP message contains the device UUID, port number (but no SMC device type information). The receiver uses the CDP message to build a neighbor topology and locate the device (but cannot identify or distinguish SMC device types such as GPU / storage / DPU firmware).

[0034] It should be noted that CDP does not support dedicated SMC management functions (such as GPU temperature monitoring, storage RAID configuration, and DPU port debugging). It is only used for device presence discovery and requires additional protocols to supplement management capabilities.

[0035] Similarly, CDP does not support the management of multiple types of SMC devices. CDP can only be used for network device discovery and only supports Cisco switches to achieve the above functions. CDP messages are transmitted in plaintext during transmission, which makes them easy to be tampered with or forged, and cannot identify the type of SMC device.

[0036] 3. Extended discovery schemes based on Dynamic Host Configuration Protocol (DHCP) options. Some manufacturers implement device discovery through DHCP server extensions: The DHCP server adds an Option 250 field to the response (containing Cluster_ID, Head IP, but no SMC device type). When the SMC device starts up, it obtains an IP address via DHCP and reads the Option 250 information to send a registration request to the Head IP (it cannot inform the Head of its own device type). The switch only acts as a Layer 2 forwarding device and does not participate in authentication, isolation control, or SMC device type verification.

[0037] Extended discovery schemes based on DHCP Options rely on third-party servers and cannot be discovered when there is no DHCP server, posing a single point of failure risk. The Option 250 field does not include Cluster isolation and SMC type, resulting in high risk of cross-cluster registration. Users cannot manage it in a targeted manner. At the same time, other vendors' switches can also forward DHCP messages normally, making it impossible to achieve exclusive control and type verification. Firmware upgrades cannot resume interrupted transmissions, logs are not compressed by type, and usability is poor when the network is unstable.

[0038] In conclusion, how to achieve the discovery and full lifecycle management of large-scale, multi-type SMC devices while ensuring high performance and high security is an important issue that the industry urgently needs to address.

[0039] Due to the aforementioned technical problems, this invention provides a device discovery method for satellite management component devices in a cluster. The method aims to accurately isolate messages from different clusters and distinguish and identify SMC devices of different device types. It establishes a strong authentication, communication encryption, message integrity verification, and anti-replay attack mechanism from the SMC device to the Head BMC, ensuring high-strength communication security throughout the entire interaction process. This device discovery method for satellite management component devices in a cluster can be used in electronic devices, including but not limited to computers, mobile terminals, etc. Figure 1 This is a schematic diagram illustrating the process of applying the device discovery method of the satellite management component device in a cluster according to an embodiment of the present invention to a network device such as a switch. Figure 2 This is an interaction timing diagram of the device discovery method for satellite management component devices in a cluster according to an embodiment of the present invention, such as... Figure 1 and Figure 2 As shown, the method may include the following steps: S101. Receive the Head Node Broadcast Message Head_Announce, which is sent by the Head Node device (Head BMC device) in the Cluster.

[0040] In this embodiment of the invention, each Cluster includes a Head BMC device as a Head Node, several SMC devices, and an authorized switch for establishing communication between the Head BMC device and all SMC devices. The Head BMC device acts as the management brain of the Cluster, responsible for initiating device discovery, verifying SMC registration requests, negotiating session keys (Session_Key), issuing various types of management commands, summarizing the overall status of the Cluster, and connecting to the upper-layer management system from the north. SMC devices can be divided into various device types, including GPU SMC, storage SMC, and DPU SMC. The authorized switch is a secondary network device used to connect the Head BMC device and all SMC devices. The authorized switch has a pre-set private key and corresponding cryptographic algorithm module set by the user. It also stores and maintains a preset mapping table. The authorized switch can also parse the header of the Head Node broadcast message Head_Announce, thereby deeply participating in the interactive session process. It is responsible for port-based filtering, type verification, adding digital signatures, and implementing ACL rules for the Head Node broadcast message Head_Announce. The ACL rules prohibit cross-cluster registration and cross-device type propagation, achieving physical-level traffic isolation.

[0041] The default mapping table is a "Cluster-Port-Device Type" mapping table. This table contains the mapping relationships between the Cluster, the ports of the authorized switches, and the device types of the SMC devices, and is statically configured. The "Cluster-Port-Device Type" mapping table explicitly defines which ports connect to the Head BMC device, which ports connect to which type of SMC device, and which Cluster ID they belong to. For example, the "Cluster-Port-Device Type" mapping table could be: "Cluster A: Head connected to port P1; GPU SMC connected to port P2, Storage SMC connected to port P3, DPU SMC connected to port P4."

[0042] The GPU SMC continuously listens for the Head Announce broadcast message and registers in response to it. The GPU SMC reports the GPU model, quantity, serial number, device temperature, and fan speed to the Head BMC device. It can also perform GPU / BMC firmware upgrades and collect GPU core logs and encrypt and upload them to the Head BMC device. The storage SMC continuously listens for the Head Announce broadcast message and registers in response to it. The storage SMC reports storage capacity, interface type, RAID status, I / O throughput, and I / O utilization to the Head BMC device. It can also perform storage controller firmware upgrades and collect and encrypt storage I / O logs for uploading. The DPU SMC continuously listens for the Head Announce broadcast message and registers in response to it. The DPU SMC reports the DPU model, number of ports, bandwidth, error packet count, and connection status to the Head BMC device. It can also perform DPU / CPLD firmware upgrades and collect and encrypt DPU network logs before uploading them.

[0043] It should be noted that regardless of the type of SMC device, the BMC can store the Session Key, support northbound communication authorized by the Head BMC device, and receive and parse management commands of different types.

[0044] In this embodiment of the invention, the authorized switch, which acts as a connection bridge, receives the Head_Announce broadcast message from the head node and executes a series of subsequent steps.

[0045] S102. Parse the Head_Announce broadcast message of the head node according to the preset mapping table to determine the Cluster and port corresponding to the Head_Announce broadcast message. The preset mapping table is a "Cluster-Port-Device Type" mapping table.

[0046] In this embodiment of the invention, after the authorized switch receives the Head_Announce broadcast message sent by the Head BMC device, it queries the built-in mapping table and parses the Head_Announce broadcast message to obtain the Cluster_ID and Support_SMC_types fields. In this way, the authorized switch can parse the Cluster and port corresponding to the Head_Announce broadcast message.

[0047] S103. Use the corresponding port to forward the Head_Announce broadcast message from the Head node to the corresponding SMC device in the Cluster.

[0048] In this embodiment of the invention, since the mapping table specifies which ports connect to the Head BMC device, which ports connect to which type of SMC device, and which Cluster ID they belong to, and since ACL rules can be used to explicitly authorize switches to prohibit cross-cluster registration and cross-device type communication (for example, ACL rules can deny P1 port from interacting with P6-P8 ports, and deny P2 port from receiving storage SMC commands), the authorized switch will only use the corresponding port to forward the Head_Announce broadcast message to the corresponding SMC device of the corresponding device type in the corresponding Cluster. SMC devices of other device types cannot receive the Head_Announce broadcast message.

[0049] Assuming that the authorized switch parses the Head_Announce message and determines that the Head_Announce message is supported by SMC devices of all three device types (e.g., 0x010203 = GPU, storage, and DPU SMC devices are all supported), the authorized switch will determine three ports based on this parsing result. These three ports will forward the Head_Announce message to the GPU SMC, storage SMC, and DPU SMC, respectively.

[0050] S104. Receive the device greeting message SMC_Hello, where the device greeting message SMC_Hello is sent by the SMC device in the Cluster.

[0051] In this embodiment of the invention, SMC devices of various device types will generate a device greeting message SMC_Hello containing their own device type parameters in response to the Head_Announce broadcast message.

[0052] S105. Verify the device greeting message SMC_Hello according to the preset mapping table, and merge the verified device greeting message SMC_Hello with the generated switch authentication message Switch_Auth and forward it to the Head BMC device of the corresponding Cluster.

[0053] In this embodiment of the invention, SMC devices of various device types continuously monitor their management network ports to receive Head_Announce broadcast messages forwarded by the authorized switches. The SMC devices then parse the Head_Announce broadcast messages, extract the Cluster_id field, and determine their respective Clusters. The SMC devices then verify whether their own Cluster is consistent with their own Cluster and extract the Support_SMC_types field from the Head_Announce broadcast messages to determine whether the device types supported by the Head BMC device include their own type. For example, GPU SMC needs to confirm that Support_SMC_types contains 0x01.

[0054] After both of the above verifications are successful, the SMC device will construct the device greeting message SMC_Hello. During the construction of the device greeting message SMC_Hello, the SMC device will add the type parameter to the device greeting message SMC_Hello and generate the Auth_tag field using the device key of the SMC device.

[0055] In this embodiment of the invention, the Switch_Auth authentication message is a trusted credential for the network path, generated by an authorized switch acting as a trusted communication intermediary. It is the core of realizing the switch as a trusted communication intermediary and user-specified compatibility. After the message carrying the Switch_Auth authentication message is forwarded to the Head BMC device, the Head BMC device can confirm whether it is a message forwarded by an authorized switch and whether the SMC device type matches the mapping table.

[0056] The authorized switch can verify the SMC registration request, i.e. the device greeting message SMC_Hello, according to the device type, to ensure that the registration request of the corresponding SMC device can be forwarded to the Head BMC device of the corresponding cluster.

[0057] By merging the device greeting message SMC_Hello with the switch authentication message Switch_Auth before forwarding it to the HeadBMC device, network bandwidth can be effectively reduced and network traffic optimized.

[0058] S106. Receive the Head_Accept message and forward it to the corresponding SMC device according to the mapping table. The Head_Accept message is sent by the Head BMC device. After receiving the merged device greeting message SMC_Hello and the generated switch authentication message Switch_Auth, the Head BMC device first verifies the Switch_Auth message. If the first verification passes, it then verifies the device greeting message SMC_Hello. After both verifications pass, it negotiates the session key Session_Key according to the device type using the ECDH algorithm (different device types of SMC devices can generate different Session_Keys to improve security). It encrypts the Session_Key using the SMC's device public key, then constructs a Head_Accept message containing the encrypted Session_Key, Head signature, device type identifier, etc., and sends it to the authorized switch.

[0059] Specifically, the Head BMC device first parses the Switch_Auth authentication message, extracting fields such as auth_tag, port_id, and SMC_type. The auth_tag field in the Switch_Auth authentication message is generated by the authorized switch using the switch's private key. Unauthorized switches do not have a private key and cannot generate this field, i.e., a valid tag. The Head BMC device then verifies the auth_tag field using the switch's public key. If it is confirmed to be valid, it continues to verify whether the port_id and SMC_type fields match the mapping table. For example, the P2 port corresponds to the GPU SMC. Next, the Head BMC device parses the device greeting message SMC_Hello, extracting fields such as auth_tag, Nonce, timestamp, and SMC_type. The auth_tag field in the device greeting message SMC_Hello is generated by the SMC device using its private key. Different device types of SMC devices have different private keys. The Head BMC device then verifies the auth_tag field using its public key. If it is confirmed to be valid, it continues to verify whether the Nonce is in the blacklist to filter duplicate values, whether the timestamp is within its validity period (the validity period can be set to 30 seconds), and confirms whether the SMC_type field is within the device types supported by the Head BMC device based on the Head node broadcast message Head_Announce.

[0060] It should be noted that the Head BMC device of each cluster stores the device public keys corresponding to different device types of SMC devices, such as the GPU SMC public key, the storage SMC public key, and the DPU SMC public key.

[0061] In this embodiment of the invention, after the SMC device receives the Head_Accept message, it uses its private key to decrypt the encrypted session key (Session_Key) carried in the Head_Accept message, and then registers according to the Head_Accept message.

[0062] The device discovery method for satellite management components in a cluster, as described in this invention, utilizes a pre-defined mapping table and ACL rules of authorized switches within each cluster. Authorized switches can filter messages through their ports. When forwarding Head_Announce, SMC_Hello, Switch_Auth, and Head_Accept messages within the cluster, authorized switches effectively identify and distinguish between different clusters and SMC devices of different device types. This achieves physical-level traffic isolation, preventing cross-cluster registration and cross-device type propagation. It provides precise management throughout the entire process, from device discovery and registration to daily maintenance. Furthermore, as network devices establishing communication between Head BMC devices and various SMC devices within each cluster, authorized switches must possess user-authorized and supported switches and built-in switch private keys to participate in the interaction process, forming a trusted communication path. Forwarding is only permitted after verification by the authorized switch, enhancing the security of the interaction process. After powering on, BMC and SMC devices can automatically perform device discovery, authentication, and registration without manual configuration, reducing the deployment time of hundreds of devices from hours to minutes. The common header and TLV payload structure used in the Head Announce, SMC Hello, and Switch Auth messages significantly reduce message length, thus optimizing traffic during message forwarding and reducing network bandwidth consumption. The distributed architecture of the Cluster avoids the performance bottleneck of centralized servers. The BMC devices in each Cluster only handle registration requests from SMC devices within their own Cluster, which not only reduces CPU utilization to an extremely low level but also facilitates the management of thousands of Clusters and the construction of a dedicated compatibility ecosystem using the distributed structure.

[0063] In this embodiment of the invention, step S102 includes: S1021. Parse the Head Announce message of the head node, extract the Cluster to which it belongs from the common header and the supported device type from the TLV payload. The Head Announce message consists of a common header and a TLV payload.

[0064] Throughout the entire interaction process, the Head Announce broadcast message, the SMC Hello device greeting message, and the Switch Auth authentication message are all built on the Stateless Satellite Self-Discovery Protocol (SSDIP) structure, which adopts a "common header + TLV payload" structure.

[0065] In this embodiment of the invention, the common header in the stateless satellite self-discovery protocol structure uses a fixed 16-byte subheading, and all types of messages use this common header. The TLV payload varies according to the message type. More specifically, please refer to Table 1; the common header format is as follows: Table 1 Common Header Format

[0066] It can be seen that an identifier for the SMC device type has been added to the public header.

[0067] Please refer to Table 2. The TLV payload format in the Head_Announce broadcast message of the head node is as follows: Table 2. TLV payload format in header node broadcast messages

[0068] It can be seen that the Head_Announce broadcast message in the head node has added an SMC device type field and sub-type parameters to the TLV payload format.

[0069] Please refer to Table 3. The TLV payload format in the device greeting message SMC_Hello is as follows: Table 3. TLV payload format in device greeting messages

[0070] It can be seen that the TLV payload format in the device greeting message SMC_Hello is an SMC that is adapted to the different device types.

[0071] Please refer to Table 4. The TLV payload format in the Switch_Auth authentication message is as follows: Table 4. TLV payload format in switch authentication messages

[0072] It can be seen that the Switch_Auth authentication message has an SMC device type verification field set in the TLV payload format.

[0073] All message TLV payloads carry HMAC-SHA256 tags, allowing both the Head BMC device and authorized switches to verify message integrity via HMAC-SHA256 tags, preventing third-party tampering. Each communication generates a unique 3-byte Nonce, and the Head BMC device maintains a 30-second Nonce blacklist; messages with duplicate Nonces can be discarded.

[0074] In step S1021, the authorized switch parses the Head_Announce broadcast message sent by the Head BMC device, extracts the Cluster_id field from the common header to determine the Cluster to which it belongs, and extracts the Support_SMC_types field from the TLV load to determine the supported device types.

[0075] S1022. Based on the cluster to which it belongs and the supported device types, query the mapping table to determine the cluster and port corresponding to the header node broadcast message.

[0076] In this embodiment of the invention, after determining the cluster to which the message belongs and the supported device types, a mapping table is queried. This allows the determination of the Cluster corresponding to the Head_Announce broadcast message from the head node and which ports are needed for message forwarding. These ports correspond to the supported device types. For example, supported device types include GPU SMC and storage SMC. After querying the mapping table, it is determined that GPU SMC requires port P2 for forwarding, and storage SMC requires port P3 for forwarding. Therefore, the corresponding ports are the P2 and P3 ports of the authorized switch.

[0077] In this embodiment of the invention, step S105 includes: S1051. Parse the device greeting message SMC_Hello to determine the message source and the cluster authorization list.

[0078] In step S1051, the authorized switch parses the device greeting message SMC_Hello sent by the SMC device, extracts the Cluster_id field from the common header to determine the Cluster to which it belongs, and extracts the SMC_types field from the TLV load to determine the device type corresponding to the SMC device. The authorized port of the Cluster can be determined based on the Cluster to which it belongs and the mapping table, and the source of the message can be determined based on the device type.

[0079] If the SMC_types field cannot be extracted or cannot be matched with the mapping table, subsequent steps will not be executed, ensuring highly secure communication.

[0080] S1052. Determine whether the message source matches the port of the receiving device greeting message SMC_Hello based on the mapping table, and whether the port is in the cluster authorization list. This verifies the matching of the device type corresponding to the message source and the port. For example, the mapping table can determine that the P2 port of the authorized switch is only allowed to forward GPU SMC messages. This verifies whether the sending port of the SMC device matches its declared type.

[0081] S1053. After confirming that the port matches and that the port is in the cluster authorization list, use the switch private key to generate a switch authentication message Switch_Auth carrying the device type, and merge the device greeting message SMC_Hello of the same device type with the switch authentication message Switch_Auth and forward it to the corresponding Head BMC device in the Cluster.

[0082] Understandably, during the parsing of the device greeting message SMC_Hello, the authorized switch can determine the Head BMC device to be forwarded based on its Cluster.

[0083] The switch uses its own private key (Switch Private Key) to generate a Switch Authentication Message (Switch_Auth) carrying an auth_tag field. Then, it merges the verified device greeting messages (SMC_Hello) according to device type. For example, it merges the SMC_Hello messages sent by three GPU SMCs to reduce the number of times the Head BMC device receives the message, improving interaction efficiency. Finally, it forwards the merged SMC_Hello message and the Switch Authentication Message (Switch_Auth) to the corresponding Head BMC device in the cluster.

[0084] The Switch_Auth authentication message generated in this way is a signature of the authorized switch private key.

[0085] In this embodiment of the invention, after receiving the device greeting message SMC_Hello, the authorized switch can cache the device greeting message SMC_Hello so that it can subsequently merge device greeting messages SMC_Hello of the same device type, and then merge them with the switch authentication message Switch_Auth before forwarding them to the corresponding Head BMC device in the Cluster.

[0086] S1054. If it is determined that the port does not match or the port is not in the cluster authorization list, the device greeting message SMC_Hello is discarded directly.

[0087] In this embodiment of the invention, step S106 includes: S1061. Receive the Head Accept message from the Head node and parse it to extract the device type identifier contained therein. The Head Accept message contains the encrypted session key (Session_Key), Head signature, device type identifier, and other information.

[0088] S1062. Based on the device type identifier, the mapping table is queried to determine the port corresponding to the Head_Accept message received by the head node. The authorized switch can then determine which ports are needed for message forwarding based on the mapping table. These ports correspond to the device type identifiers. For example, if the device type identifiers include GPU SMC and Storage SMC, after querying the mapping table, it is determined that GPU SMC requires port P2 for forwarding, and Storage SMC requires port P3 for forwarding. Therefore, the corresponding ports are the authorized switch's P2 and P3 ports.

[0089] S1063. Forward the Head_Accept message to the corresponding SMC device of the corresponding device type according to the corresponding port.

[0090] Then, the Head_Accept message is forwarded to the corresponding SMC device using the corresponding port. The SMC device receives and responds to the Head_Accept message. The SMC device uses its own private key to decrypt the encrypted session key Session_Key to complete the registration. At the same time, the session key Session_Key can be stored for subsequent type-specific communication by the SMC device.

[0091] Due to the aforementioned technical problems, this invention provides a device discovery method for satellite management component devices in a cluster. The method aims to accurately isolate messages from different clusters and distinguish and identify SMC devices of different device types. It establishes a strong authentication, communication encryption, message integrity verification, and anti-replay attack mechanism from the SMC device to the Head BMC, ensuring high-strength communication security throughout the entire interaction process. This device discovery method for satellite management component devices in a cluster can be used in electronic devices, including but not limited to computers, mobile terminals, etc. Figure 2 This is an interaction timing diagram of the device discovery method for satellite management component devices in a cluster according to an embodiment of the present invention. Figure 3 This is a schematic diagram illustrating the process of applying the device discovery method for satellite management component devices in a cluster according to an embodiment of the present invention to a server, such as a Head Node in a Cluster. Figure 2 and Figure 3 As shown, the method may include the following steps: S201. Based on the preset stateless satellite self-discovery protocol structure, construct the head node broadcast message Head_Announce. The stateless satellite self-discovery protocol structure is also the interactive session message structure for establishing communication between the Head BMC device, SMC device, and authorized switches, such as... Figure 1 As shown in Tables 1 to 4 of the illustrated embodiment, the stateless satellite self-discovery protocol structure adopts a "common header + TLV payload" structure. Based on the stateless satellite self-discovery protocol structure, the head node broadcast message Head_Announce, the device greeting message SMC_Hello, and the switch authentication message Switch_Auth can be constructed.

[0092] S202. Periodically send Head Announce messages to the authorized switch, for example, broadcast Head Announce messages to the authorized switch once every 60 seconds.

[0093] In this embodiment of the invention, each Cluster includes a Head BMC device as a Head Node, several SMC devices, and an authorized switch for establishing communication between the Head BMC device and all SMC devices. The Head BMC device acts as the management brain of the Cluster, responsible for initiating device discovery, verifying SMC registration requests, negotiating session keys (Session_Key), issuing various types of management commands, summarizing the overall status of the Cluster, and connecting to the upper-layer management system from the north. SMC devices can be divided into various device types, including GPU SMC, storage SMC, and DPU SMC. The authorized switch is a secondary network device used to connect the Head BMC device and all SMC devices. The authorized switch has a pre-set private key and corresponding cryptographic algorithm module set by the user. It also stores and maintains a preset mapping table. The authorized switch can also parse the header of the Head Node broadcast message Head_Announce, thereby deeply participating in the interactive session process. It is responsible for port-based filtering, type verification, adding digital signatures, and implementing ACL rules for the Head Node broadcast message Head_Announce. The ACL rules prohibit cross-cluster registration and cross-device type propagation, achieving physical-level traffic isolation.

[0094] The default mapping table is a "Cluster-Port-Device Type" mapping table. This table contains the mapping relationships between the Cluster, the ports of the authorized switches, and the device types of the SMC devices, and is statically configured. The "Cluster-Port-Device Type" mapping table explicitly defines which ports connect to the Head BMC device, which ports connect to which type of SMC device, and which Cluster ID they belong to. For example, the "Cluster-Port-Device Type" mapping table could be: "Cluster A: Head connected to port P1; GPU SMC connected to port P2, Storage SMC connected to port P3, DPU SMC connected to port P4."

[0095] The GPU SMC continuously listens for the Head Announce broadcast message and registers in response to it. The GPU SMC reports the GPU model, quantity, serial number, device temperature, and fan speed to the Head BMC device. It can also perform GPU / BMC firmware upgrades and collect GPU core logs and encrypt and upload them to the Head BMC device. The storage SMC continuously listens for the Head Announce broadcast message and registers in response to it. The storage SMC reports storage capacity, interface type, RAID status, I / O throughput, and I / O utilization to the Head BMC device. It can also perform storage controller firmware upgrades and collect and encrypt storage I / O logs for uploading. The DPU SMC continuously listens for the Head Announce broadcast message and registers in response to it. The DPU SMC reports the DPU model, number of ports, bandwidth, error packet count, and connection status to the Head BMC device. It can also perform DPU / CPLD firmware upgrades and collect and encrypt DPU network logs before uploading them.

[0096] It should be noted that regardless of the type of SMC device, the BMC can store the Session Key, support northbound communication authorized by the Head BMC device, and receive and parse management commands of different types.

[0097] S203. Receive the merged and forwarded device greeting message SMC_Hello and switch authentication message Switch_Auth, and verify the switch authentication message Switch_Auth and the device greeting message SMC_Hello using the pre-stored switch public key respectively.

[0098] In this embodiment of the invention, SMC devices of various device types continuously monitor their management network ports to receive Head_Announce broadcast messages forwarded by the authorized switches. The SMC devices then parse the Head_Announce broadcast messages, extract the Cluster_id field, and determine their respective Clusters. The SMC devices then verify whether their own Cluster is consistent with their own Cluster and extract the Support_SMC_types field from the Head_Announce broadcast messages to determine whether the device types supported by the Head BMC device include their own type. For example, GPU SMC needs to confirm that Support_SMC_types contains 0x01.

[0099] After both of the above verifications are successful, the SMC device will construct the device greeting message SMC_Hello. During the construction of the device greeting message SMC_Hello, the SMC device will add the type parameter to the device greeting message SMC_Hello and generate the Auth_tag field using the device key of the SMC device.

[0100] Specifically, the Head BMC device first parses the Switch_Auth authentication message, extracting fields such as auth_tag, port_id, and SMC_type. The auth_tag field in the Switch_Auth authentication message is generated by the authorized switch using the switch's private key. Unauthorized switches do not have a private key and cannot generate this field, i.e., a valid tag. The Head BMC device then verifies the auth_tag field using the switch's public key. If it is confirmed to be valid, it continues to verify whether the port_id and SMC_type fields match the mapping table. For example, the P2 port corresponds to the GPU SMC. Next, the Head BMC device parses the device greeting message SMC_Hello, extracting fields such as auth_tag, Nonce, timestamp, and SMC_type. The auth_tag field in the device greeting message SMC_Hello is generated by the SMC device using its private key. Different device types of SMC devices have different private keys. The Head BMC device then verifies the auth_tag field using its public key. If it is confirmed to be valid, it continues to verify whether the Nonce is in the blacklist to filter duplicate values, whether the timestamp is within its validity period (the validity period can be set to 30 seconds), and confirms whether the SMC_type field is within the device types supported by the Head BMC device based on the Head node broadcast message Head_Announce.

[0101] It should be noted that the Head BMC device of each cluster stores the device public keys corresponding to different device types of SMC devices, such as the GPU SMC public key, the storage SMC public key, and the DPU SMC public key.

[0102] S204. If both the device greeting message SMC_Hello and the switch authentication message Switch_Auth are verified, negotiate the session key Session_Key according to the device type, and encrypt the session key Session_Key using the device public key corresponding to the device type.

[0103] In this embodiment of the invention, different device types can correspond to different session keys (Session_Key) to improve interaction security. The Head BMC device negotiates the session key (Session_Key) through the ECDH algorithm.

[0104] S205. Construct a Header Accept message containing the device type identifier based on the encrypted session key Session_Key, and send the Header Accept message to the authorized switch. The Header Accept message contains the encrypted session key Session_Key, Head signature, device type identifier, and other information.

[0105] The device discovery method for satellite management component devices in the cluster of the present invention, Head The Head_Announce message built by the BMC device carries the supported device types, enabling device discovery and triggering based on device type. It sequentially verifies the Switch_Auth authentication message using the pre-stored switch public key and the SMC_Hello device greeting message using the pre-stored device public key, improving device type compatibility and ensuring secure communication during the interaction process. Simultaneously, it negotiates and encrypts the Session_Key according to the device type, further enhancing the security of the interaction process. Through the pre-defined mapping table and ACL rules of the authorized switches within each cluster, the authorized switches can filter messages through their ports. When forwarding Head_Announce, SMC_Hello, Switch_Auth, and Head_Accept messages within the cluster, the authorized switches effectively identify and distinguish between different clusters and SMC devices of different device types, achieving physical-level traffic isolation and preventing cross-cluster registration and cross-device type propagation. This provides precise management throughout the entire process, from device discovery and registration to daily operation and maintenance. After powering on, BMC and SMC devices can automatically perform device discovery, authentication, and registration without manual configuration, reducing the deployment time of hundreds of devices from hours to minutes. The common header and TLV payload structure used in the Head Announce, SMC Hello, and Switch Auth messages significantly reduce message length, thus optimizing traffic during message forwarding and reducing network bandwidth consumption. The distributed architecture of the Cluster avoids the performance bottleneck of centralized servers. The BMC devices in each Cluster only handle registration requests from SMC devices within their own Cluster, which not only reduces CPU utilization to an extremely low level but also facilitates the management of thousands of Clusters and the construction of a dedicated compatibility ecosystem using the distributed structure.

[0106] In this embodiment of the invention, step S201 includes: S2011: Load the pre-configured Cluster UUID and supported device types. The Cluster UUID is the complete Cluster UUID.

[0107] S2012. Generate Nonce. A random Nonce, such as 0x987654, is generated each time the Head_Announce message is constructed.

[0108] S2013. Based on the Cluster's UUID, supported device types, Nonce, and pre-shared key with the authorized switch, and according to the preset interactive session message structure, construct the Head Announce broadcast message.

[0109] After the Head BMC device in the cluster is powered on, it can construct the Head Announce broadcast message. Understandably, during the construction of the Head Announce message, the Head BMC device will also obtain information such as the UTC timestamp.

[0110] In this embodiment, step S203 includes: S2031. Receive the merged and forwarded device greeting message SMC_Hello and switch authentication message Switch_Auth.

[0111] S2032. Parse the Switch authentication message Switch_Auth, extract fields such as auth_tag, port_id, and SMC_type from the Switch authentication message Switch_Auth, and then extract the first authentication message, the corresponding port, and the device type of the message source.

[0112] S2033. Verify the validity of the auth_tag field in the first authentication message, i.e. the switch authentication message Switch_Auth, using the switch's public key. The first authentication message is generated by the authorized switch using the switch's private key.

[0113] S2034. If the first authentication message is found to be valid, determine whether the corresponding port and the device type of the message source match the mapping table.

[0114] S2035. If it is determined whether there is a match with the mapping table, the device greeting message SMC_Hello is parsed, and the fields such as auth_tag, Nonce, timestamp, and SMC_type in the device greeting message SMC_Hello are extracted. Then, the second authentication message, the random number used once, the timestamp information, and the device type of the message source are extracted.

[0115] S2036. Based on the device type of the message source, schedule the device public key corresponding to the device type, and use the device public key to verify whether the auth_tag field in the second authentication message, i.e. the device greeting message SMC_Hello, is valid. The second authentication message is generated by the SMC device using the device private key.

[0116] Understandably, the SMC device generates the auth_tag field in the device greeting message SMC_Hello based on the device private key corresponding to its device type, which is also the generation of the second authentication message.

[0117] S2037. If the first authentication message is found to be valid, verify whether the random number used in a single instance is in a preset blacklist and whether the timestamp information is within its validity period.

[0118] S2038. If it is determined that the device is not on the blacklist and is within the validity period, determine whether the device type of the message source is among the supported device types.

[0119] In this embodiment, the method further includes the following steps: S206. Receive device status messages and update the overall cluster status according to the device type corresponding to the message source of the device status message. Then, synchronize the overall cluster status to the northbound system. The device status messages are reported by the SMC device and include abnormal status information, online rate information, health information, etc. Abnormal status data can be, for example, GPU temperature exceeding 85°C, storage utilization rate >90%, DPU port offline, etc.

[0120] In this embodiment of the invention, the Head BMC device communicates directly with the northbound system, reports the overall status of the cluster, and receives batch commands of different types issued by the northbound system, such as "upgrade all GPU SMC firmware". Correspondingly, each SMC device in the cluster needs authorization from the Head BMC device to communicate northbound.

[0121] More specifically, the SMC device sends a northbound access request to the Head BMC device. This request includes the device type and access purpose, such as "DPU SMC requires northbound transmission port configuration." After verifying the permissions of the northbound access request, the Head BMC device generates a temporary northbound communication token. This token contains the device type identifier and its validity period, and is then distributed to the corresponding SMC device. The SMC device, carrying this temporary northbound communication token, communicates with the northbound system through an authorized switch. The authorized switch verifies the device type and port matching in the temporary northbound communication token using a mapping table to ensure compliant communication. After successful verification, the SMC device communicates with the northbound system. When the northbound system receives data from the SMC device, it distinguishes the data type by the device type identifier, such as GPU asset data or storage performance data, thereby achieving categorized management.

[0122] SMC devices can periodically send device report messages SMC_Report, for example, every 30 seconds, and encrypt the device report messages SMC_Report using the session key (Session_Key) received and stored internally, thereby enabling device asset reporting based on device type.

[0123] The equipment assets of GPU SMC include, but are not limited to: GPU model (0x01=NVIDIA A100), quantity, serial number, and core temperature; The equipment assets of the storage SMC include, but are not limited to: storage capacity, interface type (0x02=SAS-4), RAID level, and utilization rate; The equipment assets of the DPU SMC include, but are not limited to: DPU model (0x03=Intel E2100), number of ports, bandwidth, and error packet count.

[0124] The Head BMC device can also distribute corresponding firmware according to the device type (such as GPU firmware, storage controller firmware) and perform fragmented transmission (1KB / fragment, including device type identifier and checksum). The SMC device performs the upgrade after verifying the device type match according to the device type identifier, and supports breakpoint resume. The Head BMC device can also issue log retrieval commands for different device types (such as "retrieve GPU core logs" and "retrieve storage IO logs"). The SMC device collects, compresses (LZ4), and encrypts the logs according to device type before uploading them in blocks. The Head BMC device forwards the logs to the northbound system. The log data also carries the device type identifier, which facilitates the northbound system to classify and store the logs.

[0125] The device discovery apparatus for satellite management component devices in a cluster provided in the embodiments of the present invention is described below. The device discovery apparatus for satellite management component devices in a cluster described below can be referred to in correspondence with the device discovery method for satellite management component devices in a cluster described above.

[0126] Due to the aforementioned technical problems, this invention provides a device discovery device for satellite management component devices in a cluster. The device aims to accurately isolate messages from different clusters and distinguish and identify SMC devices of different device types. It establishes a strong authentication, communication encryption, message integrity verification, and anti-replay attack mechanism from SMC devices to the Head BMC, ensuring high-strength communication security end-to-end throughout the entire interaction process. Figure 4 This is a schematic diagram of the device discovery device of the satellite management component device in the cluster according to an embodiment of the present invention, applied to a network device such as a switch. Figure 4 As shown, the device may include: The first receiving module 10 is used to receive the Head Announce broadcast message, which is sent by the Head BMC device (Head BMC device) that acts as the Head Node in the Cluster.

[0127] The first parsing module 20 is used to parse the Head_Announce broadcast message of the head node according to a preset mapping table to determine the Cluster and port corresponding to the Head_Announce broadcast message. The preset mapping table is a "Cluster-Port-Device Type" mapping table.

[0128] In this embodiment of the invention, after the authorized switch receives the Head_Announce broadcast message sent by the Head BMC device, it queries the built-in mapping table and parses the Head_Announce broadcast message to obtain the Cluster_ID and Support_SMC_types fields. In this way, the authorized switch can parse the Cluster and port corresponding to the Head_Announce broadcast message.

[0129] The first forwarding module 30 is used to forward the Head_Announce broadcast message from the Head node to the corresponding SMC device in the Cluster using the corresponding port.

[0130] In this embodiment of the invention, since the mapping table specifies which ports connect to the Head BMC device, which ports connect to which type of SMC device, and which Cluster ID they belong to, and since ACL rules can be used to explicitly authorize switches to prohibit cross-cluster registration and cross-device type communication (for example, ACL rules can deny P1 port from interacting with P6-P8 ports, and deny P2 port from receiving storage SMC commands), the authorized switch will only use the corresponding port to forward the Head_Announce broadcast message to the corresponding SMC device of the corresponding device type in the corresponding Cluster. SMC devices of other device types cannot receive the Head_Announce broadcast message.

[0131] The second receiving module 40 is used to receive the device greeting message SMC_Hello, which is sent by the SMC device in the Cluster.

[0132] In this embodiment of the invention, SMC devices of various device types will generate a device greeting message SMC_Hello containing their own device type parameters in response to the Head_Announce broadcast message.

[0133] The second forwarding module 50 is used to verify the device greeting message SMC_Hello according to the preset mapping table, and to merge the verified device greeting message SMC_Hello with the generated switch authentication message Switch_Auth and forward it to the Head BMC device of the corresponding Cluster.

[0134] In this embodiment of the invention, the Switch_Auth authentication message is a trusted credential for the network path, generated by an authorized switch acting as a trusted communication intermediary. It is the core of realizing the switch as a trusted communication intermediary and user-specified compatibility. After the message carrying the Switch_Auth authentication message is forwarded to the Head BMC device, the Head BMC device can confirm whether it is a message forwarded by an authorized switch and whether the SMC device type matches the mapping table.

[0135] The authorized switch can verify the SMC registration request, i.e. the device greeting message SMC_Hello, according to the device type, to ensure that the registration request of the corresponding SMC device can be forwarded to the Head BMC device of the corresponding cluster.

[0136] The third forwarding module 60 is used to receive the Head_Accept message and forward it to the corresponding SMC device according to the mapping table. The Head_Accept message is sent by the Head BMC device. After receiving the merged device greeting message SMC_Hello and the generated switch authentication message Switch_Auth, the Head BMC device first verifies the Switch_Auth message, then verifies the SMC_Hello message. If both verifications pass, it negotiates a session key (Session_Key) according to the device type using the ECDH algorithm (different SMC devices of different types can generate different Session_Keys to improve security). It encrypts the Session_Key with the SMC's public key, then constructs a Head_Accept message containing the encrypted Session_Key, Head signature, device type identifier, etc., and sends it to the authorized switch.

[0137] In this embodiment of the invention, after the SMC device receives the Head_Accept message, it uses its private key to decrypt the encrypted session key (Session_Key) carried in the Head_Accept message, and then registers according to the Head_Accept message.

[0138] The device discovery device for satellite management components in the cluster of this invention utilizes a pre-defined mapping table and ACL rules of the authorized switches within each cluster. The authorized switches can filter messages through their ports. When forwarding Head_Announce, SMC_Hello, Switch_Auth, and Head_Accept messages within the cluster, the authorized switches effectively identify and distinguish between different clusters and SMC devices of different device types. This achieves physical-level traffic isolation, preventing cross-cluster registration and cross-device type propagation. It provides precise management throughout the entire process, from device discovery and registration to daily maintenance. Furthermore, as the network device establishing communication between the Head BMC devices and various SMC devices in each cluster, the authorized switches must possess user-authorized and supported switches and built-in switch private keys to participate in the interaction process, forming a trusted communication path. Forwarding is only allowed after verification by the authorized switches, improving the security of the interaction process. After powering on, BMC and SMC devices can automatically perform device discovery, authentication, and registration without manual configuration, reducing the deployment time of hundreds of devices from hours to minutes. The common header and TLV payload structure used in the Head Announce, SMC Hello, and Switch Auth messages significantly reduce message length, thus optimizing traffic during message forwarding and reducing network bandwidth consumption. The distributed architecture of the Cluster avoids the performance bottleneck of centralized servers. The BMC devices in each Cluster only handle registration requests from SMC devices within their own Cluster, which not only reduces CPU utilization to an extremely low level but also facilitates the management of thousands of Clusters and the construction of a dedicated compatibility ecosystem using the distributed structure.

[0139] Due to the aforementioned technical problems, this invention provides a device discovery device for satellite management component devices in a cluster. The device aims to accurately isolate messages from different clusters and distinguish and identify SMC devices of different device types. It establishes a strong authentication, communication encryption, message integrity verification, and anti-replay attack mechanism from SMC devices to the Head BMC, ensuring high-strength communication security end-to-end throughout the entire interaction process. Figure 5 This is a schematic diagram illustrating the application of the device discovery method for satellite management component devices in a cluster according to an embodiment of the present invention to a server-side structure, such as a Head Node in a Cluster. Figure 5 As shown, the device may include: The message construction module 70 is used to construct the Head Announce broadcast message based on the preset stateless satellite self-discovery protocol structure. The stateless satellite self-discovery protocol structure is also the interactive session message structure for establishing communication between the Head BMC device, SMC device, and authorized switch. The stateless satellite self-discovery protocol structure adopts a "common header + TLV payload" structure. Based on the stateless satellite self-discovery protocol structure, the Head Announce broadcast message, the SMC_Hello device greeting message, and the Switch_Auth authentication message can be constructed.

[0140] The first sending module 80 is used to periodically send Head Announce messages to the authorized switch, for example, to broadcast Head Announce messages to the authorized switch once every 60 seconds.

[0141] The third receiving module 90 is used to receive the merged and forwarded device greeting message SMC_Hello and switch authentication message Switch_Auth, and sequentially verify the switch authentication message Switch_Auth using the pre-stored switch public key and verify the device greeting message SMC_Hello using the pre-stored device public key.

[0142] In this embodiment of the invention, SMC devices of various device types continuously monitor their management network ports to receive Head_Announce broadcast messages forwarded by the authorized switches. The SMC devices then parse the Head_Announce broadcast messages, extract the Cluster_id field, and determine their respective Clusters. The SMC devices then verify whether their own Cluster is consistent with their own Cluster and extract the Support_SMC_types field from the Head_Announce broadcast messages to determine whether the device types supported by the Head BMC device include their own type. For example, GPU SMC needs to confirm that Support_SMC_types contains 0x01.

[0143] After both of the above verifications are successful, the SMC device will construct the device greeting message SMC_Hello. During the construction of the device greeting message SMC_Hello, the SMC device will add the type parameter to the device greeting message SMC_Hello and generate the Auth_tag field using the device key of the SMC device.

[0144] The session negotiation module 100 is used to negotiate the session key Session_Key according to the device type after confirming that both the device greeting message SMC_Hello and the switch authentication message Switch_Auth have been verified, and to encrypt the session key Session_Key using the device public key corresponding to the device type.

[0145] In this embodiment of the invention, different device types can correspond to different session keys (Session_Key) to improve interaction security.

[0146] The second sending module 110 is used to construct a Header Accept message containing a device type identifier based on the encrypted session key Session_Key, and send the Header Accept message to the authorized switch. The Header Accept message contains the encrypted session key Session_Key, Head signature, device type identifier, and other information.

[0147] The device discovery apparatus for satellite management components in the cluster of the present invention, Head The Head_Announce message built by the BMC device carries the supported device types, enabling device discovery and triggering based on device type. It sequentially verifies the Switch_Auth authentication message using the pre-stored switch public key and the SMC_Hello device greeting message using the pre-stored device public key, improving device type compatibility and ensuring secure communication during the interaction process. Simultaneously, it negotiates and encrypts the Session_Key according to the device type, further enhancing the security of the interaction process. Through the pre-defined mapping table and ACL rules of the authorized switches within each cluster, the authorized switches can filter messages through their ports. When forwarding Head_Announce, SMC_Hello, Switch_Auth, and Head_Accept messages within the cluster, the authorized switches effectively identify and distinguish between different clusters and SMC devices of different device types, achieving physical-level traffic isolation and preventing cross-cluster registration and cross-device type propagation. This provides precise management throughout the entire process, from device discovery and registration to daily operation and maintenance. After powering on, BMC and SMC devices can automatically perform device discovery, authentication, and registration without manual configuration, reducing the deployment time of hundreds of devices from hours to minutes. The common header and TLV payload structure used in the Head Announce, SMC Hello, and Switch Auth messages significantly reduce message length, thus optimizing traffic during message forwarding and reducing network bandwidth consumption. The distributed architecture of the Cluster avoids the performance bottleneck of centralized servers. The BMC devices in each Cluster only handle registration requests from SMC devices within their own Cluster, which not only reduces CPU utilization to an extremely low level but also facilitates the management of thousands of Clusters and the construction of a dedicated compatibility ecosystem using the distributed structure.

[0148] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0149] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A device discovery method for satellite management component devices in a cluster, characterized in that, Applied to network devices, the method includes: Receive head node broadcast messages; head node broadcast messages are sent by the head node devices in the cluster. Each cluster contains one head node device, several satellite management component devices, and an authorized switch for communication between the head node device and all satellite management component devices. When the authorized switch forwards messages, cross-cluster registration and cross-device type propagation are prohibited. The head node broadcast message is parsed according to the preset mapping table to determine the cluster and port corresponding to the head node broadcast message; the mapping table contains the mapping relationship between the cluster to which it belongs, the port of the authorized switch, and the device type of the satellite management component device; The header node broadcast message is forwarded to the corresponding satellite management component device in the cluster using the corresponding port. Receive device greeting messages; device greeting messages are sent by the satellite management component device; The device greeting message is verified according to the preset mapping table, and the verified device greeting message is merged with the generated switch authentication message and forwarded to the head node device in the corresponding cluster. The head node receives the message and forwards it to the corresponding satellite management component device according to the mapping table; the head node receives the message and sends it.

2. The device discovery method for satellite management component devices in a cluster according to claim 1, characterized in that, The step of parsing the head node broadcast message according to a preset mapping table to determine the cluster and port corresponding to the head node broadcast message specifically includes: The header node broadcast message is parsed to extract the cluster to which it belongs from the common header and the supported device types from the type-length-value payload; the header node broadcast message consists of a common header and a type-length-value payload. Based on the cluster it belongs to and the supported device types, query the mapping table to determine the cluster and port corresponding to the header node's broadcast message.

3. The device discovery method for satellite management component devices in a cluster according to claim 1, characterized in that, The step of verifying the device greeting message according to a preset mapping table, and then merging the verified device greeting message with the generated switch authentication message and forwarding it to the corresponding head node device in the cluster, specifically includes: The device greeting message is parsed to determine the message source and the cluster authorization list; The mapping table is used to determine whether there is a match between the message source and the port of the receiving device greeting message, and whether the port is in the cluster authorization list. If the port matches and the port is in the cluster authorization list, a switch authentication message carrying the device type is generated using the switch private key. The device greeting message of the same device type is then merged with the switch authentication message and forwarded to the corresponding head node device in the cluster. The switch authentication message carries an auth_tag field, which is generated based on the switch private key. If it is determined that the port does not match or the port is not in the cluster authorization list, discard the device greeting message.

4. The device discovery method for satellite management component devices in a cluster according to claim 1, characterized in that, The receiving head node receives the message and forwards it to the corresponding satellite management component device according to the mapping table, specifically including: Receive the message from the header node, parse the message, and extract the device type identifier contained in the message. The mapping table is queried based on the device type identifier to determine the port corresponding to which the head node receives messages; The head node receives and forwards messages to the corresponding satellite management component device based on the corresponding port.

5. A device discovery method for satellite management component devices in a cluster, characterized in that, Applied to the server side, the method includes: Based on the preset stateless satellite self-discovery protocol structure, a header node broadcast message is constructed; the stateless satellite self-discovery protocol structure adopts a common header and TLV payload structure; Header node broadcast messages are periodically sent to the authorized switches; each cluster contains one head node device, several satellite management component devices, and an authorized switch for communication between the head node device and all satellite management component devices, and the authorized switches are prohibited from cross-cluster registration and cross-device type propagation when forwarding messages; Receive the merged and forwarded device greeting message and switch authentication message, and verify the switch authentication message and the device greeting message in sequence using the pre-stored switch public key and the pre-stored device public key, respectively. Once it is confirmed that both the device greeting message and the switch authentication message have passed verification, the session key is negotiated according to the device type, and the session key is encrypted using the device public key corresponding to the device type; different device types correspond to different session keys; Construct a header node accept message containing the device type identifier based on the encrypted session key, and send the header node accept message to the authorized switch.

6. The device discovery method for satellite management component devices in a cluster according to claim 5, characterized in that, The step of constructing a head node broadcast message based on a preset stateless satellite self-discovery protocol structure specifically includes: Load the pre-configured cluster's universally unique identifier and supported device types; Generate a single-use random number; Based on the cluster's universally unique identifier, supported device types, a single-use random number, and a pre-shared key with the authorized switch, and according to the preset interactive session message structure, a header node broadcast message is constructed.

7. The device discovery method for satellite management component devices in a cluster according to claim 5, characterized in that, The process of receiving and forwarding the merged device greeting message and the switch authentication message, and then sequentially verifying the switch authentication message using a pre-stored switch public key and verifying the device greeting message using a pre-stored device public key, specifically includes: Receive and merge forwarded device greeting messages and switch authentication messages; The switch authentication message is parsed to extract the first authentication message, the corresponding port, and the device type of the message source. The validity of the first authentication message is verified using the switch's public key; the first authentication message is generated by the authorized switch using the switch's private key. If the first authentication message is found to be valid, the corresponding port and the device type of the message source are determined according to the mapping table to see if they match the mapping table. If it is determined whether there is a match with the mapping table, the device greeting message is parsed to extract the second authentication message, the single-use random number, the timestamp information, and the device type of the message source. Based on the device type of the message source, the corresponding device public key is dispatched, and the device public key is used to verify whether the second authentication message is legitimate; the second authentication message is generated by the satellite management component device using the device private key. If the first authentication message is found to be valid, verify whether the random number used in a single instance is in a preset blacklist and whether the timestamp information is within its validity period. If it is determined that the device is not on the blacklist and is within the validity period, determine whether the device type of the message source is among the supported device types.

8. The device discovery method for satellite management component devices in a cluster according to claim 5, characterized in that, The method also includes the following steps: Receive device status messages, update the overall cluster status according to the device type corresponding to the message source, and synchronize the overall cluster status to the northbound system; device status messages are reported by the satellite management component devices and include abnormal status information, online rate information, and health information.

9. A device discovery device for satellite management component equipment in a cluster, characterized in that, Applied to network devices, the device includes: The first receiving module is used to receive head node broadcast messages. Head node broadcast messages are sent by the head node devices in the cluster. Each cluster contains one head node device, several satellite management component devices, and an authorized switch for communication between the head node device and all satellite management component devices. When the authorized switch forwards messages, cross-cluster registration and cross-device type propagation are prohibited. The first parsing module is used to parse the head node broadcast message according to the preset mapping table to determine the cluster and port corresponding to the head node broadcast message; the mapping table contains the mapping relationship between the cluster to which it belongs, the port of the authorized switch, and the device type of the satellite management component device; The first forwarding module is used to forward the head node broadcast message to the corresponding satellite management component device in the cluster using the corresponding port. The second receiving module is used to receive device greeting messages; the device greeting messages are sent by the satellite management component device. The second forwarding module is used to verify the device greeting message according to the preset mapping table, and to merge the verified device greeting message with the generated switch authentication message and forward it to the head node device in the corresponding cluster. The third forwarding module is used to receive the head node accept message and forward it to the satellite management component device of the corresponding device type according to the mapping table; the head node accept message is sent by the head node device.

10. A device discovery device for satellite management component equipment in a cluster, characterized in that, Applied to the server side, the device includes: The message construction module is used to construct the header node broadcast message according to the preset stateless satellite self-discovery protocol structure; the stateless satellite self-discovery protocol structure adopts a common header and TLV payload structure; The first sending module is used to periodically send head node broadcast messages to the authorized switches. Each cluster contains one head node device, several satellite management component devices, and an authorized switch for communication between the head node device and all satellite management component devices. The authorized switches are prohibited from cross-cluster registration and cross-device type propagation when forwarding messages. The third receiving module is used to receive the merged and forwarded device greeting message and switch authentication message, and sequentially verify the switch authentication message using the pre-stored switch public key and verify the device greeting message using the pre-stored device public key. The session negotiation module is used to negotiate a session key according to the device type after confirming that both the device greeting message and the switch authentication message have passed verification, and to encrypt the session key using the device public key corresponding to the device type; different device types correspond to different session keys; The second sending module is used to construct a header node accept message containing a device type identifier based on the encrypted session key, and send the header node accept message to the authorized switch.

Images