Control session binding and migration system, method and apparatus across secure tap ports

Abstract

This invention discloses a system, method, and device for control session binding and migration across secure listening ports. The system includes a multi-listening port access layer, a multi-security protocol adaptation layer, a security control and policy layer, a control protocol management layer, and a control and service layer. The security control and policy layer includes a secure channel management module, a unified secure session abstraction module, a migration control management module, a security capability negotiation module, a session context management module, and a security policy decision module. This invention enables smooth migration of control sessions between different secure listening ports, completing secure channel switching and communication channel adjustment without interrupting control session semantics. This significantly improves the continuity, reliability, and stability of control plane communication systems in multi-secure port environments and can be widely applied in the field of computer network technology.

Description

Technical Field

[0001] This invention relates to the field of computer network technology, and in particular to a control session binding and migration system, method and device across secure listening ports. Background Technology

[0002] As satellite internet rapidly evolves towards wider coverage, higher bandwidth, lower latency, and heterogeneous interconnection of multiple nodes, integrated space-air-ground networks are gradually becoming an important form of future network infrastructure. In this type of network environment, network nodes are widely distributed and links change frequently, making traditional distributed routing control methods increasingly inadequate in terms of resource scheduling efficiency and global optimization capabilities. Therefore, a centralized control mode based on software-defined networking (SDN) architecture is gradually being introduced into satellite IP networks to achieve unified scheduling of network resources and global path optimization.

[0003] In satellite IP networks, SDN controllers typically establish control connections with onboard routers, terrestrial routers, and gateway station equipment via southbound control protocols such as PCEP (Path Computation Element Protocol). This enables path calculation, policy distribution, and state management for MPLS-TE, Segment Routing (SR), SRv6 Policy, and leased line services, thereby achieving unified optimization of network paths and rapid service activation. As satellite networks continue to expand and service types become increasingly diverse, the stability, security, and continuity of control plane communication are gradually becoming crucial foundations for ensuring reliable network operation.

[0004] To meet the operational requirements of high reliability, high security, and compliant access in satellite networks, control plane communication typically needs to support multiple transport layer security protocols, such as TCP, TLS, TLCP, and TLCP+SM2+LAC, with different security levels, to satisfy diverse security needs such as national cryptographic compliance, identity authentication, data encryption, replay protection, and tamper protection. In real-world scenarios where multiple vendors and models of spaceborne and ground equipment are deployed together, the support capabilities of different vendors' equipment for security protocols vary significantly. Controllers typically need to open multiple secure listening ports simultaneously to ensure compatibility with the access capabilities of different devices.

[0005] In existing control plane communication systems, control sessions are typically directly attached to the underlying transport connection and its corresponding listening port, lacking an independent abstraction layer between the control session and the specific secure connection. Under this architecture, the lifecycle of the control session is highly tied to the underlying secure connection; once the underlying transport connection changes, the control session becomes invalid. When network security policies change, or when security protocol upgrades, port migrations, and encryption capability adjustments are required, existing systems typically need to first disconnect the original secure connection, then re-establish the control connection through the new secure listening port, and recreate the control session. During this process, the control session state of control protocols such as PCEP will be forcibly interrupted, and service states such as LSP and SR Policy need to be re-negotiated and synchronized, potentially causing path oscillations, service jitter, or even short-term service interruptions, significantly impacting the stability of network control services.

[0006] Specifically, existing control plane communication systems have the following main limitations in session management across secure listening ports: First, the control session is tightly coupled with the transport connection and lacks an independent abstraction layer. In existing implementations, the control session is directly bound to a specific secure connection and listening port. There is no protocol-independent abstraction mechanism between the control session and the underlying transport channel, making it impossible to maintain the continuity of the control session when switching security ports or upgrading protocols.

[0007] Second, secure port switching relies on rebuilding control connections, which affects the stability of the control plane. In scenarios such as security policy adjustments, security level upgrades, or cipher suite updates, existing systems must disconnect the original connection and re-establish a new secure connection. The re-establishment process requires capability negotiation and full state synchronization, which may cause temporary control plane failure in a highly reliable network environment, leading to path control anomalies and service interruptions.

[0008] Third, the migration process lacks a dual-channel transition mechanism, posing a risk of control message loss. Existing systems typically switch connections directly or forcibly close the original connection during connection switching, potentially resulting in the loss of control messages that have not yet been sent or acknowledged. This can lead to inconsistencies in the control state, making it difficult to meet the zero-packet-loss migration requirement in high-reliability control scenarios.

[0009] Fourth, there is a lack of a unified session binding and migration mechanism across security ports. In scenarios where multiple secure listening ports coexist, there is a lack of a unified session binding model between different secure connections. The system cannot achieve smooth migration of control sessions between different security protocol channels, and the continuity of control semantics during security protocol switching is difficult to guarantee.

[0010] Fifth, the migration process lacks atomic switching and rollback guarantees, resulting in insufficient system robustness. Existing technologies lack explicit atomic switching mechanisms and migration state management when making connection changes. In the event of migration failure or new connection anomalies, it often requires re-establishing the connection or manual intervention, leading to weak system self-recovery capabilities and difficulty in meeting the automated operation and maintenance needs of large-scale network environments.

[0011] The above problems urgently need to be addressed. Summary of the Invention

[0012] The purpose of this invention is to at least partially solve one of the technical problems existing in the prior art.

[0013] Therefore, one objective of this invention is to provide a control session binding and migration system across secure listening ports. This system constructs an abstract model of control sessions independent of the transmission connection, introduces a unified session channel binding management mechanism, a dual-channel transition and message emptying mechanism, and a session binding switching and fast rollback mechanism based on atomic operations, to achieve smooth migration of control sessions between different secure listening ports. It completes secure channel switching and communication channel adjustment without interrupting the semantics of the control session, thereby significantly improving the continuity, reliability, and stability of the control plane communication system in a multi-secure port environment.

[0014] Another objective of this invention is to provide a method for binding and migrating control sessions across secure listening ports.

[0015] To achieve the above-mentioned technical objectives, the technical solutions adopted in the embodiments of the present invention include: On one hand, embodiments of the present invention provide a control session binding and migration system across secure listening ports, including: The multi-listening port access layer is used to provide access capabilities for multiple security protocols through multiple listening ports; A multi-security protocol adaptation layer is used to uniformly adapt to different security protocols; The security control and policy layer is used to decouple control sessions and communication channels and enable cross-port migration capabilities. The control protocol management layer is used to implement protocol management in the control plane. The control and business layer is used to implement the business logic of the control plane. The security control and strategy layer includes: The secure channel management module is used to uniformly encapsulate transmission connections of different security protocols and provide a consistent channel interface; The unified security session abstraction module is used to model control sessions in a unified manner, obtain the session unique identifier, the current active channel identifier, the migration target channel identifier, the historical channel identifier, and the migration status, and realize the dynamic binding and switching between control sessions and communication channels based on the session-channel binding table; The migration control management module implements session migration control across security listening ports based on dual-channel management mechanism, atomic switching mechanism, channel emptying mechanism and rollback control mechanism; The security capability negotiation module is used to detect the protocol capabilities supported by the client and determine the capability negotiation result; The session context management module is used to maintain and control sessions; The security policy decision module is used to determine the corresponding target security level and target communication protocol based on the capability negotiation results.

[0016] Furthermore, in one embodiment of the present invention, the security control and policy layer establishes a control session through the following steps: Continuously monitor the monitoring port and receive access connection requests for the monitoring port, and verify the legitimacy of the access connection requests; Once the legitimacy verification is successful, the corresponding secure channel object is created and a channel identifier is assigned through the secure channel management module. The security capability negotiation module detects the protocol capabilities supported by the client and determines the capability negotiation result. The security policy decision module performs matching analysis on the capability negotiation results according to the preset security policy to determine the target security level and target communication protocol adopted by the control session. Based on the capability negotiation results, the target security level, and the target communication protocol, a control session object is created and a unique session identifier is assigned.

[0017] Furthermore, in one embodiment of the present invention, the security control and policy layer binds the control session and communication channel through the following steps: The session unique identifier of the control session object is associated and bound with the channel identifier of the secure channel object to obtain the session channel binding relationship; Write the session channel binding relationship into the session-channel binding table.

[0018] Furthermore, in one embodiment of the present invention, the security control and policy layer implements session migration across secure listening ports through the following steps: When a migration action is triggered, the controller generates corresponding migration authorization information through the migration control management module and issues migration instructions to the client based on the migration authorization information; The client determines the target listening port according to the migration instruction and initiates a connection request to the target listening port corresponding to the controller. After receiving the connection request from the target listening port, the controller creates a migration channel object and assigns a migration channel identifier through the security channel management module. The controller verifies the validity of the migration authorization information sent by the client. If the validity verification is successful, it registers the migration target channel according to the migration channel object, and binds the session unique identifier of the control session with the channel identifier of the migration target channel and writes it into the session-channel binding table. Once the target migration channel completes the security protocol handshake, the control session will be migrated from the initial active channel to the target migration channel; Once the session migration is complete, the initial active channel is emptied so that it no longer receives new control messages and is only used to send or process the remaining data that has entered the transmission queue. When the transmission queue of the initial active channel is cleared, the initial active channel is closed, and the corresponding session-channel binding relationship is deleted from the session-channel binding table.

[0019] Furthermore, in one embodiment of the present invention, migrating the control session from the initial active channel to the migration target channel specifically includes: Set the historical channel identifier of the control session to the channel identifier of the initial active channel; Update the current active channel identifier of the control session to the channel identifier of the migration target channel; Clear or set the migration target channel identifier of the control session to NULL; Update the migration status of the control session to complete migration.

[0020] Furthermore, in one embodiment of the present invention, the security control and policy layer implements migration failure rollback control through the following steps: When a session migration anomaly is detected, a migration failure rollback is triggered, and the corresponding current active channel identifier and migration target channel identifier are determined based on the control session record. The migration control management module closes the migration target channel corresponding to the migration target channel identifier and switches the control session back to the single-channel operation state based on the initial active channel. Close the migration target channel and delete the session channel binding relationship between the control session and the migration target channel in the session-channel binding table.

[0021] Furthermore, in one embodiment of the present invention, switching the control session from the migration target channel back to a single-channel operating state based on the initial active channel specifically includes: Clear or set the migration target channel identifier of the control session to NULL; Keep the current active channel identifier of the control session unchanged, and keep the channel identifier of the initial active channel unchanged; Clear or set the history channel identifier of the control session to NULL; Update the migration state of the control session to either rollback or NORMAL.

[0022] On the other hand, embodiments of the present invention provide a method for control session binding and migration across secure listening ports, which is implemented through the aforementioned control session binding and migration system across secure listening ports, and includes the following steps: A control session is established through the security control and policy layer, and the control session is bound to the communication channel. When a migration action is triggered, session migration across secure listening ports is achieved through the security control and policy layer. When a session migration anomaly is detected, the migration failure rollback control is implemented through the security control and policy layer.

[0023] On the other hand, embodiments of the present invention provide an electronic device, the electronic device including a memory, a processor, a computer program stored in the memory and executable on the processor, and a data bus for implementing connection communication between the processor and the memory, wherein when the computer program is executed by the processor, it implements the control session binding and migration method across security listening ports as described above.

[0024] On the other hand, embodiments of the present invention also provide a storage medium, which is a computer-readable storage medium for computer-readable storage. The storage medium stores one or more computer programs, which can be executed by one or more processors to implement the control session binding and migration method across secure listening ports as described above.

[0025] On the other hand, embodiments of the present invention also provide a computer program product, including a computer program that, when executed by a processor, implements the control session binding and migration method across secure listening ports as described above.

[0026] The advantages and beneficial effects of the present invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention: This invention includes a multi-monitoring port access layer, a multi-security protocol adaptation layer, a security control and policy layer, a control protocol management layer, and a control and service layer. The security control and policy layer comprises a secure channel management module, a unified secure session abstraction module, a migration control management module, a security capability negotiation module, a session context management module, and a security policy decision module. This invention constructs a control session abstraction model independent of the transmission connection, introduces a unified session channel binding management mechanism, a dual-channel transition and message emptying mechanism, and a session binding switching and fast rollback mechanism based on atomic operations. This enables smooth migration of control sessions between different secure monitoring ports, completing secure channel switching and communication channel adjustment without interrupting the semantics of the control session. This significantly improves the continuity, reliability, and stability of the control plane communication system in a multi-secure port environment. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the embodiments of the present invention are described below. It should be understood that the drawings described below are only for the convenience of clearly describing some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a schematic diagram of the structure of a control session binding and migration system across secure listening ports provided in an embodiment of the present invention; Figure 2 A schematic diagram of the system architecture for a control session binding and migration system across secure listening ports provided in an embodiment of the present invention; Figure 3 A flowchart for establishing a control session and binding the control session to a communication channel is provided for an embodiment of the present invention; Figure 4 A flowchart for implementing session migration across secure listening ports provided in an embodiment of the present invention; Figure 5 This is a flowchart illustrating the implementation of migration failure rollback control provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the state transition of the migration process provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the state transition of the degradation migration process provided in an embodiment of the present invention; Figure 8 A flowchart illustrating the steps of the control session binding and migration method across secure listening ports provided in this embodiment of the invention; Figure 9 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of the storage medium provided in an embodiment of the present invention. Detailed Implementation

[0029] The embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application. It should be noted that although functional modules are divided in the system schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the system schematic diagram or the order in the flowchart. The step numbers in the following embodiments are only set for ease of explanation and do not limit the order between steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0030] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0031] In existing control plane communication mechanisms, control sessions are typically directly attached to the underlying transport connection and its corresponding secure listening port. There is a lack of an independent abstraction layer between the control session and the specific secure connection, and the lifecycle of the control session is highly bound to the underlying transport connection. When security port switching, security protocol upgrades, or encryption capability adjustments are required, it is often necessary to disconnect the original connection and re-establish the control session. This can easily lead to the loss of session state for control protocols such as PCEP, causing service path instability or even service interruption, and affecting the stable operation of the network control plane.

[0032] Existing technologies generally suffer from the following problems in managing control sessions across secure listening ports: 1. Strong coupling between control session and transport connection: In existing control plane communication mechanisms, the control session is usually directly attached to the underlying transport connection and its corresponding listening port, lacking an independent abstraction layer between the control session and the specific secure connection. When a secure port switch or security protocol upgrade is required, the original connection often needs to be disconnected and the control session re-established, making it impossible to maintain the continuity of the control session.

[0033] 2. Security port switching requires rebuilding the control session: In scenarios such as changes in security policies, upgrades to security protocols, or adjustments to encryption capabilities, existing systems typically achieve channel switching by closing the original connection and re-establishing the control connection on the new secure listening port. This method results in the loss of PCEP session state, requiring renegotiation of capabilities and full state synchronization, which may cause temporary failure of path control, business path instability, or even business interruption.

[0034] 3. Lack of dual-channel transition and message flushing mechanism during migration: When switching connections, existing systems usually use direct switching or forced closure of the original connection. Control messages that have not yet been sent or confirmed in the original connection may be lost as a result, leading to inconsistencies in the control state and making it difficult to meet the requirements of zero packet loss migration in high-reliability control scenarios.

[0035] 4. Lack of a unified session binding and migration mechanism across security ports: In scenarios where multiple security listening ports coexist, there is a lack of a unified session binding model and migration management mechanism between different security connections. The system cannot achieve smooth migration of control sessions between different security protocol channels, and the continuity of control semantics during the security port switching process is difficult to guarantee.

[0036] The existing optimization solutions mainly focus on the following aspects: The first is the connection reconstruction-based security protocol switching mechanism. Some systems upgrade security protocols or migrate ports by disconnecting the old connection and re-establishing a new secure connection. However, this method inevitably interrupts the control session and affects the continuity of the control plane, which is a significant shortcoming in satellite network scenarios where control stability is critical.

[0037] Second, static port configuration and manual policy adjustment. In multi-security port environments, most systems still rely on static configuration for port and security policy management, lacking unified session management and dynamic migration capabilities across ports. When device capabilities or network security policies change, the system struggles to adapt automatically, requiring frequent manual configuration adjustments by maintenance personnel, resulting in high system maintenance complexity.

[0038] Thirdly, there is the session recovery mechanism at the single-connection layer. Some systems attempt to reduce control interruption time by quickly reconnecting and restoring the state after the connection is lost. However, this approach is essentially still a "disconnect and rebuild" mode, which cannot fundamentally solve the problem of control session continuity. In scenarios with complex session states or a large number of devices, the rebuild overhead is still significant.

[0039] In summary, existing technologies have significant shortcomings in managing control sessions across secure listening ports: control sessions are highly coupled with the underlying transport connections, lack a unified abstract model for session binding and migration, secure port switching relies on control session reconstruction, and the migration process lacks reliability assurance mechanisms such as dual-channel transition, atomic switching, and fast rollback. These limitations are particularly pronounced in large-scale heterogeneous network environments such as satellite internet, making it difficult to meet the comprehensive requirements of high reliability, high security, and continuous stable operation of control plane communication. Therefore, it is necessary to propose a new mechanism that can decouple control sessions from transport connections and support smooth migration of control sessions between different secure listening ports to ensure the continuity of control plane communication and the stable operation of network services in multi-security protocol environments.

[0040] This invention addresses the challenges of high coupling between control sessions and underlying transport connections, the need to rebuild control sessions when switching between secure listening ports, and the lack of reliability guarantees during migration in control plane communication scenarios with multiple secure ports in a satellite internet environment. It proposes a control session binding and migration system across secure listening ports. This solution constructs an abstract model of control sessions independent of transport connections, a unified session channel binding management mechanism, and a dual-channel transition and atomic switching migration mechanism. This enables the controller to smoothly migrate control sessions between different secure listening ports without interrupting the semantics of the control sessions, thereby significantly improving the continuity, reliability, and system stability of control plane communication.

[0041] The following describes some of the terms used in the embodiments of the present invention.

[0042] SDN (Software-Defined Networking): SDN is a network architecture whose core idea is to separate the network control plane (which determines how data flows) from the data plane (which actually forwards data packets). In this architecture, the network control plane is centrally managed through software, while the data plane consists of simple forwarding devices such as switches and routers. This separation makes network management more flexible and programmable, allowing administrators or automated systems to dynamically adjust network behavior according to business needs.

[0043] BGP (Border Gateway Protocol): BGP is the core routing protocol of the Internet. Its core idea is to divide the Internet into several Autonomous Systems (AS), each managing its own routing, while BGP coordinates the exchange of routing information and path selection between ASes. In this architecture, BGP establishes TCP peer relationships between border routers of adjacent ASes, incrementally advertising reachable network prefixes and path attributes to each other. It also comprehensively considers multi-dimensional policy attributes such as AS path length, local priority, and MED (Mean Advantage) to select the optimal path, enabling operators and enterprises to flexibly intervene in routing decisions based on business agreements, traffic costs, and other requirements. This design makes BGP not only responsible for the distribution and maintenance of global Internet routing tables, but also a crucial foundation for advanced network functions such as traffic engineering, multi-homed access, and cross-domain VPNs.

[0044] NETCONF (Network Configuration Protocol): NETCONF is a network device configuration and management protocol standardized by the IETF. Its core idea is to decouple configuration operations from the underlying device implementation. Through an XML-based Remote Procedure Call (RPC) mechanism, it enables the management system to distribute configurations, query status, and audit operations on devices in a structured and programmable manner. In this architecture, the management end performs fine-grained operations on devices using standard operation primitives (such as edit-config, commit, and rollback), while the device end uses the YANG data model to standardize its own capabilities. Both sides interact via a secure SSH channel. Its transactional commit mechanism supports atomic configuration activation and one-click rollback, significantly reducing the risk of batch changes compared to traditional CLI methods. This design is a crucial protocol foundation for standardized southbound interface interfacing between network controllers and devices, playing a key role in SDN and network automation systems.

[0045] PCEP (Path Computation Unit Communication Protocol): PCEP is a network communication protocol whose core idea is to separate path calculation functionality from network devices, allowing dedicated Path Computation Units (PCEs) to handle it centrally. In this architecture, the PCE is responsible for calculating the optimal path based on the global network topology and traffic engineering constraints, while network devices (such as routers) act as Path Computation Clients (PCCs), requesting and executing the obtained path. This separation makes path planning in complex multi-layered, multi-domain networks more intelligent and efficient, allowing administrators or automated systems to dynamically distribute and adjust traffic forwarding paths based on multi-dimensional constraints such as bandwidth, latency, and reliability.

[0046] TLS (Transport Layer Security): TLS is a network security protocol whose core idea is to provide encryption, authentication, and data integrity protection for both communicating parties at the transport layer, decoupling security mechanisms from upper-layer application logic. In this architecture, the TLS handshake phase is responsible for negotiating encryption algorithms and verifying certificate identity, while the record layer encrypts and encapsulates the actual transmitted data. Upper-layer applications (such as HTTP and SMTP) do not need to concern themselves with the underlying encryption details to enjoy secure communication. This layered design makes network transmission security more universal and standardized, and is widely used in scenarios such as HTTPS, email, and instant messaging to ensure the confidentiality and trustworthiness of data in public networks.

[0047] TLCP (Transport Layer Cryptography Protocol): TLCP is a transport layer security protocol defined by the Chinese national standard (GB / T38636). Its core idea is to replace international cryptographic algorithms with domestically developed commercial cryptographic algorithms (SM series algorithms) on the basis of the TLS design framework, achieving independent and controllable secure transmission. In this architecture, TLCP manages signature certificates and encryption certificates separately through a dual-certificate mechanism, using them for identity authentication and key negotiation respectively. Data transmission relies on Chinese cryptographic algorithms such as SM4 for encryption protection. This design makes the transport layer security mechanism compliant with Chinese cryptographic regulations and suitable for application scenarios with mandatory cryptographic compliance requirements, such as finance, government affairs, and critical infrastructure.

[0048] TLCP+SM2+LAC (a hybrid encryption scheme combining the national cryptographic transmission protocol with SM2 and lattice-based cryptography): TLCP+SM2+LAC is a hybrid cryptographic transmission scheme geared towards post-quantum security. Its core idea is to combine the traditional national cryptographic asymmetric algorithm SM2 with the lattice-based post-quantum cryptography algorithm LAC (Lattice-based Cryptography) within the TLCP protocol framework, thus balancing current compliance requirements with future resistance to quantum attacks. In this architecture, SM2 is responsible for identity authentication and digital signature requirements under current national cryptographic standards, while the LAC algorithm handles key encapsulation or key negotiation. Its security is built upon lattice-hard problems (such as LWE and RLWE), maintaining high security even against quantum computer attacks. The TLCP record layer uses the negotiated session key to encrypt and protect transmitted data with SM4 encryption. This hybrid design enables communication systems to comply with national cryptographic compliance requirements while possessing forward-looking protection against quantum threats such as "interception now, decryption in the future," making it suitable for high-security deployment scenarios in finance, government, and military industries where long-term data security is paramount.

[0049] Cipher Suite Negotiation: Cipher suite negotiation is the core handshake step in establishing an encrypted connection using secure transport protocols such as TLS / TLCP. Its core idea is that before formally transmitting data, both communicating parties agree on a set of cryptographic algorithms through a negotiation mechanism, ensuring that the encryption methods used in subsequent communication are supported and recognized by both parties. In this mechanism, a cipher suite typically consists of four types of algorithms: key exchange algorithms for authentication (such as RSA, SM2, ECDHE), symmetric encryption algorithms for data encryption (such as AES, SM4), message authentication algorithms for data integrity verification (such as SHA-256, SM3), and hash algorithms used for pseudo-random functions in some protocol versions. During the negotiation process, the client sends a list of all supported cipher suites to the server in the handshake message. The server selects the highest-priority cipher suite it also supports, confirms it, and responds. Both parties then jointly establish an encrypted channel. This negotiation mechanism gives the security protocol good algorithmic flexibility and backward compatibility, allowing the system to dynamically select suitable cipher combinations under different security policies, compliance requirements, or performance constraints. It also provides institutional guarantees for gradually phasing out weak cryptographic algorithms and smoothly transitioning to a more secure cryptographic system.

[0050] The control session binding and migration method across secure listening ports provided in this application can be applied to terminals, servers, or software running on terminals or servers. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing a driver status monitoring method based on machine vision, but is not limited to the above forms.

[0051] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0052] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards of the relevant countries and regions. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data for the proper functioning of the embodiments of this application obtained.

[0053] like Figure 1 The diagram shown is a structural schematic of a control session binding and migration system across secure listening ports provided in an embodiment of the present invention. (Refer to...) Figure 1 This invention provides a control session binding and migration system across secure listening ports, specifically including: The multi-listening port access layer is used to provide access capabilities for multiple security protocols through multiple listening ports; A multi-security protocol adaptation layer is used to uniformly adapt to different security protocols; The security control and policy layer is used to decouple control sessions and communication channels and enable cross-port migration capabilities. The control protocol management layer is used to implement protocol management in the control plane. The control and business layer is used to implement the business logic of the control plane. The security control and strategy layer includes: The secure channel management module is used to uniformly encapsulate transmission connections of different security protocols and provide a consistent channel interface; The unified security session abstraction module is used to model control sessions in a unified manner, obtain the session unique identifier, the current active channel identifier, the migration target channel identifier, the historical channel identifier, and the migration status, and realize the dynamic binding and switching between control sessions and communication channels based on the session-channel binding table; The migration control management module implements session migration control across security listening ports based on dual-channel management mechanism, atomic switching mechanism, channel emptying mechanism and rollback control mechanism; The security capability negotiation module is used to detect the protocol capabilities supported by the client and determine the capability negotiation result; The session context management module is used to maintain and control sessions; The security policy decision module is used to determine the corresponding target security level and target communication protocol based on the capability negotiation results.

[0054] Specifically, this invention proposes a control session binding and migration system across secure listening ports. Through multi-protocol listening, capability negotiation, policy decision-making, and session migration mechanisms, it achieves dynamic secure adjustment and continuous communication capabilities for control plane communication. For example... Figure 2 The diagram shown illustrates the system architecture of the cross-security listening port control session binding and migration system provided in this embodiment of the invention. The system adopts a layered design, comprising five layers from bottom to top: a multi-listening port access layer, a security protocol adaptation layer, a security control and policy layer, a control protocol management layer, and a control and business layer. 1. Multi-Port Access Layer: This layer is responsible for providing access capabilities for various security protocols, including TLS ports, TLCP ports, and TCP ports. Different devices can choose the corresponding port to access based on their own capabilities, providing the foundation for subsequent cross-port migration.

[0055] 2. Multi-Security Protocol Adaptation Layer: This layer is used for unified adaptation of different security protocols, including TLS protocol modules, TLCP protocol modules, and SM2+LAC security enhancement modules. Through protocol adaptation, a unified abstraction of communication capabilities under different security mechanisms is achieved.

[0056] 3. Security Control and Policy Layer. This layer is the core of the invention, enabling decoupling of control sessions and communication channels, as well as cross-port migration capabilities. It mainly includes the following modules: 1) Secure Channel Management Module. This module is responsible for the unified management of underlying communication connections. Its core functions include channel status management (establishing, READY, DRAIN, CLOSED, etc.), handshake and encryption context management, and SecureChannel object management. This module uniformly encapsulates transmission connections of different protocols, providing a consistent channel interface for upper layers.

[0057] 2) Unified Security Session Abstraction Module. The ControlSession object is used to model the control session in a unified manner. The core fields include session_id (unique identifier of the session), active_channel_id (current active channel), target_channel_id (target channel for migration), previous_channel_id (historical channel identifier), and migration_state (migration state machine).

[0058] 3) Session-Channel Binding Table (Decoupling Mechanism). The SessionChannelBindingTable maintains the mapping relationship between session_id and channel_id, enabling dynamic binding and switching between sessions and communication channels.

[0059] 4) Migration Control Management Module (Core Mechanism). This module is used to implement session migration control across secure listening ports. It includes: dual-channel management mechanism (active / target coexistence), atomic switching mechanism, channel emptying mechanism (DRAIN), and rollback control mechanism (Rollback Manager).

[0060] 5) Security Capability Negotiation Module. The security capability negotiation module is mainly used to detect the protocol capabilities supported by the peer.

[0061] 6) Session Context Management Module. The session context management module is mainly responsible for maintaining logical control sessions.

[0062] 7) Security Policy Decision Module. The security policy decision module selects the target security level based on the detection results.

[0063] 4. Control Protocol Management Layer: This layer is responsible for the management of control plane protocols, such as BGP / PCEP / Netconf session management, control protocol message encoding and decoding, and control protocol capability processing. This layer interacts with the underlying communication system through the ControlSession abstract interface and does not need to be aware of the actual communication protocol type used at the underlying level.

[0064] 5. Control and Business Layer: This layer implements the business logic of the control plane, such as path calculation, network resource scheduling, and TE policy control.

[0065] In the system of this invention, to achieve multi-security protocol communication management and session migration control, the following core data structures are maintained: 1. The CapabilitySet, a collection of security capabilities, has the following data structure: CapabilitySet { support_tls: bool support_tlcp: bool support_sm2: bool support_lac: bool cipher_suites: list version_range: list } This set of capabilities is exchanged between the two communicating parties during the communication establishment phase and serves as the input for security policy decisions.

[0066] 2. The SecurityPolicy object has the following data structure: SecurityPolicy { min_security_level preferred_protocol_order downgrade_allowed rekey_interval } Security policy objects are used to describe the system's control policies for communication security levels.

[0067] 3. Unified control session (abstract object), data format as follows: ControlSession { session_id / / Controls the unique identifier of the session device_id / / Device identifier active_channel_id / / The currently used secure channel previous_channel_id / / Channel before migration target_channel_id / / Target migration channel migration_state / / Migration status, with the following possible values: / / - NORMAL: Normal state, no migration in progress / / - MIGRATING: Migration in progress (new channel switched, old channel is empty) / / - ROLLED_BACK: Rollback completed (marks a rollback event for shock protection) / / - FAILED: Migration failed, manual intervention required. session_state / / session state } The control session object is used to describe the logical control relationship between the two parties communicating in the control plane. It mainly includes: 1) session unique identifier session_id, 2) peer device identifier device_id, 3) currently used secure channel active_channel_id, 4) previous_channel_id of the channel before migration, 5) target migration channel target_channel_id, 6) migration state migration_state, and 7) session state session_state.

[0068] 4. The SecureChannel object has the following data structure: SecureChannel { channel_id / / Generated by the controller bind_session_id / / The session to be bound transport_conn_id / / TCP connection identifier protocol_type (TLS / TLCP / TCP) local_port / / Local listening port handshake_state / / Handshake state channel_state / / Channel running status } A secure communication channel object represents the actual communication connection in the control plane. It mainly includes: 1) a unique channel identifier (channel_id); 2) a bound session identifier (bind_session_id); 3) a TCP connection identifier (transport_conn_id); 4) a protocol type (protocol_type); 5) a listening port (local_port); 6) a handshake state (handshake_state); and 7) a channel running state (channel_state). This object is responsible for carrying the actual data transmission in the control plane. The channel state definitions are shown in Table 1 below.

[0069]

[0070] Table 1 5. The SessionChannelBindingTable, a table representing the session channel binding relationship, has the following data structure: SessionChannelBindingTable { session_id → channel_id_list } The system maintains a mapping relationship between control sessions and communication channels. This mapping relationship identifies the communication channel currently bound to a given control session. Through this binding relationship, dynamic updates to the association between the control session and the communication channel can be achieved when a communication channel switch occurs.

[0071] 6. Migrate Token, with the following data structure: MigrationToken { session_id / / Controls the unique identifier of the session target_port / / Target listening port identifier expire_time / / Migration validity period token_signature / / Verification signature generated by the controller } The migration token is used to authorize the device to establish a migration connection on the new secure listening port. The migration token includes the following information: control session identifier (session_id), target listening port (target_port), migration expiration time (expire_time), and verification signature (token_signature) generated by the controller.

[0072] The present invention has the following improvements in system design: 1. By constructing a control session context object (ControlSession) independent of the transport connection, the control session is abstracted from the specific underlying transport connection, and a unified binding relationship table (SessionChannelBindingTable) is established between the control session and the security connection. This enables independent identification and centralized management of the control session, providing a basic model support for session migration across security listening ports.

[0073] 2. By establishing a control session migration mechanism across secure listening ports, when communication channel adjustments are required, the system can establish a new secure connection on the target secure listening port and migrate the existing control session to the new secure channel through a session binding mechanism, thereby achieving a smooth switch of control sessions between different secure protocol channels, without the upper-layer control protocol needing to be aware of changes in the underlying channel.

[0074] 3. By introducing a dual-channel transition and message emptying mechanism, the original connection and the new connection are allowed to coexist briefly during the migration process. By placing the old channel in an empty state, the orderly sending and confirmation of the remaining control messages in the original connection are ensured, thereby achieving zero-loss migration of control messages and effectively avoiding the problem of inconsistent control states.

[0075] 4. By introducing an atomic operation-based session binding switching mechanism and a fast rollback mechanism for migration failure, the system switches the session and channel binding relationship through atomic operations during the migration process, and achieves fine-grained control of the migration process by combining the migration state machine. When the new channel is abnormal, the system can quickly roll back to the original channel and restore business communication, which significantly improves the system's self-recovery capability and operational stability.

[0076] Through the above improvements, this invention can effectively overcome the problems of strong coupling between control sessions and security ports, the need to rebuild control sessions when switching across ports, and the lack of reliability guarantees during migration in existing control plane communication systems. It constructs a highly reliable and smoothly migrated control plane session management system for satellite Internet multi-security port scenarios, thereby meeting the comprehensive requirements for control plane continuity, security, and flexible operation and maintenance capabilities in future large-scale heterogeneous network environments.

[0077] It can be recognized that the embodiments of the present invention construct an abstract model of control session independent of transmission connection, introduce a unified session channel binding management mechanism, a dual-channel transition and message emptying mechanism, and a session binding switching and fast rollback mechanism based on atomic operation, so as to realize the smooth migration of control session between different secure listening ports, and complete secure channel switching and communication channel adjustment without interrupting the semantics of control session, thereby significantly improving the continuity, reliability and stability of control plane communication system in multi-secure port environment.

[0078] like Figure 3 The diagram shown is a flowchart of establishing a control session and binding the control session to the communication channel according to an embodiment of the present invention. (Refer to...) Figure 3 As an optional implementation, the security control and policy layer establishes a control session through the following steps: Continuously monitor the monitoring port and receive access connection requests for the monitoring port, and verify the legitimacy of the access connection requests; Once the legitimacy verification is successful, the corresponding secure channel object is created and a channel identifier is assigned through the secure channel management module; The security capability negotiation module detects the protocol capabilities supported by the client and determines the capability negotiation result. The security policy decision module matches and analyzes the capability negotiation results according to the preset security policy to determine the target security level and target communication protocol adopted by the control session. Based on the capability negotiation results, target security level, and target communication protocol, create a control session object and assign a unique session identifier.

[0079] As an optional implementation, the security control and policy layer binds the control session and communication channel through the following steps: The session unique identifier of the control session object is associated and bound with the channel identifier of the secure channel object to obtain the session channel binding relationship; Write the session channel binding relationship into the session-channel binding table.

[0080] Specifically, in this embodiment of the invention, the control session establishment and session-channel binding process is implemented through a security control and policy layer, as follows: 1. Connection Request Reception: The SDN controller continuously listens on multiple pre-set secure listening ports (including but not limited to TLS ports, TLCP ports, and TCP ports). Devices (such as routers and switches) initiate access connection requests (such as PCEP over TLS, PCEP over TLCP, or PCEP over TCP protocols) to the corresponding listening port of the SDN controller according to their own communication needs. The SDN controller receives the connection request, verifies its legitimacy (including device identity verification and certificate validity check), and proceeds to the next processing step if it is confirmed to be legitimate; if the verification fails, the connection is rejected and the abnormal event is recorded.

[0081] 2. Creating a Secure Channel Object: After verifying the connection's legitimacy, the SDN controller creates a corresponding SecureChannel object based on the transport protocol type (TLS / TLCP / TCP) used by the current access connection. This object records the channel's transport connection identifier (transport_conn_id), protocol type (protocol_type), local listening port (local_port), and handshake state (handshake_state). At this point, the SecureChannel's channel_state is initialized to the "establishing" state, and bind_session_id is temporarily empty, to be filled in during subsequent binding steps.

[0082] 3. Assign Channel Identifier: The SDN controller assigns a globally unique channel identifier (channel_id) to the SecureChannel object created in step 2 and writes it to the SecureChannel object, which serves as the index for subsequent session binding and channel management. At this point, the SecureChannel object is initialized and meets the basic requirements for participating in session binding. 4. Capability Negotiation: The SDN controller and access devices perform a security capability negotiation process. Both parties announce their supported security communication capabilities, including but not limited to supported security protocol types, cryptographic algorithm capabilities, and protocol version ranges. The controller determines the range of communication capabilities that both parties can support based on their respective capability sets and records the negotiation result for subsequent security policy decisions.

[0083] 5. Security Policy Decision: The SDN controller performs matching analysis on the capability negotiation results based on the preset security policy to determine the target security level and target communication protocol to be used in this control session.

[0084] 6. Query existing control sessions: The SDN controller queries the existing ControlSession record based on the access device's identity identifier (device_id). If a ControlSession with the corresponding device_id already exists, it is processed according to the controller's session management policy; this processing mechanism is not within the scope of this process description. If no corresponding ControlSession exists, proceed to step 7 to execute the new session creation process.

[0085] 7. Create a control session: Based on the capability negotiation results and security policy decision results, the SDN controller creates a ControlSession object for the current device and initializes its related parameters: device_id is set to the identity identifier of the current access device; active_channel_id is temporarily empty and will be filled in step 9; previous_channel_id is initialized to NULL, indicating no migration history; target_channel_id is initialized to NULL; migration_state is initialized to NORMAL, indicating that the session is in a normal state and no migration is in progress.

[0086] 8. Generate and assign session identifiers: The SDN controller generates a globally unique session identifier (session_id) for the newly created ControlSession in step 7 and writes it to the session_id field of the ControlSession object, completing the assignment of a unique identity for the control session. The session_id is uniformly generated and managed by the SDN controller; the device side has no generation permission, but only passively obtains and uses it.

[0087] 9. Establish session and channel binding relationship: The SDN controller associates and binds the session_id generated in step 8 with the channel_id assigned in step 3, and performs the following operations: 1) Update the active_channel_id field of ControlSession to the current channel_id; 2) Update the bind_session_id field of SecureChannel to the current session_id, and at the same time update the channel_state to the bound state; 3) Write the final binding relationship (session_id → channel_id) into the SessionChannelBindingTable to form a unique mapping between the session and the transmission channel for subsequent migration process query and maintenance.

[0088] 10. Notify the device and initiate control protocol layer communication (e.g., PCEP protocol communication): The SDN controller returns the session_id assigned for this session to the access device, completing the synchronization of control plane session information. Afterwards, based on the established ControlSession, SecureChannel, and target communication protocol, the SDN controller allows the device and the SDN controller to initiate normal service data interaction at the PCEP layer, enabling the SDN controller to perform normal management and control of the device and data transmission, providing a stable session starting point for subsequent migration processes.

[0089] It's important to note that the `session_id` of `ControlSession` is uniformly generated and managed by the SDN controller; the device side has no generation authority, only passively receiving and holding it. When `ControlSession` is created, `previous_channel_id` is initialized to NULL and `migration_state` is initialized to NORMAL, explicitly indicating that the session is in an initial state without migration history, providing a clear starting point for subsequent migration processes. The `session_id → channel_id` mapping in `SessionChannelBindingTable` is the basis for querying channel switching and rollback operations in all subsequent migration processes. `ControlSession` objects and `SecureChannel` objects are managed independently, establishing a mapping relationship through `SessionChannelBindingTable`, thereby decoupling the control session from the underlying transport connection and providing a foundation for subsequent session migration across secure listening ports.

[0090] like Figure 4 The diagram shown is a flowchart of a process for implementing session migration across secure listening ports according to an embodiment of the present invention. (Refer to...) Figure 4 As an optional implementation, the security control and policy layer implements session migration across secure listening ports through the following steps: When a migration action is triggered, the controller generates corresponding migration authorization information through the migration control management module and issues migration instructions to the client based on the migration authorization information; The client determines the target listening port according to the migration instruction and initiates a connection request to the target listening port corresponding to the controller. After receiving the connection request from the target listening port, the controller creates a migration channel object and assigns a migration channel identifier through the secure channel management module. The controller verifies the validity of the migration authorization information sent by the client. When the validity verification is successful, it registers the migration target channel according to the migration channel object and binds the session unique identifier of the control session with the channel identifier of the migration target channel and writes it into the session-channel binding table. Once the target channel completes the security protocol handshake, the control session will be migrated from the initial active channel to the target channel. Once the session migration is complete, the initial active channel is emptied so that it no longer receives new control messages and is only used to send or process the remaining data that has entered the transmission queue. When the transmission queue of the initial active channel is cleared, the initial active channel is closed, and the corresponding session channel binding relationship is deleted from the session-channel binding table.

[0091] As a further optional implementation, the control session is migrated from the initial active channel to the migration target channel, specifically including: Set the historical channel identifier of the control session to the channel identifier of the initial active channel; Update the current active channel identifier of the control session to the channel identifier of the migration target channel; Clear or set the migration target channel identifier of the control session to NULL; Update the migration status of the control session to complete migration.

[0092] Specifically, this embodiment of the invention implements a session migration process across secure listening ports through a security control and policy layer. When a control session has been established and is running normally, the SDN controller migrates the control session from the communication channel corresponding to the current secure listening port to the communication channel corresponding to another secure listening port. This migration process is completed without terminating the control session. Through session and channel decoupling and a dual-channel transition mechanism, a smooth switchover of control plane communication is achieved, as detailed below: 1. Migration Trigger: During the operation of a control session, the SDN controller determines, based on factors such as system operating status, security policy adjustments, or changes in the network environment, that the current control session needs to perform a security communication method adjustment operation, such as migrating from the existing secure communication protocol to the listening port corresponding to another secure communication protocol. When it is determined that a session migration is required, the SDN controller updates the migration_state field of the corresponding ControlSession object from the NORMAL state to the MIGRATING state, indicating that the control session has entered the migration preparation phase.

[0093] It should be noted that this step only describes the triggering of the migration action. The specific triggering strategy (such as security level assessment, policy adjustment mechanism, etc.) can be implemented using existing technology or other methods, and this invention does not limit it.

[0094] 2. Generate Migration Authorization Information: The SDN controller generates a migration authorization token for the current ControlSession, which authorizes the device to establish a migration connection on the new secure listening port. The MigrationToken includes at least the following information: session_id, target listening port identifier (target_port), migration expiration time (expire_time), and a verification signature generated by the controller (token_signature). This MigrationToken ensures that the device performs cross-port migration operations only with controller authorization and prevents unauthorized session takeovers.

[0095] 3. Issuing the migration command: The SDN controller sends a migration command message to the device through the SecureChannel corresponding to the active_channel_id of the current ControlSession, and carries the MigrationToken generated in step 2 in the message. After receiving the migration command, the device initiates a new connection request to the target secure listening port corresponding to the SDN controller according to the target listening port information in the MigrationToken.

[0096] 4. Establishing a Target Secure Channel: The SDN controller receives the connection request initiated by the device to the target secure listening port and performs the following operations: 1) Creates a new SecureChannel object; 2) Assigns a new channel_id to the SecureChannel; 3) Records the protocol type (protocol_type), listening port (local_port), and connection identifier (transport_conn_id) of the channel; 4) Initializes the channel_state to the establishing state. Subsequently, the device carries the MigrationToken in the handshake or control message of this connection.

[0097] 5. Migration Authorization Verification: After receiving the MigrationToken from the device, the SDN controller performs a validity check, including: 1) verifying the validity of the token_signature; 2) verifying that the token is within its valid time frame; and 3) verifying that the session_id in the token matches the existing ControlSession. If the verification fails, the connection is rejected and the corresponding SecureChannel is closed. If the verification succeeds, proceed to the next step. Note: For the degradation process, it is necessary to consider whether the target port for verification is consistent with the degradation path of the SecurityPolicy, i.e., the target protocol for degradation must meet the min_security_level requirement. 6. Register the target channel: After successful MigrationToken verification, the SDN controller registers the SecureChannel created in step 4 as the target channel for the current ControlSession and performs the following operations: 1) Set the bind_session_id field of the SecureChannel to the current session_id; 2) Update the ControlSession.target_channel_id field to the channel_id; 3) Record this channel in the channel set corresponding to the session_id in the SessionChannelBindingTable. At this time, ControlSession is associated with two communication channels simultaneously: active_channel_id (the original communication channel); target_channel_id (the new communication channel). The system enters the dual-channel coexistence stage.

[0098] 7. New Channel Readiness Confirmation: The SDN controller continuously monitors the handshake status of the SecureChannel corresponding to target_channel_id. When it confirms that the channel has completed the security protocol handshake and entered the READY state, it considers that the target communication channel is ready to carry control session communication.

[0099] 8. Perform session migration and handover: After the target channel is READY, the SDN controller performs control session migration operations, which specifically include: 1) Set ControlSession.previous_channel_id to the current active_channel_id; 2) Update ControlSession.active_channel_id to target_channel_id; 3) Clear or set ControlSession.target_channel_id to NULL; 4) Update migration_state to COMPLETED.

[0100] After completing the above operations, the new channel becomes the only active communication channel for the control session.

[0101] 9. Existing Channel Draining: After completing the session handover, the SDN controller updates the channel_state of the SecureChannel corresponding to previous_channel_id to DRAIN. In DRAIN state, the original communication channel no longer receives new control messages and is only used to send or process the remaining data that has entered the transmission queue to ensure complete transmission of communication data.

[0102] 10. Close the original channel: After the data buffer of the original communication channel is cleared, the SDN controller closes the SecureChannel corresponding to previous_channel_id, updates its channel_state to CLOSED, and removes the channel record from the SessionChannelBindingTable, thus completing the control session migration across the secure listening port.

[0103] It should be noted that this process relies on the following core mechanisms to achieve cross-port session migration: 1) Session and channel decoupling mechanism The control session is identified by its session_id and associated with the underlying SecureChannel object through the SessionChannelBindingTable, thus preventing the control session from directly depending on the specific transport connection. This achieves decoupling between the session and the transport connection.

[0104] 2) Dual-channel transition mechanism During the migration process, the system allows the original communication channel and the target communication channel to coexist, forming: active_channel (original channel) + target_channel (new channel).

[0105] This mechanism ensures that control plane communication is not interrupted during the migration process.

[0106] 3) Atom switching mechanism Once the target channel is ready, the controller completes a one-time session switch by updating the active_channel_id field in ControlSession, enabling the atomic migration of the control session between different secure listening ports.

[0107] like Figure 5 The diagram shown is a flowchart of the migration failure rollback control provided in an embodiment of the present invention. (Refer to...) Figure 5 As an optional implementation, the security control and policy layer implements migration failure rollback control through the following steps: When a session migration anomaly is detected, a migration failure rollback is triggered, and the corresponding current active channel identifier and migration target channel identifier are determined based on the control session record. The migration target channel corresponding to the migration target channel identifier is closed through the migration control management module, and the control session is switched back to the single-channel operation state based on the initial active channel. Close the target migration channel and delete the session-channel binding relationship between the control session and the target migration channel in the session-channel binding table.

[0108] As a further optional implementation, the control session is switched from the migration target channel back to a single-channel operating state based on the initial active channel, specifically including: Clear or set the migration target channel identifier of the control session to NULL; Keep the current active channel identifier of the control session unchanged from the channel identifier of the initial active channel; Clear or set the history channel identifier of the control session to NULL; Update the migration state of the control session to either rollback or NORMAL.

[0109] Specifically, this invention implements a migration failure rollback process through the security control and policy layer. That is, during the migration of a cross-security listening port session, if the target communication channel fails to be established or the migration process fails to complete normally, the SDN controller executes the complete process of a control session rollback operation. Through the rollback mechanism, the controller can restore the original communication channel without terminating the control session, ensuring the continuity and stability of control plane communication. This process is applicable to scenarios where the control session is in a migration state (migration_state=MIGRATING) and the target communication channel has not successfully taken over control communication, as detailed below: 1. Migration Anomaly Trigger: During the control session migration process, the SDN controller detects an anomaly that prevents the migration process from completing normally, such as failure to establish the target communication channel, incomplete handshake, or interruption of the migration process. When a migration anomaly is detected, the SDN controller confirms that the migration_state of the corresponding ControlSession object is in the MIGRATING state and triggers the rollback process.

[0110] It should be noted that the specific implementation of anomaly detection and triggering conditions can be achieved using existing technologies or other methods, and this invention does not limit this.

[0111] 2. Identify rollback objects: The SDN controller identifies the channel information that needs to be rolled back based on the current ControlSession record, including: active_channel_id (current active communication channel); target_channel_id (target communication channel for migration).

[0112] During the incomplete migration phase, `active_channel_id` still points to the original communication channel, while `target_channel_id` points to the newly established communication channel that has not yet been migrated and taken over. The controller uses this information to determine the range of channels for the rollback operation.

[0113] 3. Close the target channel: The SDN controller performs a closing process on the SecureChannel corresponding to target_channel_id, including: 1) Stop receiving control messages on this channel; 2) Clear the message buffer queue for this channel; 3) Close the corresponding transport connection (transport_conn_id); 4) Update the channel_state of SecureChannel to CLOSED.

[0114] Subsequently, the controller removes the binding record corresponding to the channel_id from the SessionChannelBindingTable.

[0115] 4. Clean up migration status: After the target channel is closed, the SDN controller restores the migration-related fields in the ControlSession: 1) Clear or set ControlSession.target_channel_id to NULL; 2) Keep ControlSession.active_channel_id unchanged, so that it continues to point to the original communication channel; 3) Clear or restore ControlSession.previous_channel_id to NULL.

[0116] By performing the above operations, you can ensure that the control session is restored to single-channel operation.

[0117] 5. Restore Session Running State: The SDN controller updates the migration_state field of the ControlSession from the MIGRATING state to the ROLLED_BACK or NORMAL state, indicating that the migration operation has been terminated and rolled back. In this state, the control session continues to communicate using the control protocol through the original communication channel.

[0118] 6. Resume Normal Communication: After the rollback is complete, the SDN controller allows the device to continue normal control communication with the controller through the SecureChannel corresponding to active_channel_id. The control session's running state is restored to the pre-migration state, and the system can re-trigger a new migration process when subsequent conditions are met.

[0119] It should be noted that, to ensure safe recovery in the event of migration failure, this process relies on the following mechanisms: 1) Session state recovery mechanism. This is achieved by restoring key fields in ControlSession: active_channel_id, target_channel_id, previous_channel_id, and migration_state.

[0120] 2) Channel resource reclamation mechanism. For target SecureChannels created during the migration process but failing to successfully take over communication, the controller performs a complete shutdown and unbinding operation to prevent invalid channel residues from occupying system resources.

[0121] Single-channel operation is restored, ensuring that control communication continues through the original stable channel.

[0122] The system architecture of the present invention has been described above. The present invention will be further described below with reference to specific embodiments.

[0123] Example 1: TLS → TLCP Cross-Secure Listening Port Session Upgrade This embodiment describes a scenario where an SDN controller and a device have established a control session via the TLS protocol. When the controller determines, based on the security policy evaluation results, that the security level of the current session needs to be upgraded (e.g., a security policy adjustment leads to an increase in min_security_level, or the risk detection module determines that the TLS protocol poses a security risk), it triggers a cross-port session migration process from the secure listening port of the TLS protocol to the secure listening port of the TLCP protocol, completing the protocol upgrade without terminating the control session.

[0124] At the start of this embodiment, the controller has completed the session establishment process, and the status of each object field is as follows: 1) ControlSession (S1) session_id= S1 device_id= DEV_001 active_channel_id= C_tls previous_channel_id = NULL / / No migration history target_channel_id = NULL / / No target channel migration_state= NORMAL / / Normal operating status session_state= ACTIVE 2) SecureChannel (C_tls): channel_id= C_tls bind_session_id= S1 transport_conn_id= TCP_CONN_001 protocol_type= TLS local_port= TLS_PORT handshake_state= COMPLETED channel_state = BOUND / / Bound state 3) SessionChannelBindingTable: S1 → [C_tls].

[0125] The controller triggers an upgrade when one of the following conditions is met: 1) Security policy adjustment (SecurityPolicy.min_security_level increased, current TLS channel no longer meets the requirements); 2) The risk detection module determines that the TLS protocol has security risks; 3) The management plane issues an upgrade command, requiring a switch to the TLCP protocol.

[0126] After the controller confirms that the current session meets the migration conditions, it updates the migration_state field of ControlSession S1 from NORMAL to MIGRATING, indicating that the control session has entered the migration preparation phase. ControlSession S1: migration_state: NORMAL → MIGRATING.

[0127] like Figure 6 The diagram shown illustrates the state transition of the migration process provided in an embodiment of the present invention. The complete migration process is as follows: Step 1: Generate migration authorization token The controller generates a MigrationToken for ControlSession S1, which contains the following fields: MigrationToken: { session_id= S1 target_port= TLCP_PORT expire_time = T_current + Δt / / Complete the migration within the valid window token_signature= SIGN(S1 ∥ TLCP_PORT ∥ expire_time) / / Verification signature generated by the controller's private key } The token_signature is used to prevent unauthorized session takeovers and ensure that the device only performs cross-port migration operations when authorized by the controller.

[0128] Step 2: Issue migration instructions The controller sends a migration instruction message to device DEV_001 through the SecureChannel corresponding to the active_channel_id (i.e., C_tls) of ControlSession S1. The message carries the aforementioned MigrationToken. After receiving the migration instruction, the device parses the target_port field in the MigrationToken, learns that the target secure listening port is TLCP_PORT, and initiates a new connection request to that port.

[0129] Step 3: Establish a secure passage to the target The controller receives a connection request from the device to the TLCP_PORT and performs the following operations: Create a new SecureChannel object, denoted as C_tlcp; Assign a globally unique channel_id to C_tlcp; The fields of C_tlcp are initialized as follows: SecureChannel C_tlcp: { channel_id= C_tlcp bind_session_id = NULL / / To be filled in after token verification transport_conn_id= TCP_CONN_002 protocol_type= TLCP local_port= TLCP_PORT handshake_state= IN_PROGRESS channel_state=ESTABLISHING / / Establishment status } Step 4: Migration Authorization Verification The device carries a MigrationToken during the TLCP handshake process. The controller performs the following validity checks on the MigrationToken: 1) Verify whether the token_signature is valid (verify the controller signature); 2) Verify whether expire_time is within the valid time range (T_current ≤ expire_time); 3) Verify whether the session_id (S1) in the token matches an existing ControlSession record.

[0130] If any of the above checks fail, the connection request is rejected, C_tlcp is closed and its channel_state is updated to CLOSED, the migration process terminates, and the rollback process begins.

[0131] If all checks pass, proceed to step 5.

[0132] Step 5: Register the target channel After successful MigrationToken verification, the controller registers C_tlcp as the target channel of ControlSession S1 and performs the following field updates: 1) SecureChannel C_tlcp: bind_session_id: NULL → S1 2) ControlSession S1: target_channel_id: NULL → C_tlcp 3)SessionChannelBindingTable: S1 → [C_tls, C_tlcp] / / Add the target channel to the binding set At this point, ControlSession S1 is associated with two communication channels simultaneously, and the system enters the dual-channel coexistence phase: ControlSession S1: active_channel_id → SecureChannel C_tls(TLS_PORT, original channel); target_channel_id → SecureChannel C_tlcp (TLCP_PORT, new channel).

[0133] Step 6: New Channel Readiness Confirmation The controller continuously monitors the C_tlcp handshake_state. Once the TLCP handshake is complete, the controller updates the relevant C_tlcp state as follows: SecureChannel C_tlcp: handshake_state: IN_PROGRESS → COMPLETED channel_state: ESTABLISHING → READY When channel_state enters the READY state, it indicates that the target communication channel is ready to carry control session communication and can be atomically switched.

[0134] Step 7: Perform session atomic migration switch After the target channel enters the READY state, the controller performs an atomic operation to migrate the control session, updating the following fields in one go: ControlSession S1: previous_channel_id: NULL → C_tls / / Records the original channel, used for emptying and backtracking active_channel_id:C_tls→C_tlcp / / The new channel becomes the only active channel target_channel_id:C_tlcp→ NULL / / Clear the target channel field migration_state:MIGRATING → COMPLETED Synchronously update the SessionChannelBindingTable main mapping: SessionChannelBindingTable: S1 → [C_tls, C_tlcp] / / C_tls will be removed after being drained, C_tlcp is the active channel. After the above atomic operations are completed, C_tlcp becomes the only active communication channel for control session S1, and all new control messages are transmitted through C_tlcp.

[0135] Step 8: Empty the original channel The controller updates the channel_state of the SecureChannel corresponding to previous_channel_id (C_tls) to DRAIN state: SecureChannel C_tls: channel_state: BOUND → DRAIN In DRAIN state, C_tls no longer receives new control messages, but is only used to send or process the remaining data that has entered the transmission queue, ensuring the complete transmission of service data that is already in transit on the TLS channel and achieving zero data loss.

[0136] Dual-channel transition phase status: C_tlcp(BOUND) ← Carries all new control messages; C_tls(DRAIN) ← Only processes the remaining queue data, does not receive new messages.

[0137] Step 9: Close the original channel After the C_tls data buffer is completely emptied, the controller performs the following cleanup operations: 1) SecureChannel C_tls: channel_state: DRAIN → CLOSED transport_conn_id: TCP_CONN_001 corresponds to a closed transport connection. 2) ControlSession S1: previous_channel_id: C_tls → NULL / / Clear the history of closed channels 3)SessionChannelBindingTable: S1 → [C_tlcp] / / Remove the C_tls binding record At this point, the TLS→TLCP session upgrade migration across secure listening ports is complete.

[0138] After the migration is complete, the status of each object's fields is as follows: ControlSession (S1): session_id= S1 device_id= DEV_001 active_channel_id= C_tlcp previous_channel_id = NULL / / Cleared, no residual history target_channel_id= NULL migration_state= NORMAL / / Restores normal operation state (COMPLETED is followed by NORMAL) session_state= ACTIVE SecureChannel (C_tlcp): channel_id= C_tlcp bind_session_id= S1 transport_conn_id= TCP_CONN_002 protocol_type= TLCP local_port= TLCP_PORT handshake_state= COMPLETED channel_state= BOUND SecureChannel (C_tls): channel_state=CLOSED / / Closed, no longer participating in session communication SessionChannelBindingTable: S1 → [C_tlcp] The session identifier (S1) remains unchanged throughout the migration process, and the session ID held by the device does not need to be reassigned, thus enabling a smooth upgrade of the control session between different secure listening ports.

[0139] In this embodiment, the following key mechanism is applied: 1) Session and channel decoupling mechanism. Throughout the migration process, the session_id of ControlSession S1 remains unchanged, and the session_id held by the device side does not need to be reassigned. The control session is associated with the underlying SecureChannel through SessionChannelBindingTable, thereby achieving decoupling between the session layer and the transport layer, making the switching of protocol types transparent to the upper-layer control session.

[0140] 2) Dual-channel transition mechanism. During steps 5 (registering the target channel) to 7 (atomic switching), the system allows C_tls (the original channel) and C_tlcp (the new channel) to coexist and be associated with the same ControlSession. This mechanism ensures that control plane communication is not affected while the new channel is not yet ready; atomic switching is only performed after the new channel enters the READY state.

[0141] 3) Atomic switching mechanism. The field update operations in step 7 (assigning previous_channel_id, switching active_channel_id, clearing target_channel_id, and updating migration_state) are executed as atomic operations to prevent channel reference inconsistencies caused by intermediate states during the switching process.

[0142] 4) Migration authorization security mechanism. The MigrationToken contains token_signature (controller private key signature) and expire_time (valid time window) to prevent the token from being forged or replayed, and to ensure that only devices holding legitimate authorization tokens can initiate migration connections on the designated port.

[0143] 5) Emptying guarantee mechanism. The original channel C_tls enters the DRAIN state after migration and switching instead of being closed immediately, ensuring that the remaining control messages that have entered the transmission queue on the TLS channel are transmitted completely, achieving zero loss of control plane data.

[0144] Example 2: TLCP → TLS Cross-Security Listening Port Session Degradation This embodiment describes a scenario where an SDN controller and a device have established a control session via the TLCP protocol. When the controller detects an anomaly in the TLCP channel (such as handshake failure or certificate expiration) or the security policy allows downgrading to the TLS protocol under the current conditions, it triggers a cross-port session downgrade migration process from the TLCP protocol's secure listening port to the TLS protocol's secure listening port. The core constraint of this embodiment is that the downgrade operation must be based on `SecurityPolicy.downgrade_allowed`, and the channel switch must be completed without terminating the control session, ensuring the continuity of control plane communication.

[0145] At the start of this embodiment, the controller has completed the session establishment process, and the status of each object field is as follows: 1) ControlSession (S2): session_id= S2 device_id= DEV_002 active_channel_id= C_tlcp previous_channel_id = NULL / / No migration history target_channel_id = NULL / / No target channel migration_state= NORMAL / / Normal operating status session_state= ACTIVE SecureChannel (C_tlcp): channel_id= C_tlcp bind_session_id= S2 transport_conn_id= TCP_CONN_001 protocol_type= TLCP local_port= TLCP_PORT handshake_state= COMPLETED channel_state= BOUND 2) SecurityPolicy (Currently in effect): min_security_level= LEVEL_1 / / Allows the TLS protocol to meet the minimum security level downgrade_allowed= true / / Explicitly allow downgrade operations preferred_protocol_order = [TLCP, TLS] 3) SessionChannelBindingTable: S2 → [C_tlcp].

[0146] The controller triggers the degradation process when one of the following conditions is met: 1) TLCP handshake failure or persistent communication anomalies (such as handshake timeout or message parsing error); 2) The device certificate has expired or the certificate chain verification has failed, causing TLCP secure communication to be unable to be maintained; 3) The risk assessment module determines that the current TLCP channel is unavailable; 4) Equipment capability change notice, indicating that it no longer supports the TLCP protocol.

[0147] Pre-compliance verification of policies: Before executing a downgrade migration, the controller must first check the currently effective SecurityPolicy to confirm that the downgrade_allowed field value is true. If downgrade_allowed is false, the downgrade operation is not allowed, and the controller must not execute this process. Instead, it should proceed to alarm handling or session termination to prevent downgrade operations that violate security policies from occurring. In this embodiment, downgrade_allowed = true, and the policy verification passes.

[0148] After the policy verification passes, the controller updates the migration_state field of ControlSession S2 from NORMAL to MIGRATING, indicating that the control session has entered the migration preparation phase. ControlSession S2: migration_state: NORMAL → MIGRATING.

[0149] like Figure 7 The diagram shown illustrates the state transition of the degradation migration process provided in an embodiment of the present invention. The specific degradation process is as follows: Step 1: Generate migration authorization token The controller generates a MigrationToken for ControlSession S2, which contains the following fields: MigrationToken: { session_id= S2 target_port= TLS_PORT expire_time = T_current + Δt / / The migration must be completed within the valid time window. token_signature= SIGN(S2 ∥ TLS_PORT ∥ expire_time) / / Verification signature generated by the controller's private key } The token_signature is used to prevent unauthorized session takeovers and ensure that the device only performs cross-port degradation migration operations with the authorization of the controller. Compared to normal upgrade scenarios, the effective time window (expire_time) of the MigrationToken in degradation scenarios can be appropriately narrowed according to the actual triggering reason to reduce the risk of token abuse.

[0150] Step 2: Issue migration instructions The controller sends a migration instruction message to device DEV_002 through the SecureChannel corresponding to the active_channel_id (i.e., C_tlcp) of ControlSession S2. The message carries the aforementioned MigrationToken.

[0151] Special note for degradation scenarios: If the triggering cause is a serious anomaly in the TLCP channel itself (such as a handshake failure leading to channel unavailability), the original channel C_tlcp may not be able to properly handle the issuance of migration instructions. In this case, the controller should use an out-of-band notification mechanism (such as a management plane channel) to transmit the migration instructions to the device, or pre-configure a degradation reconnection strategy on the device side (automatically attempt to initiate a connection to the TLS_PORT and carry the already held session_id information when the TLCP connection fails). This embodiment describes the main path as if the original channel can still be used for instruction issuance.

[0152] After receiving the migration instruction, the device parses the target_port field in the MigrationToken to learn that the target secure listening port is TLS_PORT, and then initiates a new connection request to that port.

[0153] Step 3: Establish a secure passage to the target 1) The controller receives the connection request initiated by the device to the TLS_PORT and performs the following operations: 2) Create a new SecureChannel object, denoted as C_tls; 3) Assign a globally unique channel_id to C_tls; The fields of C_tls are initialized as follows: SecureChannel C_tls: { channel_id= C_tls bind_session_id = NULL / / To be filled in after token verification transport_conn_id= TCP_CONN_002 protocol_type= TLS local_port= TLS_PORT handshake_state= IN_PROGRESS channel_state=ESTABLISHING / / Establishment status } Step 4: Migration Authorization Verification The device carries a MigrationToken during the TLS handshake. The controller performs the following validity checks on the MigrationToken: 1) Verify whether the token_signature is valid (verify the controller signature); 2) Verify whether expire_time is within the valid time range (T_current ≤ expire_time); 3) Verify whether the session_id (S2) in the token matches an existing ControlSession record; 4) Verify whether the target port is consistent with the degradation path of the SecurityPolicy, that is, whether the TLS protocol meets the min_security_level requirement.

[0154] If any of the above checks fail, the connection request is rejected, C_tls is closed and its channel_state is updated to CLOSED, the migration process terminates, and the rollback process begins. The original channel C_tlcp continues to carry control communication (if the original channel is still available).

[0155] If all checks pass, proceed to step 5.

[0156] Step 5: Register the target channel After successful MigrationToken verification, the controller registers C_tls as the target channel for ControlSession S2 and performs the following field updates: 1) SecureChannel C_tls: bind_session_id: NULL → S2 2) ControlSession S2: target_channel_id: NULL → C_tls 3)SessionChannelBindingTable: S2 → [C_tlcp, C_tls] / / Add the target channel to the binding set At this point, ControlSession S2 is associated with two communication channels simultaneously, and the system enters the dual-channel coexistence phase: ControlSession S2 active_channel_id → SecureChannel C_tlcp (TLCP_PORT, original channel) target_channel_id → SecureChannel C_tls(TLS_PORT, new channel) Step 6: New Channel Readiness Confirmation The controller continuously monitors the C_tls handshake_state. Once the TLS handshake is complete, the controller updates the relevant C_tls state as follows: SecureChannel C_tls: handshake_state: IN_PROGRESS → COMPLETED channel_state:ESTABLISHING → READY When channel_state enters the READY state, it indicates that the target communication channel is ready to carry control session communication and can be atomically switched.

[0157] Step 7: Perform session atomic migration switch After the target channel enters the READY state, the controller performs an atomic operation to migrate the control session, updating the following fields in one go: ControlSession S2: previous_channel_id: NULL → C_tlcp / / Records the original channel, used for emptying and exception backtracking active_channel_id:C_tlcp→C_tls / / The new channel becomes the only active channel target_channel_id:C_tls → NULL / / Clear the target channel field migration_state:MIGRATING → COMPLETED Synchronously update SessionChannelBindingTable: SessionChannelBindingTable: S2 → [C_tlcp, C_tls] / / C_tlcp will be removed after being drained, C_tls is the active channel. After the above atomic operations are completed, C_tls becomes the sole active communication channel for control session S2, and all new control messages are transmitted through C_tls.

[0158] Step 8: Empty the original channel The controller updates the channel_state of the SecureChannel corresponding to previous_channel_id (C_tlcp) to DRAIN state: SecureChannel C_tlcp: channel_state: BOUND → DRAIN In DRAIN state, C_tlcp no longer receives new control messages, but is only used to send or process the remaining data that has entered the transmission queue, ensuring the complete transmission of service data that is already in transit on the TLCP channel and achieving zero data loss.

[0159] Special note for degradation scenarios: If the original TLCP channel is completely unavailable during the triggering phase (e.g., the transmission connection has been broken), skip the DRAIN waiting process, directly set the channel_state of C_tlcp to CLOSED, and immediately execute the closing operation in step 9.

[0160] Dual-channel transition phase status: C_tls(BOUND) ← Carries all new control messages C_tlcp (DRAIN) ← Only processes the remaining queue data and does not receive new messages.

[0161] Step 9: Close the original channel After the C_tlcp data buffer is completely emptied, the controller performs the following cleanup operations: 1) SecureChannel C_tlcp: channel_state: DRAIN → CLOSED transport_conn_id: TCP_CONN_001 corresponds to a closed transport connection. 2) ControlSession S2: previous_channel_id: C_tlcp → NULL / / Clear the history of closed channels migration_state:COMPLETED → NORMAL 3)SessionChannelBindingTable: S2 → [C_tls] / / Remove the C_tlcp binding record At this point, the TLCP→TLS session downgrade migration across secure listening ports is complete.

[0162] After the migration is complete, the status of each object's fields is as follows: 1) ControlSession (S2): session_id= S2 device_id= DEV_002 active_channel_id= C_tls previous_channel_id = NULL / / Cleared target_channel_id= NULL migration_state= NORMAL / / Restore normal operation state session_state= ACTIVE 2) SecureChannel (C_tls): channel_id= C_tls bind_session_id= S2 transport_conn_id= TCP_CONN_002 protocol_type= TLS local_port= TLS_PORT handshake_state= COMPLETED channel_state= BOUND 3) SecureChannel (C_tlcp): channel_state=CLOSED / / Closed, no longer participating in session communication 4) SessionChannelBindingTable: S2 → [C_tls].

[0163] The session identifier (S2) remains unchanged throughout the downgrade migration process, and the session ID held by the device does not need to be reassigned.

[0164] The differences between Example 2 and Example 1 are as follows: 1) Policy Pre-Constraints. Downgrade scenarios introduce mandatory pre-validation using `SecurityPolicy.downgrade_allowed`, which must be completed before the `migration_state` changes to `MIGRATING`. Upgrade scenarios do not have this constraint because upgrading the security level does not require policy authorization. If `downgrade_allowed` is false, the migration process must not be initiated to prevent downgrade operations that violate the security policy.

[0165] 2) Handling of anomalies in the original channel. In the upgrade scenario, the original channel C_tls remains running normally throughout the migration and can reliably carry out the issuance of migration instructions. In the downgrade scenario, the triggering cause may be that the original channel C_tlcp itself is abnormal. It is necessary to consider the out-of-band issuance path of migration instructions and the special handling path of skipping DRAIN and directly shutting down when the original channel is unavailable.

[0166] 3) Channel Protocol Direction. In this embodiment, the original channel uses a high-security protocol (TLCP), and the new channel uses a lower-security protocol (TLS). The two are symmetrical in process structure to those in Embodiment 1, and the core mechanisms (session and channel decoupling, dual-channel transition, atomic switching, and drain closure) are completely consistent. The session_id remains unchanged before and after the migration.

[0167] Compared with the prior art, the present invention has the following advantages: 1. Decoupled Communication Management Capability between Control Session and Transmission Channel: This application introduces an independent control session object (ControlSession) and a session channel binding table (SessionChannelBindingTable) to abstract the control session from the underlying transmission connection, achieving decoupled management of the control session and transmission channel. In this model, the upper-layer control protocol runs on top of the logical control session, and the underlying transmission channel can be independently adjusted according to security policies or communication states without affecting the upper-layer control semantics. Compared to the strong binding mode of "session as connection" in traditional control protocols, this application enables the control session to dynamically migrate between different security channels, significantly improving the system's flexibility and evolvability in multi-security protocol environments, and laying the foundation for a session migration mechanism across secure listening ports.

[0168] 2. Smooth Control Session Migration Ability Across Secure Listening Ports: This application proposes a control session migration mechanism across secure listening ports. The system can establish new target secure communication channels on different secure listening ports and, combined with session channel binding relationships, achieve smooth migration of control sessions between different protocol channels (such as TLS, TLCP, etc.). During the migration process, through the "coexistence of old and new channels combined with atomic switching of session bindings" mechanism, control traffic seamlessly switches from the old channel to the new channel, and the upper-layer control protocol does not need to be aware of the underlying protocol changes. Compared with existing methods that require disconnection and reconnection or re-establishment of control sessions, this application achieves truly seamless protocol switching, significantly improving the continuity and stability of control plane communication.

[0169] 3. Zero-Packet-Loss Smooth Migration Capability Based on Dual-Channel Transition and Draining Mechanism: This application introduces a dual-channel short-term coexistence mechanism during session migration. After the new channel is established and ready, the old channel is placed in a drained state to ensure the orderly transmission and acknowledgment of incomplete data in the old channel, thereby achieving zero-loss migration of control messages. Compared with the common direct switching or forced connection closure methods in existing technologies, this application effectively avoids problems such as control message loss and state inconsistency. In high-reliability control scenarios, it can significantly reduce the risk of service interruption and has significant engineering application value.

[0170] 4. Atomic Operation-Based Session Binding Switching and State Consistency Guarantee: This application uses atomic operations to switch the binding relationship between session identifiers and channel identifiers during session migration. By maintaining key state fields such as the previous channel identifier (previous_channel_id) and migration state (migration_state), it ensures that the session is bound to only one valid communication channel at any given time. This mechanism guarantees the consistency and determinism of the system state during migration, effectively avoiding dual-active channel conflicts or invalid binding issues. Compared to existing technologies that lack explicit atomic switching mechanisms, this application can significantly reduce the risk of state disorder and improve the predictability of system behavior in complex migration scenarios.

[0171] 5. Rapid Rollback and System Self-Recovery Capabilities in Migration Failure: This application introduces a rapid rollback mechanism based on the previous channel identifier (previous_channel_id). When an anomaly occurs in the new channel, the system can complete session binding and rollback to the old channel and restore business communication within milliseconds. Simultaneously, it combines a migration state machine (NORMAL / MIGRATING / ROLLED_BACK / FAILED) for fine-grained control of the migration process, achieving anti-vibration handling. Compared to existing technologies that require re-establishing connections or rely on manual intervention after migration failure, this application significantly improves the system's self-recovery capability and operational stability, effectively reducing operational complexity.

[0172] 6. Session-layer secure migration control capabilities based on migration tokens: This application introduces a migration token mechanism to authorize and verify the legitimacy of session migration behavior when establishing a new connection across listening ports. This ensures that only authorized legitimate devices can complete session migration operations, effectively preventing unauthorized session hijacking or forged migration requests. Compared to existing technologies that rely solely on connection-level authentication, this application introduces an additional security control mechanism at the session layer, further enhancing the security of control plane communication and providing more comprehensive security guarantees for control plane communication in multi-security protocol environments.

[0173] like Figure 8 The diagram shows the steps of the control session binding and migration method across secure listening ports provided in an embodiment of the present invention. (Refer to...) Figure 8 This invention provides a method for binding and migrating control sessions across secure listening ports, implemented using the aforementioned system for binding and migrating control sessions across secure listening ports, comprising the following steps: S101. Establish a control session through the security control and policy layer, and bind the control session to the communication channel; S102. When the migration action is triggered, session migration across security listening ports is achieved through the security control and policy layer; S103. When a session migration anomaly is detected, rollback control for migration failure is implemented through the security control and policy layer.

[0174] It is understood that the content of the above system embodiments is applicable to this method embodiment. The specific functions implemented in this method embodiment are the same as those in the above system embodiments, and the beneficial effects achieved are also the same as those achieved in the above system embodiments.

[0175] This invention also provides an electronic device, comprising: a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for communication between the processor and the memory. When the program is executed by the processor, it implements the aforementioned method for binding and migrating control sessions across secure listening ports. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0176] like Figure 9 The diagram shown is a hardware structure schematic of an electronic device provided in an embodiment of the present invention. (Refer to...) Figure 9 This invention provides an electronic device, comprising: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present invention. The memory 902 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 902 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 to execute the control session binding and migration method across secure listening ports according to the embodiments of this invention. The input / output interface 903 is used to implement information input and output; The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904); The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0177] It is understood that the content of the above system embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above system embodiments, and the beneficial effects achieved are also the same as those achieved by the above system embodiments.

[0178] like Figure 10 The diagram shown is a structural schematic of the storage medium provided in an embodiment of the present invention. (Refer to...) Figure 10 The present invention also provides a storage medium, which is a computer-readable storage medium for computer-readable storage. The storage medium stores one or more programs 1001, which can be executed by one or more processors to implement the above-described method for binding and migrating control sessions across security listening ports.

[0179] It is understood that the content of the above system embodiments is applicable to this storage medium embodiment. The specific functions implemented by this storage medium embodiment are the same as those of the above system embodiments, and the beneficial effects achieved are also the same as those achieved by the above system embodiments.

[0180] This invention also discloses a computer program product, including a computer program that, when executed by a processor, implements the above-described method for binding and migrating control sessions across secure listening ports.

[0181] It is understood that the content of the above system embodiments is applicable to the present program product embodiments. The specific functions implemented by the present program product embodiments are the same as those of the above system embodiments, and the beneficial effects achieved are also the same as those achieved by the above system embodiments.

[0182] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0183] The embodiments described in this invention are for the purpose of more clearly illustrating the technical solutions of the embodiments of this invention, and do not constitute a limitation on the technical solutions provided by the embodiments of this invention. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this invention are also applicable to similar technical problems.

[0184] The terms "first," "second," "third," "fourth," etc. (if present) in the specification and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0185] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the aforementioned blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0186] Furthermore, although the invention has been described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the aforementioned functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional skill of an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.

[0187] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0188] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0189] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the aforementioned program can be printed, because the aforementioned program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0190] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0191] In the foregoing description of this specification, references to terms such as "one embodiment," "another embodiment," or "some embodiments" indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0192] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0193] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A control session binding and migration system across secure listening ports, characterized in that, include: The multi-listening port access layer is used to provide access capabilities for multiple security protocols through multiple listening ports; A multi-security protocol adaptation layer is used to uniformly adapt to different security protocols; The security control and policy layer is used to decouple control sessions and communication channels and enable cross-port migration capabilities. The control protocol management layer is used to implement protocol management in the control plane. The control and business layer is used to implement the business logic of the control plane. The security control and strategy layer includes: The secure channel management module is used to uniformly encapsulate transmission connections of different security protocols and provide a consistent channel interface; The unified security session abstraction module is used to model control sessions in a unified manner, obtain the session unique identifier, the current active channel identifier, the migration target channel identifier, the historical channel identifier, and the migration status, and realize the dynamic binding and switching between control sessions and communication channels based on the session-channel binding table; The migration control management module implements session migration control across security listening ports based on dual-channel management mechanism, atomic switching mechanism, channel emptying mechanism and rollback control mechanism; The security capability negotiation module is used to detect the protocol capabilities supported by the client and determine the capability negotiation result; The session context management module is used to maintain and control sessions; The security policy decision module is used to determine the corresponding target security level and target communication protocol based on the capability negotiation results.

2. The control session binding and migration system across secure listening ports according to claim 1, characterized in that, The security control and policy layer establishes a control session through the following steps: Continuously monitor the monitoring port and receive access connection requests for the monitoring port, and verify the legitimacy of the access connection requests; Once the legitimacy verification is successful, the corresponding secure channel object is created and a channel identifier is assigned through the secure channel management module. The security capability negotiation module detects the protocol capabilities supported by the client and determines the capability negotiation result. The security policy decision module performs matching analysis on the capability negotiation results according to the preset security policy to determine the target security level and target communication protocol adopted by the control session. Based on the capability negotiation results, the target security level, and the target communication protocol, a control session object is created and a unique session identifier is assigned.

3. A control session binding and migration system across secure listening ports according to claim 2, characterized in that, The security control and policy layer binds the control session and communication channel through the following steps: The session unique identifier of the control session object is associated and bound with the channel identifier of the secure channel object to obtain the session channel binding relationship; Write the session channel binding relationship into the session-channel binding table.

4. A control session binding and migration system across secure listening ports according to claim 1, characterized in that, The security control and policy layer implements session migration across secure listening ports through the following steps: When a migration action is triggered, the controller generates corresponding migration authorization information through the migration control management module and issues migration instructions to the client based on the migration authorization information; The client determines the target listening port according to the migration instruction and initiates a connection request to the target listening port corresponding to the controller. After receiving the connection request from the target listening port, the controller creates a migration channel object and assigns a migration channel identifier through the secure channel management module. The controller verifies the validity of the migration authorization information sent by the client. If the validity verification is successful, it registers the migration target channel according to the migration channel object, and binds the session unique identifier of the control session with the channel identifier of the migration target channel and writes it into the session-channel binding table. Once the target migration channel completes the security protocol handshake, the control session is migrated from the initial active channel to the target migration channel through the security channel management module. Once the session migration is complete, the initial active channel is emptied so that it no longer receives new control messages and is only used to send or process the remaining data that has entered the transmission queue. When the transmission queue of the initial active channel is cleared, the initial active channel is closed, and the corresponding session-channel binding relationship is deleted from the session-channel binding table.

5. A control session binding and migration system across secure listening ports according to claim 4, characterized in that, The process of migrating the control session from the initial active channel to the target migration channel specifically includes: Set the historical channel identifier of the control session to the channel identifier of the initial active channel; Update the current active channel identifier of the control session to the channel identifier of the migration target channel; Clear or set the migration target channel identifier of the control session to NULL; Update the migration status of the control session to complete migration.

6. A control session binding and migration system across secure listening ports according to claim 1, characterized in that, The security control and policy layer implements migration failure rollback control through the following steps: When a session migration anomaly is detected, a migration failure rollback is triggered, and the corresponding current active channel identifier and migration target channel identifier are determined based on the control session record. The migration control management module closes the migration target channel corresponding to the migration target channel identifier and switches the control session back to the single-channel operation state based on the initial active channel. Close the migration target channel and delete the session channel binding relationship between the control session and the migration target channel in the session-channel binding table.

7. A control session binding and migration system across secure listening ports according to claim 6, characterized in that, Switching the control session from the migration target channel back to a single-channel operation state based on the initial active channel specifically includes: Clear or set the migration target channel identifier of the control session to NULL; Keep the current active channel identifier of the control session unchanged, and keep the channel identifier of the initial active channel unchanged; Clear or set the history channel identifier of the control session to NULL; Update the migration state of the control session to either rollback or NORMAL.

8. A method for binding and migrating control sessions across secure listening ports, characterized in that, For implementation via a control session binding and migration system across a secure listening port as described in any one of claims 1 to 7, the following steps are included: A control session is established through the security control and policy layer, and the control session is bound to the communication channel. When a migration action is triggered, session migration across secure listening ports is achieved through the security control and policy layer. When a session migration anomaly is detected, the migration failure rollback control is implemented through the security control and policy layer.

9. An electronic device, characterized in that, The electronic device includes a memory, a processor, a computer program stored in the memory and executable on the processor, and a data bus for enabling communication between the processor and the memory. When the computer program is executed by the processor, it implements the control session binding and migration method across a secure listening port as described in claim 8.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the control session binding and migration method across secure listening ports as described in claim 8.

Images