Network equipment multi-homing management method and system, electronic equipment, medium and program product

Abstract

The present disclosure provides a network device multi-homing management method, a network device multi-homing management system, an electronic device, a computer readable medium, and a computer program product, the network device multi-homing management method being applied to a tree hierarchy controller network comprising at least three levels of controllers, the method comprises the following steps: a network device establishes a first management channel with a first hierarchy controller in the tree hierarchy network; based on the establishment of the first management channel, synchronizing the registration information of the network equipment to at least one higher-level controller by the first-level controller; and carrying out collaborative management on the network equipment by the first-level controller and the at least one higher-level controller. According to the invention, collaborative management of the network equipment among the multi-level controllers is realized, registration information reporting and strategy issuing unification are supported, and reliability, flexibility and cross-domain strategy consistency of equipment management are improved.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of network management of software-defined wide area network, in particular to a network device multi-homing management method and system, an electronic device, a computer readable medium, and a computer program product. BACKGROUND

[0002] With the wide application of software-defined wide area network (SD-WAN) technology, the networking scale is continuously expanding, and the complexity of management and control is also increasing. The existing SD-WAN solutions mostly adopt a single-controller architecture, that is, a controller centrally configures, issues policies, and monitors the state of all customer premises equipment (CPE) in the system. When the network scale is small, this method can meet the basic needs, but in large-scale application scenarios, it gradually exposes its shortcomings. For example, the centralized control architecture has the risk of network large-area interruption caused by single-point failure of the control node; when facing a large number of devices, the policy issuing and management efficiency is low; the regulatory or compliance requirements of different regions are difficult to meet; at the same time, when the network scale continues to expand, the performance bottleneck problem of the centralized control architecture becomes more and more obvious. The above problems to some extent restrict the further promotion and application of SD-WAN technology in large-scale network environment. SUMMARY

[0003] The present disclosure provides a network device multi-homing management method and system, an electronic device, a computer readable medium, and a computer program product.

[0004] In a first aspect, the present disclosure provides a network device multi-homing management method applied to a tree-shaped hierarchical controller network including at least three levels of controllers, the method comprising: a network device establishing a first management channel with a first level controller in the tree-shaped hierarchical controller network; based on the establishment of the first management channel, synchronizing, by the first level controller, registration information of the network device to at least one higher level controller; and performing, by the first level controller and the at least one higher level controller, collaborative management on the network device.

[0005] In some embodiments, the network device establishes a first management channel with a first level controller in the tree-shaped hierarchical controller network, comprising: the network device sending a registration request to the first level controller, the registration request containing a device unique identifier and a geographical area code; and the first level controller completing the establishment of the first management channel after verifying that the geographical area code belongs to its jurisdiction.

[0006] In some embodiments, the registration request complies with a multi-homed device registration protocol.

[0007] In some embodiments, the multi-homing device registration protocol message includes a target controller hierarchy identifier, a device unique identifier, a geographical area code, a timestamp, and a message authentication code field.

[0008] In some embodiments, based on the establishment of the first management channel, synchronizing, by the first hierarchy controller, registration information of the network device to at least one higher hierarchy controller includes: forwarding, by the first hierarchy controller, a registration request of the network device to a second hierarchy controller that is a direct superior of the first hierarchy controller; querying, by the second hierarchy controller, a third hierarchy controller that is one level higher than the second hierarchy controller, for a global policy component applicable to the network device.

[0009] In some embodiments, after the second hierarchy controller queries the third hierarchy controller that is one level higher than the second hierarchy controller, for the global policy component applicable to the network device, includes: receiving, by the second hierarchy controller, a global policy template specific to the network device and a dynamic policy token from the third hierarchy controller; integrating, by the second hierarchy controller, the global policy template with a region-specific rule configured by the second hierarchy controller to generate a region-level policy configuration; and issuing, by the second hierarchy controller, the region-level policy configuration to the first hierarchy controller.

[0010] In some embodiments, after issuing the region-level policy configuration to the first hierarchy controller, includes: integrating, by the first hierarchy controller, the received region-level policy configuration with a local policy configured by the first hierarchy controller to generate a final policy; and issuing, by the first hierarchy controller, the final policy to the network device.

[0011] In some embodiments, the network device is managed by the first hierarchy controller and the at least one higher hierarchy controller in coordination, including: when the first hierarchy controller fails, the management of the network device is taken over by the second hierarchy controller or the third hierarchy controller based on the dynamic policy token held by the network device.

[0012] In some embodiments, the method further includes: the network device also directly registers with a higher hierarchy controller to directly receive a corresponding policy from the controller.

[0013] In some embodiments, the generation of the dynamic policy token includes: generating a random salt value; deriving a key based on a root key, the random salt value, and context information of the network device through a key derivation function; signing data including a device unique identifier and a timestamp using the key; and encoding data containing the random salt value and the signature to generate the dynamic policy token.

[0014] In a second aspect, the embodiments of the present disclosure provide a network device multi-homing management system, comprising: a plurality of network devices; and a plurality of controllers, the plurality of controllers are divided into a plurality of levels, comprising at least a first level, a second level and a third level, forming a tree-shaped hierarchical structure; wherein each of the plurality of network devices is configured to establish a first management channel with one of the plurality of controllers of the first level; the first level controller is configured to synchronize the registration information of the network device to at least one higher level controller based on the establishment of the first management channel; wherein the first level controller and the at least one higher level controller are cooperatively configured to jointly manage the network device.

[0015] In a third aspect, the embodiments of the present disclosure provide an electronic device, comprising: one or more processors; a memory having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement the network device multi-homing management method of the first aspect of the embodiments of the present disclosure.

[0016] In a fourth aspect, the embodiments of the present disclosure provide a computer readable medium having a computer program stored thereon, when the computer program is executed by a processor, the network device multi-homing management method of the first aspect of the embodiments of the present disclosure is implemented.

[0017] In a fifth aspect, the embodiments of the present disclosure provide a computer program product comprising a computer program or instructions, when the computer program or instructions are executed by a processor, the network device multi-homing management method of the first aspect of the embodiments of the present disclosure is implemented.

[0018] The present disclosure realizes the cooperative management of network devices among multiple levels of controllers, supports the unification of registration information reporting and policy distribution, and improves the reliability, flexibility and cross-domain policy consistency of device management. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 FIG. 1 is a flowchart of a network device multi-homing management method according to an embodiment of the present disclosure.

[0020] Figure 2 FIG. 2 is a block diagram of a network device multi-homing management system according to an embodiment of the present disclosure.

[0021] Figure 3 FIG. 3 is a multi-homed device registration flowchart according to an embodiment of the present disclosure.

[0022] Figure 4 FIG. 4 is a schematic diagram of an electronic device according to an embodiment of the present disclosure.

[0023] Figure 5Fig. 1 is a schematic diagram of a deployment architecture of a network device multi-homing management system according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0024] In order for those skilled in the art to better understand the technical solutions of the present disclosure, the technical solutions of the present disclosure will be described in detail below with reference to the drawings.

[0025] In the following, example embodiments will be described more fully with reference to the accompanying drawings, in which example embodiments can be embodied in different forms and should not be construed as being limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art.

[0026] In the case of no conflict, each embodiment of the present disclosure and each feature in the embodiments can be combined with each other.

[0027] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0028] The terms used herein are only used to describe specific embodiments and are not intended to limit the present disclosure. As used herein, the singular forms "a" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the terms "comprising" and / or "consisting of" when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0029] Unless otherwise defined, all terms used herein, including technical and scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted in an overly idealized or overly formal sense unless expressly so defined herein.

[0030] The present disclosure aims to solve the systemic problems caused by the single centralized controller architecture in large-scale SD-WAN networking. With the expansion of network size and the increase in the number of devices, traditional management solutions face challenges in reliability, efficiency, compliance, and scalability. The technical problems mainly solved by the present disclosure include: eliminating the single-point failure of the controller to avoid the risk of network paralysis; improving the efficiency of policy distribution and management in the scenario of a large number of CPE devices; meeting the compliance requirements of the controller in multi-region deployment; and breaking through the performance bottleneck of the control plane when the network size expands.

[0031] The core of the present disclosure is to construct a tree-level control architecture to realize high reliability and large-scale management of multi-homing CPE devices in SD-WAN. Specifically, the present disclosure mainly has the following technical capabilities: 1) By introducing a multi-homing device registration mechanism, a single CPE device can complete registration on multiple controllers at the same time, thereby accepting collaborative management from multiple controllers. This mechanism breaks through the limitations of traditional single-homing management and provides redundant management paths for devices.

[0032] 2) By deploying controllers according to geographical regions or logical management domains, the CPE devices in different regions are managed autonomously by the controllers in the region. This design can meet the compliance requirements of different countries or regions for local processing of data and control flow, and avoid compliance risks caused by centralized management across regions.

[0033] 3) By establishing a coordination mechanism between different level controllers, the upper level controller can take over the devices managed by the lower level controller. When a single point failure occurs in a level controller, its upper level controller can automatically or quickly take over its management functions to ensure the continuity of control of the CPE devices under its jurisdiction, thereby significantly improving the disaster recovery and fault recovery capabilities of the system.

[0034] 4) By decomposing and distributing global management tasks, large-scale management tasks such as network configuration, policy distribution, and state monitoring are distributed to independent controllers for parallel processing. This distributed management mode effectively distributes the management load, avoids the performance bottleneck of a single controller, and ensures the efficient operation of the system in a large-scale SD-WAN scenario.

[0035] 5) By supporting flexible expansion of controllers in a tree deployment architecture, the system can dynamically increase controller nodes or adjust the hierarchical structure according to the growth of network size. The tree control architecture includes at least a top-level controller, a regional controller, and an edge controller, forming a multi-level tree control relationship. This scalability ensures that the present disclosure can adapt to the continuous evolution and expansion needs of future networks.

[0036] The multi-homing device registration mechanism is a key technology for the tree-shaped hierarchical controller to cooperatively manage the CPE device. The mechanism supports a single CPE device to register with multiple different levels of superior controllers at the same time. Considering a typical application scenario: a large SD-WAN network divides the nationwide CPE device management system into a three-level hierarchical structure. The first level is the headquarters management center, the second level is the provincial management center of each province, and the third level is the management center of each city. Each level of management center deploys an independent controller management platform, and the architecture design allows the superior controller to take over the CPE devices managed by the subordinate controller under certain conditions such as failure. In order to realize this takeover capability and multi-level cooperative management function, the CPE must support multi-homing device registration.

[0037] Figure 1 is a flowchart of a network device multi-homing management method according to an embodiment of the present disclosure.

[0038] In a first aspect, with reference to Figure 1 The embodiment of the present disclosure provides a network device multi-homing management method, applied to a tree-shaped hierarchical controller network including at least three levels of controllers, and the method comprises the following steps: S11, a network device establishes a first management channel with a first level controller in the tree-shaped hierarchical network; S12, based on the establishment of the first management channel, the first level controller synchronizes the registration information of the network device to at least one higher level controller; S13, the first level controller and the at least one higher level controller cooperatively manage the network device.

[0039] In some embodiments, the network device establishes a first management channel with a first level controller in the tree-shaped hierarchical network, comprising: The network device sends a registration request to the first level controller, and the registration request contains a device unique identifier and a geographical area code; After the first level controller verifies that the geographical area code belongs to its jurisdiction, the establishment of the first management channel is completed.

[0040] In embodiments of the present disclosure, a network device (e.g., a CPE device) initiates a registration request to a nearest first-level controller (i.e., an edge controller). The registration request message complies with the format specification of a multi-homing device registration protocol (MCRP v2). The registration request carries at least the following key fields: a device unique identifier (Device UUID), used to uniquely identify the device in a multi-controller system; a geographic area code (GeoCode), used to indicate the physical or logical area where the device is located, for example, "CN-31-01" represents the Pudong area of Shanghai, China. When the first-level controller (edge controller) receives the registration request, it determines whether the device is within the area range under its jurisdiction according to the geographic area code. If the verification result shows that the geographic code of the device belongs to the management domain of the current controller, the controller confirms the home relationship of the device and establishes a secure first management channel with the device.

[0041] In some embodiments, the registration request complies with a multi-homing device registration protocol.

[0042] In some embodiments, the registration request includes a target controller level field for routing the message to a controller at a specified level.

[0043] In some embodiments, the registration request includes a timestamp and message authentication code field for secure authentication and anti-replay attack.

[0044] In some embodiments, the geographic area code is used for regional compliance verification or policy matching by the controller.

[0045] In embodiments of the present disclosure, a multi-homing device registration protocol (MCRP v2) is proposed and designed to solve the registration and management of CPE devices under a tree-like hierarchical control architecture. This protocol is specifically optimized for the structural characteristics of a multi-level controller system, and the design goals and protocol structure are described in detail below.

[0046] The design of the MCRP v2 protocol aims to achieve the following core goals: Multi-homing support: allows a single CPE device to register with multiple controllers at different levels (such as top-level, regional-level, and edge-level) simultaneously, establishing and maintaining multiple management channels.

[0047] Regional awareness: by introducing a geographic area code (Geo-Code) mechanism, the registration process of the CPE has location awareness, and can preferentially register with the controller of a specified geographic area according to preset policies, meeting compliance and management domain division requirements.

[0048] Secure authentication: provides a cryptographic device identity authentication mechanism for integrity verification and encryption protection of the registration communication process.

[0049] High efficiency synchronization: support the hierarchical strategy of the controller to issue, specifically, support the hierarchical, hierarchical policy synchronization and issue between the controller and the CPE.

[0050] To achieve the above design goals, MCRP v2 defines the following unified message format.

[0051] The message format of MCRP v2 protocol is as follows.

[0052] Field definition and explanation 1) Ver (4 bits): protocol version number Used to identify the protocol version. In this embodiment, the value "0010" indicates that the message follows the multi-homing device registration protocol version 2 (MCRP v2). In the future, when the protocol version evolves, other values of this field (such as "0011" for v3) will be used to distinguish. Among them, the high 2 bits are used to identify the major version number, and the low 2 bits are used to identify the minor version number.

[0053] 2) Type (4 bits): message type Used to identify the specific type of the message. The definition is as follows: 0x1: registration request (MCRP_REQUEST) 0x2: registration response (MCRP_RESPONSE) 0x3: heartbeat request (HEARTBEAT_REQ) 0x4: heartbeat response (HEARTBEAT_ACK) 0x5: policy update notification (POLICY_UPDATE) The remaining values are reserved values for future protocol function extension.

[0054] 3) Tier (4 bits): target controller level Indicates the target controller level of the CPE device registration or communication. The definition is as follows: 0x1: top controller (Root) 0x2: regional controller (Region) 0x3: edge controller (Edge) 0x4: multi-tier broadcast (Multi-tier) 4) Reserved (4 bits): reserved bits This field is a reserved field. The sender should set it to zero, and the receiver should ignore its content, and it is reserved for future protocol extension.

[0055] 5) Payload Length (16 bits): Payload Length The unit is byte length, excluding the header length.

[0056] 6) Device UUID (64 bits): Device Unique Identifier The format is: VendorID (16 bits) | Timestamp (32 bits) | Random (16 bits).

[0057] Among them, the Timestamp part can take the value of the time stamp when the device is first initialized.

[0058] 7) Geo-Code (32 bits): Geographical Area Code This field is used to identify the geographical location information of the CPE device or its site, and the format is defined as: Country (16 bits) | Region (8 bits) | POP (8 bits).

[0059] For example, the example code of China-Beijing-Haidian is 0x434E_424A_4844 (CN-BJ-HD).

[0060] 8) Timestamp (64 bits): Timestamp It uses nanosecond-level precision to represent the number of nanoseconds since UTC time 1970-01-01 00:00:00. It is used to identify the sending time of the message, and can be used to prevent replay attacks.

[0061] 9) HMAC-SHA256 (256 bits): Message Authentication Code The calculation range is from the Ver field to the Timestamp field.

[0062] This field is an authentication code calculated based on the HMAC-SHA256 algorithm, which is used to ensure the integrity and authenticity of the message.

[0063] The encryption key can be a pre-shared key (PSK) of the device, or a session key derived from a digital certificate private key. The specific key management method (such as pre-configuration, initialization negotiation or dynamic distribution) is not limited by the disclosure, and can be flexibly implemented according to the deployment requirements.

[0064] Through the design and implementation of the MCRP v2 protocol, the CPE device can complete registration on multiple hierarchical controllers simultaneously, thereby establishing a multi-path management channel, and providing a basic communication mechanism and security guarantee for multi-controller collaboration, upper controller takeover, and cross-domain redundancy management under a tree-shaped hierarchical control architecture.

[0065] In some embodiments, based on the establishment of the first management channel, the first hierarchical controller synchronizes registration information of the network device to at least one higher hierarchical controller, including: The first hierarchical controller forwards the registration request of the network device to a second hierarchical controller as its direct superior; The second hierarchical controller queries a third hierarchical controller one level higher for a global policy component applicable to the network device.

[0066] In the embodiments of the present disclosure, when the first hierarchical controller (e.g., an edge controller) successfully establishes the first management channel with the network device, the edge controller immediately starts an information synchronization process. First, the first hierarchical controller encapsulates the received network device registration request. To achieve efficient and reliable message routing between controller levels, the embodiments use a dedicated tunneling protocol (e.g., the LTP protocol) to encapsulate the request. After encapsulation, the first hierarchical controller forwards the encapsulated request to a second hierarchical controller (e.g., a regional controller) as its direct superior. Upon receiving the forwarding request from the lower level, the regional controller initiates a query to a third hierarchical controller (e.g., a top-level controller) one level higher, requesting a global policy component applicable to the specific network device. The third hierarchical controller dynamically filters, combines, and generates a global policy template customized for the device from the global policy library according to the context information of the network device (including but not limited to its device identifier, enterprise type, industry attribute, precise geographic location, etc.). This template contains basic and global policy elements applicable to the device, providing an authoritative basis for policy compilation by lower-level controllers.

[0067] In some embodiments, after the second hierarchical controller queries the third hierarchical controller one level higher for a global policy component applicable to the network device, including: The second hierarchical controller receives the network device-specific global policy template and dynamic policy token from the third hierarchical controller; The second hierarchical controller integrates the global policy template with region-specific rules configured by itself to generate a regional-level policy configuration; The regional-level policy configuration is delivered to the first hierarchical controller.

[0068] In the embodiments of the present disclosure, after the second level controller (the regional controller) inquires the third level controller (the top controller), the second level controller receives a specific global policy template dynamically generated by the third level controller for the network device and a dynamic security token bound with the device session. Then, the regional controller integrates the received global policy template with the regional specific rules stored in the regional controller to generate a regional level policy configuration. After the policy compilation, the second level controller distributes the regional level policy configuration to the first level controller. Meanwhile, the regional level policy configuration can also be cached locally in the regional controller.

[0069] In some embodiments, after the regional level policy configuration is distributed to the first level controller, the first level controller includes: The first level controller integrates the received regional level policy configuration with the local policy configured by the first level controller to generate a final policy; The first level controller distributes the final policy to the network device.

[0070] In the embodiments of the present disclosure, after the first level controller (the edge controller) receives the regional level policy configuration from the second level controller, the first level controller integrates the received regional level policy configuration with the local policy configured by the first level controller to generate a final policy for the network device. After the integration, the first level controller sends an MCRP response message to the network device, and the message includes the compiled final policy.

[0071] In some embodiments, the first level controller forwards the registration request of the network device to the second level controller as its direct superior, including: The registration request is encapsulated using a tunneling protocol; The encapsulated request is forwarded to the second level controller as its direct superior.

[0072] In the embodiments of the present disclosure, to ensure the efficiency and reliability of the transmission of the registration request between the controller levels, the first level controller (the edge controller) encapsulates the received original registration request using a dedicated tunneling protocol after completing the local verification. In a preferred embodiment of the present disclosure, the protocol is a specially designed LTP protocol, and the core design goal of the protocol is to provide a safe and reliable transmission channel for the control signaling between the controller levels. After the encapsulation, the first level controller forwards the encapsulated data unit to the second level controller (the regional controller) as its direct superior. It should be noted that in actual applications, any tunneling protocol that can achieve similar efficient and reliable information transmission function can be applied to the present disclosure.

[0073] In some embodiments, the network device is collaboratively managed by the first level controller and the at least one higher level controller, including: When the first level controller fails, the second level controller or the third level controller takes over the management of the network device based on the dynamic policy token held by the network device.

[0074] In the embodiments of the present disclosure, when the first level controller (edge controller) fails, causing the first management channel between the network device and the edge controller to be interrupted, the second level controller (area controller) or the third level controller (top controller) immediately starts a takeover process. The network device has held a dynamic policy token issued by a higher level controller and authenticated in a previous normal registration process. The token is a lightweight security credential of the device identity and authorized policy. When the device senses the disconnection with the edge controller, or when a higher level controller initiates a probe actively, the network device can establish a new secure management channel directly with the second level controller or the third level controller by virtue of the valid dynamic policy token held by the network device. After verifying the validity of the dynamic policy token, the higher level controller can confirm the legal identity of the device and the existing policy context, thereby seamlessly taking over the management function of the network device, including but not limited to policy issuing, state monitoring, and path control.

[0075] In some embodiments, the method further includes: The network device also directly registers with the higher level controller to directly receive the corresponding policy from the controller.

[0076] In the embodiments of the present disclosure, the network device has the capability of directly registering to a higher-level controller, such as direct second-level controller registration (direct area registration) and direct third-level controller registration (direct top-level registration). In the direct second-level controller registration, the network device initiates a direct registration request to the second-level controller (area controller). The request follows the same multi-homing device registration protocol as the registration request to the edge controller, but the target controller level field in the message is set to point to the area controller. After verifying the request, the second-level controller directly issues a corresponding exclusive area policy (such as the Yangtze River Delta optimization policy) to the network device, and the issuance of the policy does not need to pass through the first-level controller. This not only realizes flexible optimization of business, but also provides an effective escape channel when the edge controller fails collectively. In the direct top-level registration, for key devices in the network (such as headquarter core routers), it is necessary to ensure that they can obtain the most authoritative global security benchmark in any case. The network device initiates a direct registration request to the third-level controller (top-level controller). After completing a strict security handshake, the third-level controller directly issues a global policy and related security audit configuration to the network device. Among them, the global policy token issued will serve as a unified security credential for the device to access across areas within the entire network; and the security audit configuration issued ensures that all operations of the device meet the highest level of auditability and compliance requirements.

[0077] In some embodiments, the generation of the dynamic policy token includes: generating a random salt value; deriving a key based on a root key, the random salt value, and context information of the network device through a key derivation function; signing data containing the device unique identifier and the timestamp using the key; encoding data containing the random salt value and the signature to generate the dynamic policy token.

[0078] In the embodiments of the present disclosure, the dynamic policy token (DPT) is a core security component for implementing security authentication and authorization management of the MCRP v2 protocol. The DPT is not a one-time use token, and its validity period is defined by the system policy. It can be used for device registration and communication authentication in subsequent communication processes until the token expires or is updated.

[0079] The derivation of the DPT key is implemented by using the HMAC-based Key Derivation Function (HKDF) algorithm. Specifically, the key derivation mechanism includes the following points: Introduction of random salt value: A random salt value (salt) is generated, such as a random number of 16 bytes in length. The salt value is used to enhance the randomness of key derivation, ensuring that even under the same root key conditions, DPT keys generated by different sessions or different devices still have differences.

[0080] Root key binding with context: Key derivation takes the root secret as input, which can be securely stored in the top-level controller or high-security level key management server. In the derivation process, the HKDF algorithm introduces a context information parameter (info) in addition to the root key and salt value. This parameter is used to bind the device and protocol version information to avoid the risk of key reuse between different devices or protocols. For example, info can be set to "MCRPv2_DPT_Key" + UUID, where "MCRPv2_DPT_Key" represents the protocol version identifier and UUID represents the device unique identifier. By including both device identification and protocol context in the derivation input, it is ensured that the derived DPT key is only valid for a specific device and protocol version.

[0081] Key derivation process: Through the HKDF-SHA256 algorithm, the root secret (root_secret), random salt value (salt), and the above context information (info) are taken as input to derive the corresponding dynamic policy token key (DPT key, dpt_key).

[0082] This key derivation mechanism ensures the uniqueness and device binding of each generated DPT key, providing a secure foundation for subsequent token signature calculation.

[0083] The generation process of the dynamic policy token is as follows, and its pseudo-code implementation is as follows: def generate_dpt(root_secret, device_uuid, timestamp): # Step 1: Generate a random salt value (16 bytes) salt = secure_random(16) # Step 2: HKDF key derivation dpt_key = HKDF-SHA256( secret=root_secret,salt=salt, info=b"MCRPv2_DPT_Key" + UUID,length=32 ) # Step 3: Construct token data dpt_data = device_uuid + to_bytes(timestamp) Step 4: Calculate HMAC signature signature = hmac_sha256(dpt_key, dpt_data) Step 5: Base64 encoding return base64url_encode(salt + signature)[:32] Detailed description of each step is as follows: Step 1 (Generate random salt value): Generate a 16-byte random number as a salt value (salt) to provide an independent random source for each token generation; Step 2 (HKDF key derivation): Derive the DPT key (dpt_key) by the HKDF-SHA256 algorithm with the root key (root_secret), the random salt value (salt), and the context information (info) concatenated by the protocol identifier and the device UUID as input; Step 3 (Construct token data): Concatenate the device identifier (UUID) and the timestamp (timestamp) to form the token data (dpt_data); Step 4 (Calculate HMAC signature): Perform HMAC-SHA256 operation on the token data (dpt_data) constructed in step 3 using the dynamic policy token key (dpt_key) derived in step 2 to generate the key-based message authentication code (i.e. HMAC signature (signature)); Step 5 (Base64 encoding): Concatenate the random salt value (salt) and the HMAC signature (signature), then perform Base64 URL safe encoding on the concatenated data. Finally, the first 32 characters of the encoded string are taken as the officially published dynamic policy token (DPT).

[0084] The dynamic policy token (DPT) generated by the present disclosure has the following technical effects: 1) By carrying the encrypted and signed policy state information in the token, the traditional session state maintenance mechanism is replaced, thereby reducing the state storage and management overhead of the controller side; 2) Since the DPT can be independently verified and parsed by each controller, the state synchronization operation between the controller cluster is avoided, significantly reducing the consistency maintenance burden in the distributed system; 3) The verifiable nature of DPT enables seamless migration of devices between multiple controllers, ensuring policy continuity and access security. DPT not only enhances the security of the "MCRPv2" protocol, but also provides an extensible and high-performance security foundation framework for large-scale device access and policy distribution.

[0085] In the embodiments of the present application, the generation of the DPT key adopts the HKDF-SHA256 algorithm. It should be noted that the gist of the present disclosure is not the algorithm itself, but the key derivation combined with the device unique identifier (UUID) and the protocol context, and used for the secure construction of the dynamic policy token, so as to realize the replacement of the traditional session state and the stateless migration between controllers.

[0086] In some embodiments, the verification of the dynamic policy token comprises: extracting a random salt value from the dynamic policy token; deriving a key based on the same root key, the random salt value and the context information of the network device by the same key derivation function; generating a signature by calculating data containing the device unique identifier and the timestamp using the key; comparing the generated signature with the signature in the dynamic policy token; if the comparison is consistent, the verification is passed.

[0087] In the embodiments of the present disclosure, when the controller receives the dynamic policy token (DPT) uploaded by the device, the following verification process is performed: extracting a salt value: the first 16 bytes in the token are extracted as a random salt value (salt), which is used in the subsequent key derivation process; re-deriving a key: the controller uses the same root key (root_secret) and context parameters (info = b"MCRPv2_DPT_Key"+UUID) as in the token generation stage, and combines the extracted salt to re-calculate and derive a key (dpt_key) by the HKDF-SHA256 algorithm; calculating a signature: the device unique identifier (UUID) and the timestamp are spliced to form the data to be verified (dpt_data), and the dpt_key re-calculated is used to perform the HMAC-SHA256 operation on the dpt_data to generate a local signature; signature comparison and verification result: the controller compares the generated local signature with the signature contained in the DPT; if the two match, it is considered that the token verification is successful, and the device authentication is passed; if they do not match, it is determined that the token is invalid, and the authentication fails.

[0088] The DPT technology of the present disclosure has the following innovative features: stateless design: the controller does not need to maintain a token database, and the token can be independently verified at any controller node; Time binding mechanism: the token contains timestamp information, which can effectively prevent replay and support token expiration policy; Device binding mechanism: the token is bound to a specific device through UUID and cannot be used across devices; Forward security: a different random salt value is used to generate a token each time, so even if a key or token is leaked, it will not affect the security of historical or future tokens.

[0089] Through the above mechanisms, the dynamic policy token (DPT) technology realizes an efficient cross-control layer authentication mechanism, which ensures security while avoiding the state storage overhead of traditional centralized authentication mechanisms, and provides unified security support for the MCRP v2 protocol under a layered architecture.

[0090] Figure 2 is a block diagram of a network device multi-homing management system according to an embodiment of the present disclosure.

[0091] In a second aspect, referring to Figure 2 The present embodiment provides a network device multi-homing management system, comprising: a plurality of network devices; and a plurality of controllers, which are divided into multiple levels, including at least a first level, a second level and a third level, forming a tree-like hierarchical structure; Each of the plurality of network devices is configured to establish a first management channel with one of the plurality of controllers of the first level. The first level controller is configured to synchronize the registration information of the network device to at least one higher level controller based on the establishment of the first management channel. The first level controller and the at least one higher level controller are configured to jointly manage the network device.

[0092] In some embodiments, the network device is further configured to send a registration request to the first level controller, the registration request containing a device unique identifier and a geographic area code. The first level controller is further configured to verify that the geographic area code belongs to its jurisdiction to complete the establishment of the first management channel.

[0093] In some embodiments, the registration request complies with a multi-homed device registration protocol.

[0094] In some embodiments, the multi-homed device registration protocol message contains target controller level identifier, device unique identifier, geographic area code, timestamp and message authentication code fields.

[0095] In some embodiments, the first level controller is further configured to forward the registration request of the network device to a second level controller as its direct superior; and the system further comprises the second level controller configured to query a third level controller for a global policy component applicable to the network device.

[0096] In some embodiments, the second level controller is further configured to: receive the network device specific global policy template and the dynamic policy token from the third level controller; integrate the global policy template with region specific rules configured by itself to generate a region level policy configuration; and issue the region level policy configuration to the first level controller.

[0097] In some embodiments, the first level controller is further configured to integrate the received region level policy configuration with local policies configured by itself to generate a final policy, and issue the final policy to the network device.

[0098] In some embodiments, the second level controller or the third level controller is further configured to take over the management of the network device based on the dynamic policy token held by the network device when the first level controller fails.

[0099] In some embodiments, the network device is further configured to directly register with a higher level controller to directly receive a corresponding policy from the controller.

[0100] In some embodiments, the third level controller is configured to generate the dynamic policy token by: generating a random salt value; deriving a key by a key derivation function based on a root key, the random salt value, and context information of the network device; signing data containing a device unique identifier and a timestamp using the key; and encoding data containing the random salt value and the signature to generate the dynamic policy token.

[0101] In some embodiments, the second level controller or the third level controller is configured to verify the dynamic policy token by: extracting a random salt value and a first signature from the dynamic policy token; deriving a verification key by a same key derivation function based on a same root key, the random salt value, and context information of the network device; calculating a second signature using the verification key on data containing the device unique identifier and the timestamp; and comparing the second signature with the first signature, and verifying if they are consistent.

[0102] Figure 3 is a multi-homing device registration process diagram of an embodiment of the present application. In combination with Figure 3As shown, the MCRP v2 registration process proposed by the present disclosure adopts a hierarchical processing mechanism, and realizes the step-by-step registration, authentication and policy distribution of devices through the cooperation of three levels. The process is executed step by step in the order of the first stage (edge registration), the second stage (direct regional registration) and the third stage (direct top-level registration).

[0103] First stage: edge registration (main process) 1. The terminal device initiates a request. As shown, Figure 3 As shown, the CPE device first sends an MCRP registration request to its nearest edge controller. The message follows the MCRP v2 protocol format and contains necessary fields such as device unique identifier (Device UUID) and geographic code (Geo-Code, such as CN-31-01 represents Shanghai Pudong, China).

[0104] 2. Edge controller processing. After receiving the request, the edge controller verifies whether the geographic code is within its jurisdiction, encapsulates the registration request (LTP encapsulation: registration request + local certificate) through the LTP protocol, and forwards it to the upper regional controller to realize efficient and reliable message transmission between controller levels.

[0105] 3. Regional controller coordination. After receiving the encapsulated request, the regional controller queries the top-level controller for the global policy components applicable to the target device. The top-level controller filters and combines relevant policy components from the global policy library based on the device's enterprise type, industry attribute and geographic location, generates a corresponding device-specific policy template and issues it. The regional controller receives the policy template and dynamic security token DPT returned by the top-level controller.

[0106] 4. Policy compilation. The regional controller receives the policy template generated based on the global policy from the top-level controller and integrates it with the regional-specific rules stored in the region. The regional-specific rules adopt a hybrid design pattern of "part common + part customized", and the applicability hierarchy includes: ① global applicable rules, used to ensure basic network optimization and regional compliance requirements; ② conditional applicable rules, effective for specific CPE subsets based on business type, criticality, etc.; ③ classification applicable rules, effective for specific device categories or role groups. This hierarchical design realizes the balance of regional policy in consistency, flexibility, scalability and performance optimization. After integration, the regional controller generates regional-level policy configuration, i.e. the specific configuration data obtained by fusing the global policy template and regional-specific rules, which can be directly issued to lower-level controllers or CPE devices.

[0107] 5. Final Configuration Deployment. The edge controller receives the region-level policy configuration from the region controller and integrates it with the local policy stored locally to generate the edge-level policy configuration. The local policy adopts a hybrid mode of "basic general + service group + device specific" to achieve the most granular configuration. After the edge-level policy configuration is verified, it is deployed to the corresponding CPE device via MCRP (Management Configuration Response Protocol) response message to achieve the final policy activation and deployment.

[0108] Phase Two: Direct Regional Registration 6. In some network topologies, CPE devices can directly send MCRP requests to the area controller to complete registration and policy acquisition. Similar to the registration process in step (1), the Tier field of the MCRP request message is set to 0x2, indicating that its target control layer is the area controller. After receiving the request, the area controller obtains the exclusive area policy applicable to the CPE according to the service type or device group, generates the corresponding MCRP response message, and sends it to the CPE device to enable it to complete the loading and activation of the policy.

[0109] 7. Regional-level response. The regional controller directly issues the dedicated regional policies. This process does not require the edge controller to relay the policies. Through this mechanism, the system can achieve rapid policy delivery and redundant backup of the control plane in scenarios such as edge controller failure or cross-regional business optimization.

[0110] Phase 3: Direct Top-Level Registration 8. Terminal devices connect directly to the top-level device. For example... Figure 3 As shown at the bottom, critical devices can directly initiate a registration request (MCRP request, device ID, geocode) to the top-level controller, with its Tier field pointing to the top-level controller. After responding to the request, the top-level controller directly issues a global policy token (i.e., a dynamic security token (DPT)) and security audit configuration to the device. The security audit configuration is used for network-wide operation tracking and compliance auditing.

[0111] 9. Global Policy Issuance. The top-level controller directly issues global policy tokens, which are used for cross-region security authentication, and security audit configurations are used for cross-region security auditing. Through the dynamic distribution and verification of these tokens, the transmission and execution of global policies are achieved.

[0112] This mechanism can reduce the registration latency in typical scenarios from more than 2 seconds in traditional architecture to less than 300 milliseconds, while ensuring high reliability and scalability of the system in cross-level registration and large-scale device management scenarios.

[0113] The present disclosure adopts a hierarchical registration mechanism, the first stage (edge registration) focuses on "near control". The edge controller directly serves the local CPE device, and realizes the localization of high-frequency operation processing. By shortening the control path, the registration delay is reduced from more than 2 seconds in the traditional architecture to within about 300 ms, and at the same time, a fault isolation mechanism is formed in the architecture. When a certain edge node fails, the network services in other areas are not affected, thereby significantly improving the reliability and service continuity of the system. The second stage (regional registration) can realize "service optimization". The regional controller faces the cross-regional service scenario, and realizes the global collaborative optimization of network performance by providing regional-level service strategies (such as direct connection optimization strategies for financial services). At the same time, this stage establishes an emergency channel across the edge, and when the local edge controller is unavailable, the device can still maintain the controlled state through the regional controller, ensuring that the service does not be interrupted. The third stage (top-level registration) ensures the "security bottom line". Only a small number of high-security level devices (such as headquarter core routers) are open to this registration channel. Even in the case of large-scale failure of regional controllers, the direct reach of security policies and audit commands can still be maintained through the top-level control channel, ensuring the safety controllability of the system in extreme cases.

[0114] In summary, the hierarchical registration and control mechanism not only realizes low-latency access, but also takes into account regional service optimization and global security protection, and builds a three-dimensional collaborative network management system of performance, service and security.

[0115] Figure 4 FIG. 1 is a schematic diagram of an electronic device according to an embodiment of the present disclosure.

[0116] In a third aspect, referring to Figure 4 An electronic device is provided, which includes: one or more processors 401; a memory 402 having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement the network device multi-homing management method of any one of the above; one or more I / O interfaces 403 connected between the processor and the memory, configured to realize the information interaction of the processor and the memory.

[0117] Among them, processor 401 is a device with data processing capabilities, including but not limited to central processing unit (CPU); memory 402 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH); I / O interface (read-write interface) 403 is connected between processor 401 and memory 402, and can realize information interaction between processor 401 and memory 402, including but not limited to data bus (Bus).

[0118] In some embodiments, the processor 401, memory 402, and I / O interface 403 are interconnected via bus 404, and thus connected to other components of the computing device.

[0119] Fourthly, embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements any of the above-described network device multi-homing management methods.

[0120] Fifthly, embodiments of this disclosure provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement any of the above-described network device multi-homing management methods.

[0121] To enable those skilled in the art to more clearly understand the technical solutions provided by the embodiments of this disclosure, the technical solutions provided by the embodiments of this disclosure will be described in detail below through specific embodiments: Example 1 To more clearly illustrate the technical solution of this invention, the following explanation is based on an example of SD-WAN networking in a large, cross-regional enterprise.

[0122] Figure 5 This is a schematic diagram of the deployment architecture of the network device multi-homing management system according to an embodiment of the present disclosure in a practical application.

[0123] like Figure 5 As shown, this system adopts a tree-like hierarchical control structure, including: a top-level controller located in Beijing (national control layer); regional controllers located in Shanghai and Guangzhou, responsible for the East China and South China regions respectively; and edge controllers distributed in Hangzhou, Nanjing, Shenzhen, Xiamen, and other locations. This network connects CPE devices of branch offices in different geographical locations such as Shanghai, Hefei, Dongguan, and Xiamen, demonstrating the multi-homing registration of devices and the hierarchical policy distribution path.

[0124] This example demonstrates a scenario where a large enterprise deploys this system to achieve unified, efficient, and compliant management of CPE devices across its branches nationwide.

[0125] As Figure 5 shown in FIG. 1, the CPEs of Shanghai branch, Hefei branch and Dongguan branch respectively initiate a registration request to the edge controller of the corresponding region through the MCRP protocol, forming a cross-regional, multi-level registration and policy distribution process.

[0126] Shanghai branch device registration process (1) Shanghai office CPE registers with Hangzhou edge controller The Shanghai office CPE selects the Hangzhou edge controller as the access point for registration based on network performance indicators (including latency, bandwidth, packet loss rate, etc.) (reflecting the principle of proximity access in the actual network topology). The registration message contains geographic coding information Geo-Code: CN-31-01 (China-Shanghai-Huangpu District), which is used to identify the geographic location of the device.

[0127] (2) Regional policy distribution After completing the registration and authentication, the Hangzhou edge controller synchronizes the device information to the Shanghai regional controller. The regional controller matches and distributes East China exclusive policies, such as optimized paths to access certain data centers, from the multiple sub-regional policy configurations stored in it according to the Geo-Code and device attributes.

[0128] (3) National policy coordination The Shanghai regional controller requests global policies from the Beijing top-level controller. The top-level controller returns national unified security policies, such as "Network Security Law" compliance configuration, Level 2.0 basic security requirements, and national branch interconnection policies.

[0129] (4) South China regional linkage The CPE of Dongguan branch initiates registration with Shenzhen edge controller, which synchronizes the registration information to Guangzhou regional controller. The Guangzhou regional controller applies the Guangdong-Hong Kong-Macao Greater Bay Area exclusive policy, such as Shenzhen-Hong Kong dedicated line priority routing, Guangdong-Hong Kong-Macao data cross-border compliance settings, and supports Tencent Cloud Shenzhen node access optimization.

[0130] (5) Multi-level registration example The CPE of Hefei branch registers with Nanjing edge controller (edge layer). The CPE of Hefei branch directly registers with Shanghai regional controller to obtain Yangtze River Delta regional policies. The regional controller internally stores multiple sub-regional policy configurations and can distribute different regional policies according to the geographic location (Geo-Code) and device attributes of the CPE. Key devices can also register with the Beijing top-level controller to obtain security audit tokens, enabling national unified security monitoring.

[0131] The Xiamen office CPE registers to the Xiamen edge controller, and at the same time, registers to the Guangzhou regional controller to obtain the Taiwan Strait line optimization strategy, which is used to optimize the cross-sea communication link from Xiamen to Taiwan.

[0132] This embodiment shows that the present disclosure realizes cross-regional strategy coordination and performance optimization through a tree-level controller structure and a multi-homing registration mechanism, can flexibly issue exclusive strategies according to the device registration location and network attributes, and at the same time, ensures global security and compliance control through the top-level controller.

[0133] The tree-level controller-based SD-WAN device multi-homing management method and system provided by the present disclosure at least have the following beneficial effects: 1) Improve system reliability: through the cooperative work of multi-level controllers, the risk of network paralysis caused by single point failure in the traditional centralized control architecture is avoided, and the fault tolerance and system stability of the control plane are significantly enhanced; 2) Improve the efficiency of policy distribution: the hierarchical and domain-based policy management and distribution mechanism is adopted, so that the controller can realize hierarchical scheduling and local response when processing a large number of devices, effectively solving the problem of low efficiency of policy distribution under centralized control; 3) Meet the regional compliance requirements: the controller architecture supports independent policy control and data isolation according to regions, and can meet the compliance requirements of network control and data management in different countries or regions; 4) Good scalability: when the network scale expands or the number of devices significantly increases, horizontal expansion can be realized by increasing the number of controller nodes, thereby eliminating the performance bottleneck of the control plane and ensuring the continuous high-performance operation of the system.

[0134] The present disclosure mainly constructs a tree-level controller-based SD-WAN device multi-homing management system, and the technical key points mainly include the following aspects: 1) Multi-homing device registration mechanism: a registration scheme supporting device multi-homing is provided, so that the same device can belong to multiple regional controllers at the same time, realizing cross-regional independent management and control. This mechanism supports handover and migration between cross-level controllers, avoids the management bottleneck of a single controller, and improves the flexibility and reliability of the system.

[0135] 2) Multi-homing device registration protocol: a device registration protocol based on multi-dimensional information is designed, which realizes trusted verification of device access identity through comprehensive verification of parameters such as timestamp, network address information and device unique identifier (UUID), thereby effectively reducing the risk of illegal access and fake registration.

[0136] 3) Dynamic Policy Token (DPT) technology: a dynamic generated policy token mechanism is proposed, the token contains timestamp information to prevent replay attacks, and is bound based on the device unique identifier (UUID), so that the token cannot be reused between different devices, thereby further enhancing the security and uniqueness of the control instruction issuing and policy synchronization process.

[0137] Those of ordinary skill in the art will understand that all or some of the steps in the methods disclosed above, the functional modules / units in the systems and devices can be implemented as software, firmware, hardware and appropriate combinations thereof. In hardware implementation, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component can have multiple functions, or one function or step can be performed by several physical components in cooperation. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor or a microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software can be distributed on a computer readable medium, which can include computer storage media (or non-transitory media) and communication media (or transitory media). As is well known to those of ordinary skill in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those of ordinary skill in the art that communication media typically includes computer readable instructions, data structures, program modules or other data in modulated data signals such as carrier waves or other transport mechanisms, and can include any information delivery medium.

[0138] Example embodiments have been disclosed herein and, although the use of specific terms is exemplified throughout, they are used in an illustrative sense only and should not be construed as limiting. In some instances, it will be apparent that features, characteristics or / and elements described in connection with a particular embodiment can be used in conjunction with other embodiments unless otherwise explicitly stated, or unless it would be obvious based on a consideration of the function of those elements in the context of a particular embodiment that those elements should or should not be used in that context. Accordingly, it will be understood that various forms and details of the disclosure can be made without departing from the scope of the disclosure or the spirit that it purports to promote.

Claims

1. A method for managing multiple affiliations of network devices, applied to a tree-structured hierarchical controller network including at least three levels of controllers, the method comprising: The network device establishes a first management channel with the first-level controller in the tree-structured hierarchical controller network; Based on the establishment of the first management channel, the first-level controller synchronizes the registration information of the network device to at least one higher-level controller. The network device is managed collaboratively by the first-level controller and the at least one higher-level controller.

2. The network device multi-homing management method according to claim 1, wherein, The network device establishes a first management channel with the first-level controller in the tree-structured hierarchical controller network, including: The network device sends a registration request to the first-level controller, the registration request including a unique device identifier and a geographic region code; After the first-level controller verifies that the geographic area code belongs to its jurisdiction, it completes the establishment of the first management channel.

3. The network device multi-homing management method according to claim 2, wherein, The registration request follows the multi-homed device registration protocol.

4. The network device multi-homing management method according to claim 3, wherein, The multi-homed device registration protocol message includes the target controller level identifier, device unique identifier, geographic area code, timestamp, and message authentication code fields.

5. The network device multi-homing management method according to any one of claims 1-4, wherein, Based on the establishment of the first management channel, the first-level controller synchronizes the registration information of the network device to at least one higher-level controller, including: The first-level controller forwards the registration request of the network device to the second-level controller, which is its direct superior. The second-level controller queries the third-level controller above it for global policy components applicable to the network device.

6. The network device multi-homing management method according to claim 5, wherein, After the second-level controller queries the third-level controller above it for the global policy component applicable to the network device, the process includes: The second-level controller receives a network device-specific global policy template and a dynamic policy token from the third-level controller; The second-level controller integrates the global policy template with its own configured region-specific rules to generate a region-level policy configuration; The regional policy configuration is sent to the first-level controller.

7. The network device multi-homing management method according to claim 6, wherein, After the regional policy configuration is distributed to the first-level controller, the following steps are included: The first-level controller integrates the received regional policy configuration with its own configured local policy to generate the final policy; The first-level controller sends the final policy to the network device.

8. The network device multi-homing management method according to claim 6, wherein, The network device is managed collaboratively by the first-level controller and the at least one higher-level controller, including: When the first-level controller fails, the second-level controller or the third-level controller takes over the management of the network device based on the dynamic policy token held by the network device.

9. The network device multi-homing management method according to claim 8, wherein, Also includes: The network device also registers directly with a higher-level controller to receive the corresponding policies directly from the controller.

10. The network device multi-homing management method according to claim 9, wherein, The generation of the dynamic policy token includes: Generate random salt values; Based on the root key, the random salt value, and the context information of the network device, a key is derived through a key derivation function. Use the key to sign data containing a unique device identifier and a timestamp; The data containing the random salt value and the signature is encoded to generate the dynamic policy token.

11. A network device multi-homing management system, comprising: Multiple network devices; as well as Multiple controllers are divided into multiple levels, including at least a first level, a second level, and a third level, forming a tree-like hierarchical structure; Each of the plurality of network devices is configured to establish a first management channel with one of the plurality of controllers at the first level; The first-level controller is configured to synchronize the registration information of the network device to at least one higher-level controller based on the establishment of the first management channel; The first-level controller and the at least one higher-level controller are configured to work together to jointly manage the network device.

12. An electronic device, comprising: One or more processors; A memory having stored one or more programs that, when executed by one or more processors, cause the one or more processors to implement the network device multihoming management method according to any one of claims 1 to 10.

13. A computer-readable medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the network device multihoming management method according to any one of claims 1 to 10.

14. A computer program product comprising a computer program or instructions that, when executed by a processor, implement the network device multihoming management method according to any one of claims 1 to 10.

Images