A method and system for managing control interface protocol message processing

Abstract

This application relates to a management and control interface protocol message processing method and system, belonging to the field of optical communication network technology. The method includes: identifying fragmented messages and complete messages in a management and control interface protocol message stream; assembling fragmented messages belonging to the same ME instance to obtain a complete ME instance; parsing the dependencies between the complete ME instance and other ME instances to obtain a set of prerequisite dependencies; and scheduling the complete ME instance to a worker thread pool for execution based on the set of prerequisite dependencies. This method can improve the stability of ONU operation.

Description

Technical Field

[0001] This application relates to the field of optical communication network technology, and in particular to a management and control interface protocol message processing method and apparatus. Background Technology

[0002] In a Gigabit Passive Optical Network (GPON) system, the Optical Line Terminal (OLT) manages and configures the Optical Network Units (ONUs) through the Management and Control Interface (OMCI) protocol. According to the ITU-T G.988 standard, the data payload of a complete OMCI protocol message is only 32 bytes. However, many instances of Management Entities (MEs) contain multiple attributes, and their total length often exceeds 32 bytes (e.g., a PPPoE WAN connection configuration, including name, VLAN ID, account, password, etc., exceeds 50 bytes). Therefore, the OLT must split a complete ME configuration into multiple OMCI protocol messages for distribution.

[0003] Existing ONUs typically employ a serial processing model: they process management and control interface protocol messages issued by the OLT sequentially, only starting to process the next message after the previous one has been completed. This approach has the following drawbacks: 1. Improper handling of fragmented messages leads to configuration anomalies: When the existing ONU's serial processing model receives the first fragmented message, it often cannot determine whether the message is part of a complete configuration. If the ONU attempts to create or modify the ME before receiving all fragmented messages, the configuration information will be incomplete, causing abnormal business functions (such as PPPoE dialing failing due to missing password). 2. Process freezes and poor compatibility: Different vendors' OLTs have differences in the order and interval of sending fragmented messages. In the existing serial model, if a transaction cannot be completed due to the loss or delay of a fragmented message, the entire configuration process will stop, the ONU cannot recover automatically, and can only wait for the OLT to time out and resend or restart the process; 3. Limitations of rigid transactions: Although existing technologies have proposed transaction rollback mechanisms, they employ "all-or-nothing" rigid transactions. When the configuration includes non-core optional parameters, if the configuration fails due to an optional parameter (such as an unimportant description field), the rigid transaction will roll back the entire core configuration as well, reducing the configuration success rate and increasing the retry burden on the OLT. 4. Lack of accurate status feedback: When configuration fails due to message loss, the existing ONU usually only returns a "failed" status, which cannot tell the OLT which specific attributes are missing. As a result, the OLT can only blindly retransmit all messages, which is inefficient. Summary of the Invention

[0004] Therefore, it is necessary to provide a management control interface protocol message processing method and system to address the technical problem of ONU instability caused by improper processing of fragmented management control interface protocol messages in existing technologies. The specific technical solution is as follows: Firstly, this application proposes a management control interface protocol message processing method, comprising the following steps: S1: Identify fragmented messages and complete messages in the management control interface protocol message stream, wherein the fragmented messages and complete messages are configuration messages of multiple different ME instances; S2: Assemble fragmented messages belonging to the same ME instance to obtain a complete ME instance; S3: Analyze the dependencies between the complete ME instance and other ME instances to obtain the set of prerequisite dependencies; S4: Based on the aforementioned set of prerequisite dependencies, schedule the complete ME instance to the worker thread pool for execution.

[0005] Further, the method for identifying fragmented messages and complete messages in step S1 is as follows: parse the header of the management control interface protocol message, extract key fields, the key fields include management entity identifier, instance number, message type, and attribute mask. If the attribute mask includes preset mandatory attributes, the management control interface protocol message is determined to be a complete message. If the attribute mask does not include preset mandatory attributes, the management control interface protocol message is determined to be a fragmented message, and a fragment descriptor is generated. The fragment descriptor includes management entity identifier, instance number, message type, attribute mask, message payload, and receiving timestamp.

[0006] Further, the specific content of assembling fragmented messages belonging to the same ME instance in step S2 is as follows: A fragment cache table is opened in the ONU memory, with each cache record corresponding to an assembled ME instance. The cache record includes a management entity identifier, instance number, received attribute mask, attribute value array, and fragment counter. When a fragment descriptor is received, the fragment cache table is searched for a cache record with the same management entity identifier and instance number. If it exists, the received attribute mask of that record is updated, and the attribute values ​​carried by the new fragment message are stored in the attribute value array. Simultaneously, the fragment counter is incremented by 1. When the received attribute mask of the cache record includes preset mandatory attributes, the complete ME instance is output and the corresponding cache record is deleted.

[0007] The cache record also includes a timeout timer. When there is no identical management entity identifier and instance number, a new cache record needs to be created. The timeout timer is started and a preset time threshold is set. When the timeout timer reaches the preset time threshold, if the received attribute mask of the cache record does not include the preset required attributes, the cache record is marked as a missing record and a missing report is generated.

[0008] Further, the process of obtaining the prerequisite dependency set in step S3 is as follows: based on the complete ME instance, traverse the dependency rule base to obtain the dependency rule that matches the complete ME instance; check whether there is a ME instance that satisfies the dependency rule in the ME instance in the management information base or the ME instance to be created in the transaction manager; if not, add the dependency rule to the prerequisite dependency set; if it exists, keep the prerequisite dependency set as an empty set.

[0009] Further, the specific process of step S4 is as follows: Store ME instances with non-empty prerequisite dependency sets in the waiting queue, and store ME instances with empty prerequisite dependency sets in the ready queue; use the scheduler to monitor the ME instances in the waiting queue. When a new ME instance is processed, check all ME instances in the waiting queue. If all dependencies in the prerequisite dependency set of the ME instance have been successfully processed, then transfer the ME instance from the waiting queue to the ready queue. Use the scheduler to monitor the idle threads in the ready queue and the thread pool at the same time. When the ready queue is not empty and there are idle threads, the scheduler takes out the ME instance from the ready queue and assigns it to the idle thread. The idle thread then calls the management control interface protocol proxy module to perform the configuration operation.

[0010] Furthermore, the creation or modification of each ME instance is defined as a logical transaction, and different handling strategies are adopted according to the error type, which includes critical errors and non-critical errors. The critical errors are those that cause the ME instance to malfunction, and a rollback strategy is adopted. The non-critical errors are those that do not affect the normal operation (core functions) of the ME instance, and a flexible skip strategy is adopted.

[0011] The rollback strategy is as follows: when an operation within a transaction fails due to a critical error, the transaction manager aborts the transaction and reads the transaction's operation log in reverse order, generating a reverse operation message for each successfully executed operation. The scheduler then allocates threads for execution based on the reverse operation message.

[0012] The specific content of the flexible skip strategy is as follows: when an operation within a transaction fails due to a non-critical error, the transaction manager does not abort the entire transaction, but records the error log and marks the corresponding attribute of the ME instance in the MIB, while updating the transaction status to partially successful; the transaction continues to execute other operations, and when the transaction is finally completed, a partially successful result report is generated, which includes a list of successful operations and information on failed operations.

[0013] Secondly, this application proposes a management control interface protocol message processing system, including a message receiving and fragment identification module, a fragment assembly and integrity verification module, a dependency resolution module, an asynchronous parallel scheduling module, a flexible transaction management module, and a precise status reporting module. The message receiving and fragment identification module receives management control interface protocol message streams and identifies fragmented messages within them, sending the fragmented messages to the fragment assembly and integrity verification module. This module assembles fragmented messages belonging to the same ME instance to obtain a complete ME instance and sends it to the dependency resolution module. The dependency resolution module resolves the dependencies between the complete ME instance and other ME instances, obtaining a set of prerequisite dependencies. The asynchronous parallel scheduling module schedules the complete ME instance to a worker thread pool for execution based on the set of prerequisite dependencies. The flexible transaction management module defines the creation or modification of each ME instance as a logical transaction and adopts different processing strategies based on the error type. The precise status reporting module generates a final processing result report and reports it to the OLT.

[0014] Beneficial effects: This application proposes a management control interface protocol message processing method and system. By assembling and verifying the integrity of fragmented messages, it ensures that the ONU will not create or modify ME instances based on incomplete configuration information, fundamentally eliminating business function anomalies caused by configuration fragmentation and improving the stability of ONU operation. At the same time, the proposed flexible skip strategy avoids unnecessary process rollback and retries, further improving the efficiency of ONU operation. Attached Figure Description

[0015] Figure 1 This is a flowchart of a management control interface protocol message processing method according to an embodiment of this application; Figure 2 This is a schematic diagram of the fragment assembly and integrity verification process in an embodiment of this application; Figure 3 This is a schematic diagram of the transaction state machine in an embodiment of this application; Figure 4 This is an overall architecture diagram of a management control interface protocol message processing system according to an embodiment of this application; Figure 5 This is a timing diagram of message processing in an embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0017] Example 1 This embodiment provides a method for processing management control interface protocol messages, the flowchart of which is shown below. Figure 1 As shown, it includes the following steps: S1: Identify fragmented messages and complete messages in the management control interface protocol message stream, wherein the fragmented messages and complete messages are configuration messages of multiple different ME instances; It should be noted that the method for identifying fragmented messages and complete messages in step S1 is as follows: parse the header of the management control interface protocol message and extract key fields. The key fields include the management entity identifier, instance number, message type, and attribute mask. If the attribute mask includes preset mandatory attributes, the management control interface protocol message is determined to be a complete message. If the attribute mask does not include preset mandatory attributes, the management control interface protocol message is determined to be a fragmented message, and a fragment descriptor is generated. The fragment descriptor includes the management entity identifier, instance number, message type, attribute mask, message payload, and reception timestamp.

[0018] S2: Assemble fragmented messages belonging to the same ME instance to obtain a complete ME instance; It should be noted that the specific content of assembling fragmented messages belonging to the same ME instance in step S2 is as follows: A fragment cache table is opened in the ONU memory, and each cache record corresponds to an assembled ME instance. The cache record includes a management entity identifier, instance number, received attribute mask, attribute value array, and fragment counter. When a fragment descriptor is received, the fragment cache table is checked to see if there is a cache record with the same management entity identifier and instance number. If it exists, the received attribute mask of the record is updated, and the attribute values ​​carried by the new fragment message are stored in the attribute value array. At the same time, the fragment counter is incremented by 1. When the received attribute mask of the cache record includes the preset required attributes, the complete ME instance is output and the corresponding cache record is deleted.

[0019] The cache record also includes a timeout timer. When there is no identical management entity identifier and instance number, a new cache record needs to be created. The timeout timer is started and a preset time threshold is set. When the timeout timer reaches the preset time threshold, if the received attribute mask of the cache record does not include the preset required attributes, the cache record is marked as a missing record and a missing report is generated.

[0020] S3: Analyze the dependencies between the complete ME instance and other ME instances to obtain the set of prerequisite dependencies; It should be noted that the process of obtaining the prerequisite dependency set in step S3 is as follows: based on the complete ME instance, traverse the dependency rule base to obtain the dependency rule that matches the complete ME instance; check whether there is a ME instance that satisfies the dependency rule in the ME instance in the management information base or the ME instance to be created in the transaction manager; if not, add the dependency rule to the prerequisite dependency set; if it exists, keep the prerequisite dependency set as an empty set.

[0021] S4: Based on the aforementioned set of prerequisite dependencies, schedule the complete ME instance to the worker thread pool for execution.

[0022] It should be noted that the specific process of step S4 is as follows: ME instances with non-empty prerequisite dependency sets are stored in the waiting queue, and ME instances with empty prerequisite dependency sets are stored in the ready queue. The scheduler monitors the ME instances in the waiting queue. When a new ME instance finishes processing, all ME instances in the waiting queue are checked. If all dependencies in the prerequisite dependency set of the ME instance have been successfully processed, the ME instance is transferred from the waiting queue to the ready queue. The scheduler simultaneously monitors the ready queue and the idle threads in the thread pool. When the ready queue is not empty and there are idle threads, the scheduler retrieves the ME instance from the ready queue and assigns it to an idle thread. The idle thread then calls the management control interface protocol proxy module to perform configuration operations.

[0023] The fragment caching and integrity verification mechanism proposed in this embodiment establishes an independent cache area for each ME instance being configured, monitors the configuration integrity in real time, and triggers entity creation only after all required attributes are collected, avoiding business anomalies caused by incomplete information; the two-stage dependency analysis of "assembly first and then parsing" moves the trigger condition for dependency analysis from "receiving the message" to "ME instance complete", avoiding false dependency judgments caused by disordered fragment message order, making the scheduling logic simpler and more robust.

[0024] Example 2 This embodiment provides a management control interface protocol message processing system, including a message receiving and fragment identification module, a fragment assembly and integrity verification module, a dependency parsing module, an asynchronous parallel scheduling module, a flexible transaction management module, and a precise status reporting module. The message receiving and fragment identification module is used to receive management control interface protocol message streams and identify fragmented messages in the management control interface protocol messages. It should be noted that the method for identifying fragmented messages in the management control interface protocol message is as follows: The header of the management control interface protocol message is parsed to extract key fields. These key fields include the management entity identifier (ME_ID), instance number (Instance_ID), message type (Message_Type, such as Create / Set / Delete), attribute mask (Attribute_Mask, 2 bytes, identifying which attributes this message carries), and optional sequence number (Sequence_Number, an extended field for some vendors, used to identify the fragment order). If the attribute mask does not include any preset mandatory attributes, the management control interface protocol message is determined to be a fragmented message, and a fragment descriptor is generated. The fragment descriptor includes the management entity identifier, instance number, message type, attribute mask, message payload, and receiving timestamp. The fragment descriptor is sent to the fragment assembly and integrity verification module. If all preset mandatory attributes are included, it is determined to be a complete message (this could be a single message completing the configuration, or a fragmented message just happens to have all the mandatory attributes), and the complete message is directly sent to the dependency resolution module.

[0025] In one specific embodiment, required attributes are stored in a dependency rule base. For example, for a PPPoE WAN connection entity, its required attributes include account, password, and VLAN ID.

[0026] The fragment assembly and integrity verification module is used to assemble fragmented messages belonging to the same ME instance to obtain a complete ME instance and send it to the dependency resolution module. The flowchart of fragment assembly and integrity verification is as follows. Figure 2 As shown; It should be noted that the specific process of assembling fragmented messages belonging to the same ME instance is as follows: A fragment cache table is created in the ONU memory, with each cache record corresponding to an assembled ME instance. The cache record includes a management entity identifier, instance number, received attribute mask (recording all received attributes, accumulated by bitwise OR), attribute value array (storing received values ​​by attribute index), and fragment counter (recording the number of fragments received). When a fragment descriptor is received, the fragment cache table is checked to see if a cache record with the same management entity identifier and instance number exists. If it exists, the received attribute mask of that record is updated (by bitwise ORing the new fragment's mask with the original mask), and the attribute values ​​carried by the new fragment message are stored in the attribute value array. At the same time, the fragment counter is incremented by 1. When the received attribute mask of the cache record includes the preset required attributes, the complete ME instance is output, the corresponding cache record is deleted, and the complete ME instance is sent to the dependency resolution module.

[0027] The cache record also includes a timeout timer (which records the time when the instance first receives the fragment for timeout detection). When there is no identical management entity identifier and instance number, a new cache record needs to be created. The timeout timer is started and a preset time threshold is set. When the timeout timer reaches the preset time threshold, if the received attribute mask of the cache record does not include the preset required attributes, the cache record is marked as a missing record, and a missing report is generated, which includes ME_ID, Instance_ID, the difference between the received attribute mask and the required attribute mask (i.e., the list of missing attributes). This report is then sent to the accurate status report module, and finally the cache record is cleared.

[0028] The dependency resolution module is used to resolve the dependencies between the complete ME instance and other ME instances to obtain the set of prerequisite dependencies; The process of obtaining the prerequisite dependency set is as follows: based on the complete ME instance, traverse the dependency rule base to obtain the dependency rule that matches the ME type of the complete ME instance; check whether there is a ME instance that satisfies the dependency rule in the ME instance in the management information base or the ME instance to be created in the transaction manager (by querying the list of active transactions in the transaction manager); if it does not exist, add the dependency rule to the prerequisite dependency set; if it exists, keep the prerequisite dependency set as an empty set, and send the ME instance and its prerequisite dependency set (which may be empty) together into the asynchronous parallel scheduling module.

[0029] In one specific embodiment, the dependency rule base is a pre-installed rule table in the system, defining the dependency relationships between various management entities in the management control interface protocol. The rule table contains the following fields: current ME type, dependent ME type, dependency type (e.g., "create dependency", "reference dependency", "delete dependency"), and dependency condition description. For example: (1) Create dependency: The PPPoE WAN connection (0x0102) must depend on an existing service profile (0x0007), that is, the "ServiceID" field in the WAN connection configuration must point to an existing service profile instance; (2) Reference dependency: The IP host configuration (0x000F) must reference an existing service profile; (3) Delete dependencies: Before deleting a parent entity (such as a service profile), you must first delete all its child entities (such as WAN connections). The asynchronous parallel scheduling module is used to schedule complete ME instances to the worker thread pool for execution based on the prerequisite dependency set. The specific process is as follows: ME instances with non-empty prerequisite dependency sets are stored in the waiting queue, and ME instances with empty prerequisite dependency sets are stored in the ready queue. The scheduler monitors the ME instances in the waiting queue. When a new ME instance is completed, all ME instances in the waiting queue are checked. If all dependencies in the prerequisite dependency set of the ME instance have been successfully processed (i.e., the dependent ME instances already exist in the MIB), the ME instance is transferred from the waiting queue to the ready queue. The scheduler monitors the idle threads in the ready queue and the thread pool at the same time. When the ready queue is not empty and there are idle threads, the scheduler takes a ME instance from the ready queue and assigns it to an idle thread. The idle thread calls the management control interface protocol proxy module to perform configuration operations (such as creation, modification, and deletion). Multiple complete ME instances without dependencies can be assigned to multiple threads for parallel processing at the same time, improving configuration efficiency.

[0030] The flexible transaction management module defines the creation or modification of each ME instance as a logical transaction and adopts different handling strategies based on error types. These error types include critical errors and non-critical errors. Critical errors are those that prevent the ME instance from functioning correctly, such as memory allocation failure, insufficient hardware resources, invalid required attribute values, and failure to create dependent entities; these are handled using a rollback strategy. Non-critical errors are those that do not affect the core functionality of the ME instance, such as optional attribute configuration failure (e.g., description field), attribute values ​​exceeding the range but which can be replaced with default values, and failure to configure non-core auxiliary functions; these are handled using a flexible skip strategy. The rollback strategy is as follows: when an operation within a transaction fails due to a critical error, the transaction manager aborts the transaction and reads the transaction's operation log in reverse order, generating a reverse operation message for each successfully executed operation, for example: ① If a Create operation has already been performed, then a Delete operation will be generated (deleting the newly created instance); ② If a Set operation has already been performed, then generating a Set operation will revert the property to its original value (the original value must be recorded in the operation log); ③ If a Delete operation has already been performed, it is usually impossible to roll back. Therefore, the design should avoid including Delete operations in transactions, or handle Delete operations separately. The reverse operation message is sent to the asynchronous parallel scheduling module, where the scheduler allocates threads for execution, ultimately rolling back the ONU's MIB state to the consistent state before the transaction began.

[0031] The specific content of the flexible skip strategy is as follows: when an operation within a transaction fails due to a non-critical error, the transaction manager does not abort the entire transaction, but records the error log and marks the corresponding attribute of the ME instance in the MIB (for example, marked as "configuration failed, use default value"), and updates the status of the transaction to partially successful; the transaction continues to execute other operations, and when the transaction is finally completed, a partially successful result report is generated, which includes a list of successful operations and detailed information on failed operations, and is sent to the precise status reporting module.

[0032] In one specific embodiment, a transaction corresponds to the configuration process of a complete ME instance, which may consist of multiple fragmented messages. The transaction manager maintains a state machine for each transaction and records the operation log within the transaction (i.e., the sub-operations that have been successfully executed). A schematic diagram of the state machine is shown below. Figure 3 As shown.

[0033] The precise status reporting module is responsible for returning fine-grained processing result reports to the OLT to assist the OLT in making accurate decisions. The final processing result report includes: (1) Transaction identifier (consisting of ME_ID and Instance_ID, or a unique transaction ID generated by the system); (2) Final status: Success / Partial success / Failure-Rollback / Failure-Timeout; (3) Successful operation list: Lists the attributes that have been successfully configured and their corresponding values; (4) List of failed operations: For each failed operation, record the operation type, reason for failure, and handling method (e.g., "skipped, use default value" or "rolled back"). (5) Missing information list: When the failure occurs due to fragment timeout, report the specific list of missing attributes (e.g., "Missing core attribute: VLAN ID"). The timing for reporting is: (1) When a transaction is finally completed (successful, partially successful, or rolled back), immediately assemble a report and submit it to the OLT; (2) When the fragment assembly times out, a missing information report is immediately submitted without waiting for the transaction to be created.

[0034] The overall structure diagram of the system is as follows: Figure 4 The data flow of the entire system is described below: 1OLT sends fragment messages → Module 1 identifies fragments → Module 2 caches and verifies integrity; 2. Once the ME instance is complete, Module 3 resolves dependencies; 3. ME instances whose dependencies are satisfied → Module 4 scheduled for execution; 4. The execution result is fed back to the transaction manager in module 5; 5. Transaction Manager makes decisions based on error type → Rollback instruction returns to module 4 6. Final Status Report → Report to OLT via the management control interface protocol channel.

[0035] This system has the following beneficial effects: Completely avoid protocol payload defects: Through "fragment assembly and integrity verification", ensure that the ONU will never create or modify the ME instance based on incomplete configuration information, fundamentally eliminating business function abnormalities caused by configuration fragmentation and improving the stability of ONU operation; Significantly improved configuration success rate: By employing a "flexible skip strategy," the configuration success rate is improved from an "all or nothing" approach to a "priority success for core, essential configuration parts." For example, when configuring a PPPoE WAN connection, even if the optional description field fails to configure, the core account password will still take effect, and the PPPoE dial-up service can be used normally, avoiding unnecessary process rollbacks and retries. Enhanced compatibility and robustness: This invention does not rely on the OLT's order of sending fragmented messages. Even if fragmented messages arrive out of order, or a non-core fragmented message is lost, the ONU can detect missing information through integrity verification and report the specific missing item to the OLT after a timeout, assisting the OLT in accurate resending, rather than simply blocking the process; Improved operational efficiency: Accurate status reports enable the OLT to quickly locate problems, reduce manual troubleshooting time, and improve network deployment and maintenance efficiency.

[0036] Example 3 This embodiment provides fragmented configuration and flexible processing for PPPoE WAN connections, as detailed below: This embodiment describes the process by which the OLT issues a WAN connection configuration with an IP address obtained via PPPoE. This configuration includes core mandatory attributes (PPPoE username, PPPoE password, VLAN ID) and non-core optional attributes (WAN connection name, IP version, MTU value). Due to the protocol payload limitations of the management control interface, the OLT splits the configuration into five messages: M1 (username), M2 (password), M3 (VLAN ID), M4 (name), and M5 (MTU). The order in which the OLT issues these messages may be M1, M2, M4, M3, M5 (out of order).

[0037] 1. Fragment identification and assembly: (1) The ONU message receiving and fragment identification module receives M1, M2 and M4 in sequence. The module parses them and finds that they all belong to the same WAN connection ME instance (assuming ME_ID=0x0102, Instance_ID=0x0001). Based on the attribute mask, it determines that they are all fragment messages and generates fragment descriptors to send to the fragment assembly module; (2) The fragment assembly module searches for (0x0102, 0x0001) in the cache table but does not find it. Therefore, it creates a new cache record and stores the data of M1, M2, and M4 in sequence. At this time, the received attribute mask is account, password, and name (VLAN ID and MTU are missing). (3) Upon receiving M3 (VLAN ID), the module updates the cached record, and the received attribute mask becomes one that includes the username, password, and VLAN ID. The module checks the required attribute set (username, password, VLAN ID) and finds that it is satisfied, determining that the ME instance is "complete". Therefore, the cached record is removed, and a complete ME instance object (containing username, password, and VLAN ID, but not yet name and MTU) is generated and sent to the dependency resolution module. M4 (name) and M5 (MTU) remain in the cache (as optional attributes, to be cached for further processing). (4) When M5 (MTU) is received later, the module updates the cache. At this time, all the optional attributes (name and MTU) have been collected, but the core has been satisfied. Therefore, the arrival of M5 will not trigger a new full event, but only update the cache. 2. Dependency resolution and scheduling: (1) After receiving the complete ME instance (including core attributes), the dependency resolution module queries the dependency rule base and finds that the WAN connection needs to reference an existing service profile (assuming ServiceID=10). Checking the ONU's MIB, it finds that service profile instance 10 already exists, therefore the prerequisite dependency set is empty; (2) The scheduling module adds the complete ME instance to the ready queue and assigns it to idle thread A for execution. Thread A calls the management control interface protocol proxy to create a WAN connection instance, configure the account, password and VLAN ID, and the operation is successful; 3. Flexible transaction management: (1) The transaction manager defines "Create WAN connection instance 0x0001" as a transaction T1. The current status of T1 is "success" (core properties are configured); (2) Subsequently, M4 (name) and M5 (MTU) in the cache will be processed as "update" operations since the ME instance has been created. The scheduling module will assign threads B and C to them for parallel execution. (3) Thread B successfully executed the name setting; (4) Thread C attempts to set the MTU, but the MTU value issued by the OLT is 9000, which exceeds the range supported by the ONU hardware (maximum 1500). The management control interface protocol agent returns "parameter error"; (5) Upon receiving this error, the transaction manager queries the error classification table and determines that the MTU configuration failure is a "non-critical error" (because PPPoE dialing can still proceed even if the MTU uses the default value of 1500). Therefore, a flexible skip strategy is executed: the error log is recorded as "Instance 0x0001 MTU value 9000 is invalid, default value 1500 has been used", the attribute is marked as "default value" in the MIB, and the status of transaction T1 is updated to "partial success"; (6) When transaction T1 is finally completed, the accurate status report module generates a report, which includes a list of successful operations (account, password, VLAN ID, name) and details of failed operations (MTU configuration failure and handling method), and reports it to the OLT through the management control interface protocol channel.

[0038] The message processing sequence diagram of this embodiment is as follows: Figure 5 As shown.

[0039] Example 4 This example provides a scenario where fragment assembly timeout occurs due to the loss of core attributes, as detailed below: 1. Message reception: The ONU only receives M1 (username), M2 (password), and M4 (name), but M3 (VLAN ID) is lost due to network issues; 2. Fragment Assembly: The fragment assembly module creates a new cache record at (0x0102, 0x0001) and stores it sequentially into M1, M2, and M4. The received attribute mask contains the username, password, and name, but lacks the VLAN ID; 3. Timeout Detection: The 30-second timer started by the transaction manager for this cached record expires. The module checks and finds that the required attribute (VLAN ID) has not been received. It is determined that the transaction cannot be completed due to the missing core attribute. 4. Status Report: The module triggers timeout processing and generates a missing report with the content: "Transaction T1 failed, reason: missing core attribute VLAN ID (corresponding message M3)". This report is immediately reported to the OLT through the accurate status reporting module, and the cache record is cleared at the same time. At this time, the ONU has not created any WAN connection, and the MIB status remains unchanged; 5. OLT Response: After receiving the report, the OLT does not need to retransmit all messages; it only needs to retransmit M3 (VLAN ID). Upon receiving M3, the ONU combines it with the previously cached M1, M2, and M4 (Note: the cache has been cleared and needs to be re-received. In actual implementation, it can be designed so that when the OLT retransmits, the ONU can restart the assembly process, or retain some cache until the retransmission is received. For simplicity, this example assumes the ONU restarts when the OLT retransmits, but with an accurate report, the OLT can send only M3, and then the ONU combines it with the previously received information (if the cache has been cleared, the OLT needs to retransmit everything, but after an accurate report, the OLT usually retransmits everything or retransmits as needed; this embodiment emphasizes the value of accurate reports). In practice, the cache can be retained for a period of time after a timeout to await resending, or the OLT can be designed to resend only the missing attributes based on the report, and the ONU can complete the assembly by combining the cached data after receiving the resend. However, to highlight the accuracy of the report, this embodiment describes the configuration as successfully completing after the OLT resends the missing message.

[0040] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. Those skilled in the art can make other variations or modifications based on the above description. It is neither necessary nor possible to exhaustively describe all embodiments here. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A method for processing management control interface protocol messages, characterized in that, Includes the following steps: S1: Identify fragmented messages and complete messages in the management control interface protocol message stream, wherein the fragmented messages and complete messages are configuration messages of multiple different management entity instances; S2: Assemble fragmented messages belonging to the same management entity instance to obtain a complete management entity instance; S3: Analyze the dependencies between the complete management entity instance and other management entity instances to obtain the set of prerequisite dependencies; S4: Based on the aforementioned set of prerequisite dependencies, schedule the complete management entity instance to the worker thread pool for execution.

2. The management control interface protocol message processing method according to claim 1, characterized in that, The method for identifying fragmented messages and complete messages in step S1 is as follows: parse the header of the management control interface protocol message and extract key fields. The key fields include management entity identifier, instance number, message type, and attribute mask. If the attribute mask includes preset required attributes, then the management control interface protocol message is determined to be a complete message. If the attribute mask does not include any preset required attributes, the management control interface protocol message is determined to be a fragment message, and a fragment descriptor is generated. The fragment descriptor includes the management entity identifier, instance number, message type, attribute mask, message payload, and receiving timestamp.

3. The management control interface protocol message processing method according to claim 2, characterized in that, The specific content of assembling fragmented messages belonging to the same management entity instance in step S2 is as follows: a fragment cache table is opened in the optical network unit memory, and each cache record corresponds to an assembled management entity instance. The cache record includes a management entity identifier, instance number, received attribute mask, attribute value array, and fragment counter. When a fragment descriptor is received, the system checks the fragment cache table to see if a cached record with the same management entity identifier and instance number exists. If it does, the system updates the received attribute mask of the record and stores the attribute values ​​carried by the new fragment message into the attribute value array, while incrementing the fragment counter by 1. When the received attribute mask of the cached record includes the preset required attributes, the system outputs the complete management entity instance and deletes the corresponding cached record.

4. The management control interface protocol message processing method according to claim 3, characterized in that, The cache record also includes a timeout timer. When there is no identical management entity identifier and instance number, a new cache record needs to be created. The timeout timer is started and a preset time threshold is set. When the timeout timer reaches the preset time threshold, if the received attribute mask of the cache record does not include the preset required attributes, the cache record is marked as a missing record and a missing report is generated.

5. The management control interface protocol message processing method according to claim 2, characterized in that, The process of obtaining the prerequisite dependency set in step S3 is as follows: based on the complete management entity instance, traverse the dependency rule base to obtain the dependency rule that matches the complete management entity instance; check whether there is a management entity instance that satisfies the dependency rule in the management entity instance in the management information base or the management entity instance to be created in the transaction manager; if not, add the dependency rule to the prerequisite dependency set; if it exists, keep the prerequisite dependency set as an empty set.

6. A management control interface protocol message processing method according to claim 1 or 5, characterized in that, The specific process of step S4 is as follows: store the management entity instances with non-empty prerequisite dependency sets in the waiting queue, and store the management entity instances with empty prerequisite dependency sets in the ready queue. The scheduler monitors the management entity instances in the waiting queue. When a new management entity instance finishes processing, it checks all management entity instances in the waiting queue. If all dependencies in the prerequisite dependency set of the management entity instance have been successfully processed, the management entity instance is transferred from the waiting queue to the ready queue. The scheduler also monitors the idle threads in the ready queue and the thread pool. When the ready queue is not empty and there are idle threads, the scheduler retrieves a management entity instance from the ready queue and assigns it to an idle thread. The idle thread then calls the management control interface protocol proxy module to perform configuration operations.

7. The management control interface protocol message processing method according to claim 6, characterized in that, The creation or modification of each management entity instance is defined as a logical transaction, and different handling strategies are adopted according to the error type, which includes critical errors and non-critical errors. Critical errors are those that cause the management entity instance to malfunction, and a rollback strategy is adopted. Non-critical errors are those that do not affect the normal operation of the management entity instance, and a flexible skip strategy is adopted.

8. The management control interface protocol message processing method according to claim 7, characterized in that, The rollback strategy is as follows: when an operation within a transaction fails due to a critical error, the transaction manager aborts the transaction and reads the transaction's operation log in reverse order, generating a reverse operation message for each successfully executed operation. The scheduler then allocates threads for execution based on the reverse operation message.

9. A management control interface protocol message processing method according to claim 7, characterized in that, The specific content of the flexible skip strategy is as follows: when an operation within a transaction fails due to a non-critical error, the transaction manager does not terminate the entire transaction, but records the error log, marks the corresponding attribute of the management entity instance in the management information base, and updates the status of the transaction to partially successful. The transaction continues to perform other operations. When the transaction is finally completed, a partially successful result report is generated, which includes a list of successful operations and information on failed operations.

10. A management control interface protocol message processing system, characterized in that, The system includes a message receiving and fragment identification module, a fragment assembly and integrity verification module, a dependency resolution module, an asynchronous parallel scheduling module, a flexible transaction management module, and a precise status reporting module. The message receiving and fragment identification module receives management control interface protocol message streams and identifies fragmented and complete messages within them. It then sends fragmented messages to the fragment assembly and integrity verification module. This module assembles fragmented messages belonging to the same management entity instance to obtain a complete management entity instance, which is then sent to the dependency resolution module. The dependency resolution module resolves the dependencies between the complete management entity instance and other management entity instances, obtaining a set of prerequisite dependencies. The asynchronous parallel scheduling module schedules the complete management entity instance to a worker thread pool for execution based on the set of prerequisite dependencies. The flexible transaction management module is used to define the creation or modification of each management entity instance as a logical transaction and to adopt different processing strategies according to the error type. The precise status report module is used to generate a final processing result report and report it to the optical line terminal.

Images