Business protection method and apparatus, and distributed multi-chip device

Abstract

This application provides a service protection method, apparatus, and distributed multi-chip device, relating to the field of communications. The method includes: obtaining fault report information corresponding to each OAM session on the local line card through detection, and issuing fault information notifications based on configuration information and fault report information; processing the APS state machine corresponding to each first target APS protection group based on the fault report information of each OAM session corresponding to each first APS protection group obtained by the local line card, obtaining an updated protection state table, wherein the first APS protection group is the APS protection group that requires APS state machine processing by the local line card; and sending APS synchronization messages to other line cards based on the updated protection state table, and updating the APS entries. Thus, through the provided synchronization mechanism of full-frame OAM fault notification and protection group information in the distributed multi-chip device, the link monitoring and switching of the distributed multi-chip device can achieve multi-line card state synchronization.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a service protection method, apparatus, and distributed multi-chip device. Background Technology

[0002] In existing application networks, carrier-grade switches require complete fault detection and protection switching with a switching time of 50ms. Distributed multi-chip devices (such as distributed switches) must also meet this requirement. Therefore, how to effectively synchronize information and switching between line cards is a topic that needs optimization. Summary of the Invention

[0003] This application provides a service protection method, apparatus, distributed multi-chip device, and readable storage medium. It enables multi-line card status synchronization for link monitoring and switching of the distributed multi-chip device through a synchronization mechanism of full-frame OAM fault notification and protection group information.

[0004] The embodiments of this application can be implemented as follows:

[0005] In a first aspect, embodiments of this application provide a service protection method applied to line cards in a distributed multi-chip device, the method comprising:

[0006] The fault report information corresponding to each OAM session on this line card is obtained by detection, and the fault information is notified according to the configuration information and the fault report information. The configuration information is used to indicate the fault information notification object.

[0007] Based on the fault report information of each OAM session corresponding to each first APS protection group obtained by this line card, the APS state machine corresponding to each first target APS protection group is processed to obtain the updated protection state table. Among them, the first APS protection group is the APS protection group that needs to be processed by this line card for APS state machine.

[0008] According to the updated protection status table, APS synchronization messages are sent to other line cards and APS entries are updated. The APS synchronization messages are used to indicate the switching status of each first APS protection group determined by this line card.

[0009] Secondly, embodiments of this application provide a service protection device applied to line cards in a distributed switch. The device includes an OAM processing engine and a fault handling engine.

[0010] The OAM processing engine is used to obtain fault report information corresponding to each OAM session on the local line card by detection, and to issue fault information notifications according to the configuration information and the fault report information, wherein the configuration information is used to indicate the fault information notification object;

[0011] The fault handling engine is used to process the APS state machine corresponding to each first target APS protection group based on the fault report information of each OAM session corresponding to each first APS protection group obtained by this line card, and obtain an updated protection state table. The first APS protection group is the APS protection group that needs to be processed by the fault handling engine of this line card for APS state machine processing.

[0012] The fault handling engine is also used to send APS synchronization messages to other line cards according to the updated protection status table, and to update the APS entries. The APS synchronization messages are used to indicate the switching status of each first APS protection group determined by this line card.

[0013] Thirdly, embodiments of this application provide a distributed multi-chip device, the device including multiple line cards, each line card including a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the service protection method described in the foregoing embodiments.

[0014] Fourthly, embodiments of this application provide a readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the service protection method as described in the foregoing embodiments.

[0015] The service protection method, apparatus, distributed multi-chip device, and readable storage medium provided in this application embodiment detect and obtain fault message information corresponding to each OAM session on the local line card, and perform fault information notification based on configuration information indicating the fault information notification object and the fault message information corresponding to each OAM session obtained through detection; and, based on the fault report information of each OAM session corresponding to each first APS protection group obtained by the local line card, process the APS state machine corresponding to each first target APS protection group to obtain an updated protection state table, and then send APS synchronization messages to other line cards according to the updated protection state table, and update the APS entries. The first APS protection group is the APS protection group that requires APS state machine processing by the local line card, and the APS synchronization message is used to indicate the switching status of each first APS protection group determined by the local line card. Thus, through a synchronization mechanism for full-frame OAM fault notification and protection group information of a distributed multi-chip device, the link monitoring and switching of the distributed multi-chip device can be synchronized across multiple line cards. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A block diagram illustrating a distributed multi-chip device provided in an embodiment of this application;

[0018] Figure 2 A flowchart illustrating the business protection method provided in this application embodiment;

[0019] Figure 3 for Figure 2 A flowchart illustrating the sub-steps included in step S110;

[0020] Figure 4 A schematic diagram illustrating the format of the OAM fault notification message provided in this application embodiment;

[0021] Figure 5 for Figure 2 One of the flowcharts illustrating the sub-steps included in step S120;

[0022] Figure 6 for Figure 2 The second flowchart of the sub-steps included in step S120;

[0023] Figure 7 A schematic diagram of the format of the APS synchronization message provided in the embodiments of this application;

[0024] Figure 8 A schematic diagram illustrating the execution of the service protection method provided in this application embodiment;

[0025] Figure 9 A block diagram illustrating the service protection device provided in the embodiments of this application;

[0026] Figure 10 for Figure 9 A block diagram of the OAM processing engine;

[0027] Figure 11 for Figure 9 A block diagram of the fault handling engine.

[0028] Icons: 100 - Distributed multi-chip device; 110 - Memory; 120 - Processor; 130 - Communication unit; 200 - Service protection device; 210 - OAM processing engine; 211 - Fault scanner; 212 - Announcement message generation module; 220 - Fault handling engine; 221 - OAM fault handling module; 222 - APS state machine processing module; 223 - Entry update IO processing module; 224 - APS synchronization message generation module. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0030] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0031] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0032] In distributed multi-chip devices, protecting services and links from the overall architecture perspective to meet the overall protection requirements of the device is a crucial function. This application provides a service protection method, apparatus, and distributed multi-chip device that comprehensively considers and performs functions including fault detection, protection switching, multi-line card information synchronization, and upper-layer system information processing, thereby achieving the overall protection function of the device.

[0033] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0034] Please refer to Figure 1 , Figure 1 This is a block diagram illustrating a distributed multi-chip device 100 provided in an embodiment of this application. The distributed multi-chip device 100 may be, but is not limited to, a distributed switch. The distributed multi-chip device 100 may include a switching card and multiple line cards, with the switching card used for forwarding messages between line cards. Each line card may include a memory 110, a processor 120, and a communication unit 130. The memory 110, processor 120, and communication unit 130 are electrically connected directly or indirectly to each other to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0035] The memory 110 is used to store programs or data. The memory 110 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0036] The processor 120 is used to read / write data or programs stored in the memory 110 and execute corresponding functions. For example, the memory 110 stores a service protection device 200, which includes at least one software function module that can be stored in the memory 110 in the form of software or firmware. The processor 120 executes various functional applications and data processing by running the software programs and modules stored in the memory 110, such as the service protection device 200 in this embodiment, thereby implementing the service protection method in this embodiment.

[0037] The communication unit 130 can be used to establish a communication connection between the distributed multi-chip device 100 and other communication terminals through the network, and to send and receive data through the network.

[0038] It should be understood that, Figure 1The structure shown is only a schematic diagram of the distributed multi-chip device 100. The distributed multi-chip device 100 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown. Figure 1 The components shown can be implemented using hardware, software, or a combination thereof.

[0039] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating a service protection method provided in an embodiment of this application. The method can be applied to various line cards in a distributed multi-chip device. The specific flow of the service protection method is described in detail below. In this embodiment, the service protection method may include steps S110 to S130.

[0040] Step S110: Obtain fault report information corresponding to each OAM session on this line card by detection, and issue fault information notification based on configuration information and the fault report information.

[0041] In this embodiment, the OAM (Operation, Administration and Maintenance) session is used to monitor the link status. Fault report information corresponding to each OAM session on this line card can be obtained through detection; the specific detection method can be set according to actual needs. The fault report information corresponding to an OAM session describes whether the monitored link has a fault, etc. After obtaining the fault report information corresponding to each OAM session on this line card, the fault information notification target can be determined based on pre-set configuration information, and then, in conjunction with the obtained fault report information corresponding to each OAM session on this line card, fault information notification can be performed.

[0042] The specific targets for fault information notification can be set according to actual needs. For example, it could be a different line card, all other line cards, or other functional modules on this line card. When issuing fault information notifications, fault report information corresponding to each OAM session on this line card can be directly used as the notification information. Alternatively, fault report information indicating a fault can be selected from the fault report information corresponding to each OAM session on this line card, or other methods can be used to notify fault information based on the fault report information corresponding to each OAM session on this line card. Furthermore, the fault information notified to different fault information notification targets can be the same or different, depending on actual needs. As one possible implementation, the fault report information corresponding to each OAM session on this line card can be used as the content of the notification for each fault information notification target.

[0043] Optionally, fault report information corresponding to each OAM session can be obtained periodically through detection, and fault information can be announced periodically based on configuration information and the fault report information.

[0044] Step S120: Based on the fault report information of each OAM session corresponding to each first APS protection group obtained by this line card, process the APS state machine corresponding to each first target APS protection group to obtain the updated protection state table.

[0045] In this embodiment, the first APS (Automatic Protection Switched) protection group is the APS protection group that requires APS state machine processing by this line card. The specific configuration can be tailored to actual needs. For example, if a protection link is on a line card, then that line card needs to process the APS state machine corresponding to the APS protection group for that protection link. One APS protection group includes a protection link and a working link.

[0046] In this embodiment, the fault report information of each OAM session corresponding to each first APS protection group can be obtained from the fault report information of each OAM session on this line card obtained by detection on this line card, and / or from the fault information reported by other line cards.

[0047] For each first APS protection group, the APS state machine corresponding to that first APS protection group can be processed based on the fault report information from the two OAM sessions corresponding to that first APS protection group to obtain the APS state machine result. Specifically, in the two OAM sessions corresponding to one APS protection, one OAM session is used to monitor the working links in that APS protection group, and the other OAM session is used to monitor the protection links in that APS protection group. The APS state machine results corresponding to each first APS protection group can be stored in the protection state table, thus obtaining an updated protection state table.

[0048] Optionally, obtaining fault report information and APS state machine processing for each OAM session corresponding to each first APS protection group can be performed periodically.

[0049] Step S130: Based on the updated protection status table, send APS synchronization messages to other line cards and update the APS entries.

[0050] With the updated protection status table obtained, the switching status of each first APS protection group can be determined based on the updated protection status table. Then, an APS synchronization message is sent to other line cards of the distributed multi-chip device. This APS synchronization message is used to indicate the switching status of each first APS protection group determined by this line card. APS entries can also be updated on this line card to complete the path switching for chip forwarding. It is understood that if the updated protection status table determines that no path switching is needed, the APS entries remain unchanged before and after the update; if the updated protection status table determines that a path switching is needed, the APS entries will differ before and after the update.

[0051] Thus, through a synchronization mechanism for full-frame OAM fault notification and protection group information of distributed multi-chip devices, the link monitoring and switching of distributed multi-chip devices can be synchronized across multiple line cards.

[0052] Optionally, it can be achieved through Figure 3 This method retrieves fault report information corresponding to each OAM session on this line card. Please refer to... Figure 3 , Figure 3 for Figure 2 A flowchart illustrating the sub-steps included in step S110. In this embodiment, step S110 may include sub-steps S111 to S112.

[0053] Sub-step S111: Perform a fault scan on each OAM session on this line card to obtain the status information of each OAM session.

[0054] Sub-step S112: Generate an OAM fault notification message based on the status information of each OAM session on this line card.

[0055] Optionally, in this embodiment, a fault scan can be performed on each OAM on the line card, and the status information of the OAM session can be obtained based on the scan results. The status information of an OAM session may include faults caused by OAM message processing in the receiving direction, or periodically generated dLoc (Loss of continuity), etc. That is, the fault may be caused by OAM message processing in the receiving direction, or a periodically generated dLoc, etc.

[0056] Based on the status information of each OAM session on this line card, an OAM fault notification message can be generated. This OAM fault notification message includes fault report information for each OAM session on this line card. The fault report information may include the fault type OAM session identifier, the link type of the link monitored by the OAM session (e.g., working link or protection link), and the APS protection group identifier corresponding to the link monitored by the OAM session, etc.

[0057] Optionally, for each OAM session's status information, it can be determined whether the OAM session corresponds to a fault. If it corresponds to a fault, the specific fault type can be determined based on the OAM session's status information; if it does not correspond to a fault, then no fault can be taken as the fault type corresponding to the OAM session.

[0058] The aforementioned OAM fault notification message can be directly sent to the fault information notification object indicated by the configuration information to synchronize link detection status. The aforementioned configuration information can specify the fault information notification object by configuring the egress point.

[0059] As one possible implementation, the format of the OAM Fault Report Message (OFRM) can be as follows: Figure 4 As shown.

[0060] Figure 4 The IH header in the code represents the internal processing information header of the chip. Line cards and switching cards can forward messages based on this header information. In this embodiment, the IH needs to include egress information, which is used to specify the target to be sent when generating the OAM fault notification message, such as sending it to the port corresponding to the line card where the corresponding fault handling engine is located.

[0061] Pseudo L2 is a pseudo Ethernet Layer 2 header, including MACDA, MACSA, and EtherType. EtherType is a special value used to indicate that the subsequent message content uses a proprietary message format specified in this application. The purpose of using this Pseudo L2 header is to facilitate message parsing using a common method. Alternatively, this Pseudo L2 header can be omitted, and the IH header can be used to indicate that the subsequent message data uses a proprietary message format.

[0062] The CommonInfo field is used to specify the type of subsequent messages. In this application, OAM fault notification messages and protection synchronization messages (i.e., APS synchronization messages) use the same CommonInfo format, and the subsequent data content format is distinguished by the Type field in CommonInfo.

[0063] Type 1: OAM fault notification message; Type 2: APS synchronization message.

[0064] UnitLen: This is the unit length of each subsequent data entry, in 4-byte units. It is set to 2 for OAM fault notification messages and 5 for protection synchronization messages.

[0065] EntryNum: Indicates the number of data units. It can be used in conjunction with UnitLen for subsequent data parsing.

[0066] OFRD1…ORFDn: OAM Fault Report Data, containing information for each OAM fault report.

[0067] P:0 indicates that the OAM session is monitoring a working link, and 1 indicates that the OAM session is monitoring a protection link.

[0068] FaultType: Fault type.

[0069] SessionId: OAM session ID.

[0070] ApsGroupId: The APS protection group ID to which the link monitored by this OAM session belongs.

[0071] The OFRM above contains the necessary information for OAM session failures and can be sent to the corresponding failure handling engine for processing.

[0072] Optionally, as a possible implementation, the line card may include an OAM processing engine, where the acquisition of fault message information and fault information notification can both be handled by the OAM processing engine. The OAM processing engine is used for sending and detecting OAM messages. In this embodiment, a fault scanning timer and a notification message generation module are added to the original OAM processing engine's functionality. When the OAM processing engine generates a corresponding fault, the fault scanning timer periodically (10ms / 100ms or other cycles) scans the OAM session status to obtain the status information of each OAM session and sends it to the notification message generation module. The notification message generation module can periodically... Figure 4 The OAM fault notification message is generated in the specified format and sent to the corresponding object.

[0073] Optionally, it can be achieved through Figure 5 The updated protection status table is obtained as shown. Please refer to [the provided text]. Figure 5 , Figure 5 for Figure 2 One of the flowcharts for the sub-steps included in step S120. In this embodiment, step S120 may include sub-steps S121 and S126.

[0074] Sub-step S121: Parse the obtained OAM fault notification message to obtain fault report information for each OAM session.

[0075] In this embodiment, the OAM fault notification messages obtained by this line card may include: OAM fault notification messages generated by this line card through fault scanning of each OAM session on this line card, and / or OAM fault notification messages sent by other line cards. The obtained OAM fault notification messages can be parsed to obtain fault report information for each OAM session. The fault report information for an OAM session includes the fault type, OAM session identifier, link type of the link monitored by the OAM session, and APS protection group identifier corresponding to the link monitored by the OAM session.

[0076] Sub-step S126: Based on the fault report information of each OAM session, determine the fault report information of the two OAM sessions corresponding to each first APS protection group, and update the state of the APS state machine of the first APS protection group based on the fault report information of the two OAM sessions corresponding to each first APS protection group.

[0077] In this embodiment, the fault report information of the two OAM sessions corresponding to each first APS protection group can be determined based on the APS protection group identifier in the fault report information of each OAM session. Then, based on the fault report information of the two OAM sessions corresponding to a first APS protection group, the APS state machine corresponding to that APS protection group is processed to update the state of the APS state machine. Similarly, by processing the APS state machines corresponding to other first APS protection groups in the same way, the states of the other APS state machines can be obtained. The obtained states of the APS state machines of each first APS protection group can be saved to the protection state table.

[0078] This line card may include a second OAM session corresponding to a second APS protection group. The second APS protection group is an APS protection group that does not require APS state machine processing on this line card. When fault report information of the second OAM session is obtained in sub-step S121, no processing is required.

[0079] Optionally, one of the fault types is fault-free. As a possible approach, the state of the APS state machine corresponding to the first target APS protection group can be updated based on a fault-proofing mechanism. Please refer to... Figure 6 , Figure 6 for Figure 2 The second flowchart illustrates the sub-steps included in step S120. In this embodiment, between sub-step S121 and sub-step S126, step S120 may further include sub-steps S122 to S125.

[0080] Sub-step S122: Based on the first session identifier corresponding to each first APS protection group corresponding to this line card and the obtained OAM fault notification message, calculate the unreceived duration corresponding to each pending first session identifier.

[0081] Sub-step S123: For each unreceived duration, determine whether the unreceived duration is not less than a preset duration.

[0082] If the unreceived duration is not less than the preset duration, then sub-step S124 is executed.

[0083] Sub-step S124: Use the preset fault type as the fault type of the OAM session corresponding to the first session identifier to be processed, and generate fault report information for the OAM session.

[0084] If the unreceived time is less than the preset duration, then sub-step S124 is executed.

[0085] Sub-step S125: No fault is taken as the fault type of the OAM session corresponding to the first session identifier to be processed, and fault report information of the OAM session is generated.

[0086] In this embodiment, after parsing the obtained OAM fault notification, the line card can determine the OAM session identifier obtained in this parsing. The obtained OAM session identifier can be compared with the first session identifiers corresponding to each first APS protection group of the line card to determine the first session identifier to be processed. The first session identifier to be processed is the one that was not obtained from the OAM fault notification message in this instance. Next, the non-reception duration corresponding to each first session identifier to be processed can be calculated. The non-reception duration corresponding to a first session identifier to be processed represents the duration during which the first session identifier to be processed was not obtained from the OAM fault notification message.

[0087] For example, assuming that OAM fault notification messages are periodically processed, and assuming that a certain OAM session identifier corresponding to a certain first APS protection group cannot be parsed from the OAM fault notification messages for three consecutive times, the non-received duration corresponding to the OAM session identifier can be determined based on the period on which the OAM fault notification message parsing is based and the three times.

[0088] For a pending first session identifier, the duration of no reception is determined to be greater than a preset duration. If it is greater, the OAM session corresponding to the pending first session identifier is considered to be faulty. A preset fault type (which is not fault-free, but indicates a fault) can be used as the fault type of the OAM session corresponding to the pending first session identifier. Combined with the pending first session identifier, the APS protection group identifier of the first APS group corresponding to the pending first session identifier, and the link type, the fault report information of the OAM session corresponding to the pending first session identifier is generated.

[0089] If the duration of non-receipt is not greater than the preset duration, it can be considered that the OAM session corresponding to the first session identifier to be processed is without fault. In this case, the absence of fault can be taken as the fault type of the OAM session corresponding to the first session identifier to be processed. Combined with the first session identifier to be processed, the APS protection group identifier of the first APS group corresponding to the first session identifier to be processed, and the link type, the fault report information of the OAM session corresponding to the first session identifier to be processed is generated.

[0090] By determining how to handle the non-received duration for each pending first session identifier, the fault report information for the OAM session corresponding to each pending first session identifier can be obtained.

[0091] In this way, error prevention is achieved through a timeout check mechanism.

[0092] Then, the APS state machine can be processed based on the fault message information obtained by parsing the OAM fault message and the fault message information generated based on the error prevention mechanism.

[0093] Optionally, the state of the APS state machine of each first APS protection group can be updated based on the received APS protocol messages and the fault report information of the two OAM sessions corresponding to each first APS protection group. Furthermore, after updating the APS state machine, an APS protocol message can be sent to the peer device based on the updated state of the APS state machine.

[0094] After obtaining the updated protection status table, the switching status of each first APS protection group can be determined based on the updated protection status table. Then, an APS synchronization message is generated based on this and sent to other line cards so that other line cards can update the APS performance of this line card based on the APS synchronization message.

[0095] Specifically, the switching status of each first APS protection group can be stored as a bitmap in the APS synchronization message and sent to other line cards. Upon receiving the APS synchronization message, other line cards can perform chip switching status I / O operations for multiple protection groups simultaneously through a single I / O read / write operation. This avoids switching protection group status one by one, ensuring that the switching time is not proportional to the number of protection groups, thus reducing the overall switching time.

[0096] Optionally, to ensure correct IO read / write operations, the APS synchronization message includes at least one APS synchronization message. Each APS synchronization message includes the switching states of multiple first APS protection groups stored in a bitmap format, as well as the corresponding APS protection group reference value. The APS protection group reference value indicates the APS protection group reference identifier corresponding to an APS synchronization message. Thus, correct IO read / write operations can be performed based on the APS protection group reference value, preventing the switching state of one APS protection group from being mistakenly written to the switching state position of another APS protection group.

[0097] As one possible implementation, the format of the APS synchronization message (Protection Sync Message, PSM) can be as follows: Figure 7 As shown, APS synchronization messages are used to synchronize the APS protection group switching status of all line cards in a distributed multi-chip device.

[0098] in, Figure 7 The formats of IH, Pseudo L2, and CommonInfo are the same as those of OFRM, and will not be repeated here. In this case, Type is 2 and UintLen is 5.

[0099] PSMInfo1…PSMInfoN: Protect synchronization message information.

[0100] Aps Type: 1, Linear APS; 2, Ring Network APS.

[0101] SrcChipId: The line card chip ID that sent this APS synchronization message.

[0102] DstChipId: The line card chip ID that needs to receive this APS synchronization message.

[0103] APS GroupID Base (i.e.) Figure 7 APS Index Base: The APS GroupIdBase value on which this information is based.

[0104] APS Status Bitmap 0…3: Stores the switching status of each APS group starting from APS GroupId Base. It is in Bitmap format, with each bit representing the switching status of one APS protection group. 0 indicates operation on the working link, and 1 indicates operation on the protection link. Each message contains 128 bits, representing the switching status of 128 protection groups starting from APS GroupId Base. In other words, a single PSMInfoX message includes the switching status of 128 protection groups.

[0105] Upon receiving the APS synchronization message, the line card can obtain the status of each protection group based on the APS GroupId Base and the subsequent bitmap information. After collecting multiple PSM information entries, it can update the specific protection group status chip table entries and complete the path switching for chip forwarding.

[0106] It should be noted that the switching of chip protection switching groups is designed in bitmap form during chip design. This means that a single I / O read / write operation can simultaneously perform I / O operations for switching the chip status of multiple protection groups. This is compatible with the format of the APS synchronization message in this application. After mapping the chip protection group entry index according to the APS GroupId Base, the APS Status Bitmap content in the message can be directly used for I / O operations, allowing simultaneous switching of the chip status of 128 protection groups. Furthermore, the bitmap width design here can be expanded, considering 256 bits or other widths. This design can further reduce the switching time of chip protection group status.

[0107] Understandable, Figure 4 and Figure 7 The message format shown is only one design method. As long as it achieves the purpose of transmitting the necessary information, the message format can also be changed according to the specific chip design and software design.

[0108] Optionally, in this embodiment, after obtaining the updated state protection table, it is also possible to analyze whether each first APS state group needs to perform path switching. If so, table entry IO processing is performed to complete the path switching for chip forwarding.

[0109] Optionally, in this embodiment, the APS state machine processing corresponding to an APS protection group is performed on a line card. When the line card receives an APS synchronization message sent by another line card, it can update the APS entries according to the received APS synchronization message.

[0110] Optionally, as a possible implementation, the line card may include a fault handling engine, and the above-mentioned steps S120, S130, and the APS entry update of the line card may all be handled by the fault handling engine. In this embodiment, the fault handling engine may include an OAM fault handling module, an APS status processing module, an entry update IP processing module, and an APS synchronization message generation module, with each module performing corresponding processing periodically.

[0111] The following is combined Figure 8 The implementation of the above-mentioned service protection methods is illustrated with an example. In the following example, only one APS protection group is considered, where the two OAM sessions of this APS protection group are each on a separate line card. Figure 8 The protection link board in the diagram is the line card where the protection link and the corresponding OAM session reside. Figure 8 The working link card in the diagram refers to the line card where the working link and the corresponding OAM session reside. Both line cards include an OAM processing engine and a fault handling engine.

[0112] The OAM processing engine detects a fault, which could be caused by OAM message processing in the receiving direction or by periodically generated dLocs, thus triggering a fault log. The OAM processing engine includes a fault scanner and an announcement message generation module. The fault scanner periodically scans the logs to obtain and save the OAM session's status information. The announcement message generation module periodically generates a fault based on the saved OAM session status information and... Figure 4 The format shown generates OAM fault notification messages. These messages primarily include the OAM session ID and fault type. The OAM fault messages are forwarded to the fault handling engine via line cards and switch cards according to the configured final exit point. This OAM handling engine can be implemented using an FPGA or a built-in CPU, such as RISC-V.

[0113] Both the fault scanner and the notification message generation module in the protection link board and the working link board perform the above actions. Specifically, the notification message generation module in the protection link board can directly send the generated OAM fault notification message to the fault processing engine of this line card, or send it to the fault processing engine of this line card via the switch card. The notification message generation module in the working link board can send the generated OAM fault notification message to the fault processing engine in the protection link board via the switch card.

[0114] The fault handling engine includes an OAM fault handling module, an APS state machine processing module, an entry update IO processing module, and an APS synchronization message generation module. The OAM fault handling module periodically processes OAM fault notification messages, parsing out information such as the OAM session ID and fault type from the message before sending it to the APS state machine processing module. Simultaneously, this module incorporates a timeout check mechanism: if a message corresponding to the OAM session ID is not received within multiple time intervals (e.g., 10ms), the session is considered faulty, its fault type is determined, and corresponding fault information is generated and transmitted to the APS state machine processing module.

[0115] The APS state machine processing module performs APS state machine processing. Upon receiving information from the OAM fault handling module, it updates the APS state machine for the corresponding APS protection group. Simultaneously, it can receive and send APS protocol messages. Specifically, it updates the APS state machine based on the fault status of two sessions within the APS protection group and the received APS protocol messages. The APS synchronization message generation module can periodically generate messages based on the APS state machine's transition states. Figure 7 The fault handling engine sends APS synchronization messages in the format shown to other line cards of the device. After the APS state machine is updated, if a path switch is required, the entry update IP processing module can also perform entry I / O processing.

[0116] It is worth emphasizing that, Figure 8 Taking a specific APS protection group as an example, the OAM fault handling for the two OAM sessions corresponding to this APS protection group is performed on the protection link board, and the APS state machine processing for this APS protection group is also handled on the protection link board. The OAM fault handling module and APS state machine processing module of the working link board do not need to operate for faults in the working link sessions corresponding to this APS protection group. However, the OAM processing engine of the working link board needs to monitor the status of the working link in real time and periodically send OAM fault transmission messages to the fault handling engine on the protection link board. The entry update IO processing module of the working link board also needs to receive the APS synchronization messages for the corresponding protection link sessions from the protection link board and perform entry IO processing based on the information in the messages. The above is an explanation of the process using a protection group as an example.

[0117] In addition, in the examples above, the OAM fault handling of the APS protection group is performed on the protection link card, but in actual applications, it can also be performed on other line cards. The specific method can be determined based on actual needs.

[0118] When there are multiple OAM protection groups, the same principles apply. Therefore, a link card may function as a working link card in some OAM protection groups and as a protection link card in others. Its fault handling engine only needs to handle the faults of the corresponding sessions using the methods described above.

[0119] To perform the corresponding steps in the above embodiments and various possible methods, an implementation of the service protection device 200 is given below. Optionally, the service protection device 200 can adopt the above-described... Figure 1 The device structure of the distributed multi-chip device 100 is shown. Further, please refer to... Figure 9 , Figure 9 This is a block diagram of the service protection device 200 provided in this embodiment. It should be noted that the basic principle and technical effects of the service protection device 200 provided in this embodiment are the same as those in the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments. In this embodiment, the service protection device 200 may include: an OAM processing engine 210 and a fault processing engine 220.

[0120] The OAM processing engine 210 is used to obtain fault report information corresponding to each OAM session on the local line card by detection, and to issue fault information notifications according to configuration information and the fault report information. The configuration information is used to indicate the objects to be notified of the fault information.

[0121] The fault processing engine 220 is used to process the APS state machine corresponding to each first target APS protection group based on the fault report information of each OAM session corresponding to each first APS protection group obtained by this line card, and obtain an updated protection state table. The first APS protection group is the APS protection group for which the fault processing engine of this line card needs to process the APS state machine.

[0122] The fault handling engine 220 is also used to send APS synchronization messages to other line cards according to the updated protection status table, and to update the APS entries. The APS synchronization messages are used to indicate the switching status of each first APS protection group determined by this line card.

[0123] Please refer to Figure 10 , Figure 10 for Figure 9A block diagram of the OAM processing engine 210. In this embodiment, the OAM processing engine 210 may include a fault scanner 211 and a notification message generation module 212. The fault scanner 211 is used to perform fault scanning on each OAM session on the line card to obtain the status information of each OAM session. The notification message generation module 212 is used to generate OAM fault notification messages based on the status information of each OAM session on the line card, wherein the OAM fault notification message includes fault report information of each OAM session on the line card.

[0124] Please refer to Figure 11 , Figure 11 for Figure 9 A block diagram of the fault handling engine 220. In this embodiment, the fault handling engine 220 includes an OAM fault handling module 221, an APS state machine processing module 222, an entry update IO processing module 223, and an APS synchronization message generation module 224.

[0125] The OAM fault processing module 221 is used to parse the obtained OAM fault notification message to obtain the fault report information of each OAM session. The fault report information of an OAM session includes the fault type, OAM session identifier, link type of the link monitored by the OAM session, and APS protection group identifier corresponding to the link monitored by the OAM session. The OAM fault processing module 221 is further configured to: calculate the unreceived duration corresponding to each pending first session identifier based on the first session identifier corresponding to each first APS protection group of this line card and the obtained OAM fault notification message, wherein the unreceived duration corresponding to the pending first session identifier represents the duration during which the pending first session identifier was not obtained from the OAM fault notification message; for each unreceived duration, determine whether the unreceived duration is not less than a preset duration; if the unreceived duration is not less than the preset duration, then use the preset fault type as the fault type of the OAM session corresponding to the pending first session identifier, and generate fault report information for the OAM session; if the unreceived duration is less than the preset duration, then use no fault as the fault type of the OAM session corresponding to the pending first session identifier, and generate fault report information for the OAM session.

[0126] The APS state machine processing module 222 is used to perform APS state machine processing based on the fault message information of the OAM session obtained by the OAM fault processing module 221, so as to obtain the updated protection state table.

[0127] The entry update IO processing module 223 is used to update the APS entries according to the updated protection status table, and to update the APS entries according to the received APS synchronization message when receiving the APS synchronization message sent by other line cards.

[0128] The APS synchronization message generation module 224 is used to generate APS synchronization messages based on the updated protection status table and send the generated APS synchronization messages to other line cards.

[0129] From an overall functional module framework design perspective, the OAM processing engine can be implemented in an ASIC, ensuring that all session scans and OAM fault message transmissions are performed within a 10ms or lower time period. The fault processing engine can be implemented using an FPGA or a dedicated processor to process OAM fault messages, integrate the APS protocol state machine, and update the APS switching state table (similar to the PSM format). It can periodically convert APS state table information into PSM protection through simple transformations or directly perform table entry update IO operations. Each module operates independently with a fixed cycle, ensuring controllable update cycles for all device line cards.

[0130] Therefore, this application provides a design architecture and implementation method for a distributed multi-chip device service and link protection chip, which takes into account and performs functions such as fault detection, protection switching, multi-line card information synchronization, and upper-layer system information processing as a whole, thereby realizing the protection function of the overall device.

[0131] This application also provides a readable storage medium storing a computer program thereon, which, when executed by a processor, implements the aforementioned service protection method.

[0132] In summary, this application provides a service protection method, apparatus, distributed multi-chip device, and readable storage medium. It detects and obtains fault message information corresponding to each OAM session on the local line card, and performs fault information notification based on configuration information indicating the fault information notification object and the detected fault message information corresponding to each OAM session. Furthermore, based on the fault report information of each OAM session corresponding to each first APS protection group obtained by the local line card, it processes the APS state machine corresponding to each first target APS protection group to obtain an updated protection state table. Then, based on the updated protection state table, it sends APS synchronization messages to other line cards and updates the APS entries. The first APS protection group is the APS protection group that requires APS state machine processing by the local line card, and the APS synchronization message is used to indicate the switching status of each first APS protection group determined by the local line card. Thus, through a synchronization mechanism for full-frame OAM fault notification and protection group information of a distributed multi-chip device, the link monitoring and switching of the distributed multi-chip device can be synchronized across multiple line cards.

[0133] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0134] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0135] If the aforementioned functions are implemented as software functional modules 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 application, in essence, 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 application. 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.

[0136] The above description is merely an optional embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A service protection method, characterized in that, The method, applied to line cards in a distributed multi-chip device, includes: The fault report information corresponding to each OAM session on this line card is obtained by detection, and the fault information is notified according to the configuration information and the fault report information. The configuration information is used to indicate the fault information notification object. Based on the fault report information of each OAM session corresponding to each first APS protection group obtained by this line card, the APS state machine corresponding to each first target APS protection group is processed to obtain the updated protection state table. Among them, the first APS protection group is the APS protection group that needs to be processed by this line card for APS state machine. According to the updated protection status table, APS synchronization messages are sent to other line cards and APS entries are updated. The APS synchronization messages are used to indicate the switching status of each first APS protection group determined by this line card. The step of sending APS synchronization messages to other line cards according to the updated protection status table includes: The switching status of each first APS protection group is saved in the APS synchronization message in the form of a bitmap and sent to other line cards.

2. The method according to claim 1, characterized in that, The process of processing the APS state machine corresponding to each first target APS protection group based on the fault report information of each OAM session corresponding to each first APS protection group obtained by this line card includes: The obtained OAM fault notification messages are parsed to obtain fault report information for each OAM session. The fault report information for an OAM session includes the fault type, OAM session identifier, link type of the link monitored by the OAM session, and APS protection group identifier corresponding to the link monitored by the OAM session. Based on the fault report information of each OAM session, the fault report information of the two OAM sessions corresponding to each first APS protection group is determined, and the state of the APS state machine of the first APS protection group is updated based on the fault report information of the two OAM sessions corresponding to each first APS protection group.

3. The method according to claim 2, characterized in that, One type of fault is no fault. The step of updating the state of the APS state machine corresponding to each first target APS protection group based on the fault report information of each OAM session corresponding to each first APS protection group obtained from this line card, and obtaining the updated protection state table, also includes: Based on the first session identifier corresponding to each first APS protection group of this line card and the obtained OAM fault notification message, the non-received duration corresponding to each pending first session identifier is calculated. The non-received duration corresponding to the pending first session identifier represents the duration during which the pending first session identifier was not obtained from the OAM fault notification message. For each period of unreceived data, determine whether the period of unreceived data is not less than a preset duration; If the duration of non-receipt is not less than the preset duration, the preset fault type is used as the fault type of the OAM session corresponding to the first session identifier to be processed, and fault report information of the OAM session is generated. If the duration of non-receipt is less than the preset duration, then no fault is taken as the fault type of the OAM session corresponding to the first session identifier to be processed, and fault report information of the OAM session is generated.

4. The method according to claim 2, characterized in that, The step of updating the state of the APS state machine of each first APS protection group based on the fault report information of the two OAM sessions corresponding to each first APS protection group includes: Based on the received APS protocol messages and the fault report information of the two OAM sessions corresponding to each first APS protection group, the state of the APS state machine of each first APS protection group is updated.

5. The method according to claim 1, characterized in that, The method of obtaining fault report information corresponding to each OAM session on this line card through detection includes: Perform a fault scan on each OAM session on this line card to obtain the status information of each OAM session; An OAM fault notification message is generated based on the status information of each OAM session on this line card. The OAM fault notification message includes fault report information of each OAM session on this line card.

6. The method according to claim 1, characterized in that, The APS synchronization message includes at least one APS synchronization message. Each APS synchronization message includes the switching status of multiple first APS protection groups stored in a bitmap format and the APS protection group reference value corresponding to the APS synchronization message.

7. The method according to claim 1, characterized in that, The APS state machine processing for an APS protection group is performed on a single line card, and the method further includes: Upon receiving an APS synchronization message from another line card, update the APS entries based on the received APS synchronization message.

8. A service protection device, characterized in that, The device, applied to line cards in a distributed switch, is used to execute the service protection method as described in any one of claims 1-7, and includes: an OAM processing engine and a fault handling engine. The OAM processing engine is used to obtain fault report information corresponding to each OAM session on the local line card by detection, and to issue fault information notifications according to the configuration information and the fault report information, wherein the configuration information is used to indicate the fault information notification object; The fault handling engine is used to process the APS state machine corresponding to each first target APS protection group based on the fault report information of each OAM session corresponding to each first APS protection group obtained by this line card, and obtain an updated protection state table. The first APS protection group is the APS protection group that needs to be processed by the fault handling engine of this line card for APS state machine processing. The fault handling engine is also used to send APS synchronization messages to other line cards according to the updated protection status table, and to update the APS entries. The APS synchronization messages are used to indicate the switching status of each first APS protection group determined by this line card.

9. A distributed multi-chip device, characterized in that, The device includes multiple line cards, each line card including a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the service protection method according to any one of claims 1-7.

Images