Protection switching method and apparatus for optical transport network

Abstract

A protection switching method and apparatus for an optical transport network, which method and apparatus relate to the technical field of optical communications and are used for improving the switching performance. In the present application, before completing a re-framing operation, a first network device transparently transmits to an output end a data frame stream received from a second transmission path, and then from the output end, the data frame stream is transparently transmitted to a downstream network device, wherein the transparent transmission of the data frame stream can be understood as that no change is made to a positioning identifier in the received data frame stream; and after receiving the transparently transmitted data frame stream, nodes at the downstream can start a re-framing operation without waiting for the completion of the re-framing of an upstream node, and if a transmission delay is ignored, it can be considered that hop nodes at the downstream start the re-framing operation almost at the same time. Therefore, the duration of re-framing does not increase as the number of hops increases, thereby improving the switching performance.

Description

A method and device for protection switching of an optical transport network

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of the People's Republic of China on February 18, 2024, with application number 202410182700.0 and application name “A method and device for protection switching of an optical transport network”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of optical communication technology, and in particular to a method and device for protection switching of an optical transport network. Background Art

[0004] Fine-grain optical transport network (fgOTN) is a major technological innovation based on hard pipe technology within the OTN framework and represents the next evolution of OTN technology. It primarily targets the transport of high-quality services with small granularity below 1G. It is widely applicable to government and enterprise networks, as well as dedicated lines in industries such as power and healthcare. fgOTN will play an even more important role in demanding high-quality access to computing networks for enterprise production systems and for emerging services such as extended reality (XR) technology in the future smart home.

[0005] In terms of protection, fgOTN also supports SNCP segment protection capabilities to achieve high-reliability protection against multiple fiber breaks in optical networks. However, in cascade or segment protection scenarios, when a node undergoes protection switching due to a fault, all downstream nodes from that node need to perform reframing operations. Before reframing is completed, each node will have invalid data frames (the payload area is filled with invalid data) during the node reframing process. The invalid data frames determine the position of the framing indicator (i.e., the frame start position) added during framing based on the frame header position before the protection switching. Therefore, each node needs to wait until the upstream node completes reframing before reframing can be performed. As a result, the reframing time increases with the number of hops, affecting switching performance.

[0006] Summary of the Invention

[0007] Embodiments of the present application provide a method and apparatus for protection switching in an optical transport network, to improve switching performance.

[0008] In a first aspect, an embodiment of the present application provides a method for protection switching of an optical transport network, comprising: a first network device detecting a fault on a first transmission path at an ingress end; the ingress end being configured to connect the first network device to an upstream network device of the first network device;

[0009] The first network device switches at the inlet end to receive the data frame stream from the upstream network device through the second transmission path; the first network device performs a reframe operation on the data frame stream at the inlet end; before the first network device completes the reframe operation at the inlet end, the first network device transparently transmits the data frame stream to the downstream network device of the first network device at the outlet end, and the outlet end is used to connect the first network device and the downstream network device.

[0010] In the above-mentioned scheme of the present application, before completing the reframing operation, the first network device transparently transmits the data frame stream received from the second transmission path to the exit end, and then the exit end transparently transmits the data frame stream to the downstream network device. Transparently transmitting the data frame stream can be understood as not making any changes to the positioning identifier in the received data frame stream. In the prior art, a framing identifier is added according to the framing rules before protection switching during the reframing process. After receiving this type of data frame, the downstream node can frame it and will not start reframing. Therefore, each downstream node needs to wait for the upstream node to reframe before sending the data frame stream with a new frame header to start the reframing operation. In the embodiment of the present application, the downstream nodes can start the reframing operation after receiving the transparently transmitted data frame stream, without waiting for the upstream node to complete the reframing. Ignoring the transmission delay, it can be understood that each downstream hop node starts the reframing operation almost simultaneously. Therefore, the reframing time does not increase with the increase in the number of hops, thereby improving the switching performance.

[0011] In one possible design, the first network device detects a fault on the first transmission path at the ingress end, including: the first network device detects a frame loss LOF alarm on the first transmission path at the ingress end.

[0012] In one possible design, the first network device switches at the ingress end to receive the data frame stream from the upstream network device through the second transmission path. The method also includes: when the first network device detects at the ingress end that a LOF alarm is generated on the first transmission path, the first network device inserts an alarm indication signal AIS maintenance frame at the egress end, the overhead area of ​​the AIS maintenance frame includes a framing identifier, and the insertion position of the framing identifier is determined based on the frame header position of the data frame stream before the failure of the first transmission path occurs; the first network device sends the AIS maintenance frame to the downstream network device at the egress end.

[0013] In the above design, when inserting the AIS maintenance frame, the framing identifier is inserted according to the frame header position of the data frame on the transmission path before the protection switching. However, the frame header position of the data frame stream after the protection switching may be offset from the frame header position of the data frame on the transmission path before the switching, which may affect the triggering of the framing operation by the downstream node. Therefore, this application adopts a transparent transmission solution, which will not affect the timely triggering of the reframing operation by the downstream node, thereby improving switching performance.

[0014] In one possible design, the method also includes: when the first network device detects that a LOF alarm is generated in the first transmission path at the inlet end, the state of the pipe to which the data frame stream belongs is updated to an alarm indication state, and the alarm indication state is used to indicate that there is a fault in the upstream direction of the first network device; the data frame stream is transparently transmitted to the downstream network device at the outlet end, including: before the alarm indication state terminates, the data frame stream is transparently transmitted to the downstream network device at the outlet end; wherein the duration of the alarm indication state is greater than or equal to the execution duration of the reframe operation.

[0015] In some examples, the duration of the alarm indication state can be configured to be greater than or equal to the execution duration of the reframe operation. Therefore, the data frame stream can be transparently transmitted to the downstream network device at the egress end before the alarm indication state is terminated. In other examples, the termination time of the alarm indication state is later than the completion time of the protection switching. In some implementation scenarios, the alarm indication state can be terminated after the reframe operation is completed. In one possible example, the termination time of the alarm indication state is later than or equal to the completion time of the reframe operation.

[0016] In the above solution of the present application, by modifying the alarm indication state, a transparent data frame flow (valid data frame) is triggered before the alarm indication state is terminated, that is, the service data is carried.

[0017] In one possible design, a sub-layer monitored subnetwork connection protection SNCS group is configured between the first network device and a downstream network device of the first network device, and the overhead area of ​​the AIS maintenance frame also includes a channel monitoring PM segment overhead and a tandem connection monitoring TCM segment overhead, and the PM segment overhead indicates that a fault exists on the first network device; before the first network device sends the AIS maintenance frame to the downstream network device at the egress end, the method also includes: the first network device modifies the TCM segment overhead of the AIS maintenance frame at the egress end; the modified TCM segment overhead of the AIS maintenance frame indicates that the fault does not extend to the downstream direction of the first network device, and is used to instruct the downstream network device to perform non-intrusive monitoring of the PM segment overhead, but prohibits SNCS switching when it is monitored that the PM segment overhead indicates that a fault exists on the first network device.

[0018] In the above solution, in a cascaded SNCS group scenario, even if the downstream network device detects that the TCM segment overhead does not indicate a fault, it still performs non-intrusive PM layer monitoring to suppress frame header regeneration and transparently transmit the data frame stream. However, if the PM segment overhead monitoring indicates a fault on the first network device, SNCS switching is prohibited.

[0019] In one possible design, the data frames in the data frame flow are fine-grained optical transport network fgOTN frames.

[0020] In a second aspect, an embodiment of the present application provides a method for protection switching of an optical transport network, comprising: a second network device receives an AIS maintenance frame from an upstream network device of the second network device at an inlet end, and sends the AIS maintenance frame to a downstream network device through an outlet end; the inlet end is used to connect the second network device with the upstream network device; the outlet end is used to connect the second network device with the downstream network device; after a set period of time has passed since the second network device received the AIS maintenance frame, the second network device receives a data frame stream from the upstream network device at the inlet end; the second network device performs a reframe operation on the data frame stream at the inlet end, and before completing the reframe operation, transparently transmits the data frame stream to the downstream network device of the second network device at the outlet end.

[0021] In the embodiments of the present application, after receiving a transparently transmitted data frame stream, downstream nodes can initiate reframing operations without waiting for the upstream node to complete reframing. Ignoring transmission delays, it can be understood that each downstream hop node initiates reframing operations almost simultaneously. As a result, the reframing time does not increase with the number of hops, thereby improving switching performance.

[0022] In one possible design, the method further includes:

[0023] When the second network device receives the AIS maintenance frame, it updates the state of the pipe to which the data frame flow belongs to an alarm indication state, where the alarm indication state is used to indicate that a fault exists in the upstream direction of the second network device;

[0024] Transparently transmitting the data frame flow to the downstream network device at the egress end includes:

[0025] Before the alarm indication state is terminated, transparently transmitting the data frame stream to the downstream network device at the egress end;

[0026] The duration of the alarm indication state is greater than or equal to the execution duration of the reframing operation.

[0027] In one possible design, no subnet connection protection (SNCP) group is configured between the second network device and an upstream network device of the second network device.

[0028] In one possible design, a subnetwork connection protection SNCS group with sublayer monitoring is configured between the second network device and the upstream network device of the second network device, and the overhead area of ​​the AIS maintenance frame also includes a channel monitoring PM segment overhead and a tandem connection monitoring TCM segment overhead; the PM segment overhead indicates that there is a fault in the upstream direction of the second network device; the TCM segment overhead indicates that the fault does not extend to the second network device, so as to instruct the network device not to perform protection switching; after the second network device receives the AIS maintenance frame, before transparently transmitting the data frame stream to the downstream network device at the egress end, the method also includes: non-intrusive monitoring of the AIS maintenance frame, and determining that the PM segment overhead indicates that there is a fault in the upstream direction of the second network device.

[0029] In one possible design, the data frames in the data frame flow are fine-grained optical transport network fgOTN frames.

[0030] In a third aspect, embodiments of the present application provide an apparatus for protection switching in an optical transport network. The protection switching in the optical transport network is applied to a network device, such as a first network device or a second network device. The apparatus includes a processor and a memory. The memory is configured to store program code; the processor is configured to read and execute the program code stored in the memory to implement the method described in the first aspect or any design of the first aspect, or the method described in the second aspect or any design of the second aspect.

[0031] In a fourth aspect, embodiments of the present application provide an apparatus for protection switching in an optical transport network. The protection switching in the optical transport network is applied to a network device, such as a first network device or a second network device. The apparatus includes a processor and an optical transceiver; the processor is configured to execute the method described in the first aspect or any design of the first aspect, or to execute the method described in the second aspect or any design of the second aspect, and to transmit data frame streams and / or AIS maintenance frames through the optical transceiver.

[0032] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a software program. When the software program is read and executed by one or more processors, it can implement the method provided by any one of the designs of the first or second aspects.

[0033] In a sixth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed on a computer, causes the computer to execute the method provided by any one of the designs of the first aspect or the second aspect.

[0034] In a seventh aspect, an embodiment of the present application provides a chip connected to a memory, configured to read and execute a software program stored in the memory to implement the method provided by any one of the designs of the first aspect or the second aspect.

[0035] Based on the implementations provided in the above aspects, this application can also be further combined to provide more implementations. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 is a schematic diagram of an OTN network architecture;

[0037] FIG2 is a schematic diagram of an OTN device structure;

[0038] FIG3A is a schematic diagram of the structure of an OTN frame;

[0039] FIG3B is a schematic diagram of the structure of an fgODUflex frame;

[0040] FIG4A is a schematic diagram of a non-cascade segmented protection scenario;

[0041] FIG4B is a schematic diagram of a protection switching process in a non-cascade segment protection scenario;

[0042] FIG5A is a schematic diagram of a cascade segment protection scenario;

[0043] FIG5B is a schematic diagram of a protection switching process in a cascade segment protection scenario;

[0044] FIG6 is a flow chart of a method for protection switching of an optical network provided in an embodiment of the present application;

[0045] FIG7 is a flow chart of a method for protection switching of an optical network provided in an embodiment of the present application;

[0046] FIG8 is a flow chart of another method for protection switching of an optical network provided in an embodiment of the present application;

[0047] FIG9A is a flow chart of a protection switching method for an optical transport network provided in an embodiment of the present application;

[0048] FIG9B is a schematic diagram of a protection switching process of an optical transport network provided in an embodiment of the present application;

[0049] FIG10A is a flow chart of a protection switching method for an optical transport network provided in an embodiment of the present application;

[0050] FIG10B is a schematic diagram of a protection switching process of an optical transport network provided in an embodiment of the present application;

[0051] FIG11 is a schematic structural diagram of a possible protection switching device for an optical transport network according to an embodiment of the present application;

[0052] FIG12 is a schematic structural diagram of another possible optical transport network protection switching device according to an embodiment of the present application;

[0053] FIG13 is a schematic structural diagram of another possible device for protection switching of an optical transport network according to an embodiment of the present application. DETAILED DESCRIPTION

[0054] The embodiments of the present application are applicable to optical networks, such as OTN. An OTN is typically composed of multiple OTN devices connected by optical fibers and can be organized into different topologies, such as linear, ring, and mesh, depending on specific needs. The OTN shown in Figure 1 is composed of two OTN networks. Each OTN network is composed of a certain number of OTN devices (N1 to N7). Depending on actual needs, an OTN device may have different functions. Generally speaking, OTN devices are divided into optical layer devices, electrical layer devices, and optoelectronic hybrid devices. Optical layer devices refer to devices that can process optical layer signals, such as optical amplifiers (OAs). Electrical layer devices refer to devices that can process electrical layer signals, such as devices that can process OTN signals. Optoelectronic hybrid devices refer to devices that have the ability to process both optical and electrical layer signals. It should be noted that, depending on specific integration requirements, an OTN device can integrate multiple different functions. The technical solutions provided in this application are applicable to OTN devices of different forms and levels of integration. The network devices involved in the embodiments of this application may be OTN devices, which may also be referred to as network nodes, or simply nodes.

[0055] Figure 2 is a schematic diagram of a possible OTN equipment structure. The OTN equipment here can refer to the OTN nodes (N1-N7) in Figure 1. Specifically, an OTN device includes power supplies, fans, auxiliary boards, and may also include tributary boards, line boards, cross-connect boards, optical layer processing boards, and system control and communication boards. Power supplies power the OTN equipment and may include primary and backup power supplies. Fans dissipate heat. Auxiliary boards provide auxiliary functions such as external alarms and external clock access. Tributary boards, cross-connect boards, and line boards primarily process OTN electrical layer signals. Tributary boards receive and transmit various customer services, such as SDH, packet, Ethernet, and fronthaul services. Furthermore, tributary boards can be divided into client-side optical modules and signal processors. Client-side optical modules can be optical transceivers, used to receive and / or transmit service data. Signal processors map and demap service data into data frames. Cross-connect boards exchange data frames, completing the exchange of one or more types of data frames. The circuit board mainly implements the processing of line-side data frames. Specifically, the circuit board can be divided into a line-side optical module and a signal processor. Among them, the line-side optical module can be a line-side optical transceiver for receiving and / or sending data frames. The signal processor is used to implement multiplexing and demultiplexing, or mapping and demapping processing of line-side data frames. System control and communication boards are used to implement system control and communication. Specifically, information can be collected from different boards through the backplane, or control instructions can be sent to the corresponding boards. It should be noted that, unless otherwise specified, the specific components (for example: signal processors) can be one or more, and this application does not impose any restrictions. It should also be noted that the embodiments of the present application do not impose any restrictions on the types of boards included in the device, as well as the specific functional design and quantity of the boards.

[0056] It should be noted that the specific types and quantities of boards included in each device may vary. For example, a network device that functions as a core node may not have a tributary board, while a network device that functions as an edge node may have multiple tributary boards.

[0057] The following first describes the technical concepts involved in the embodiments of this application.

[0058] 1) Loss of frame (LOF) alarm. LOF alarm refers to frame loss on the receiving side of the line. Generally, a LOF alarm is detected when errors are detected in the reception of the A1 and A2 bytes. The A1 and A2 bytes are frame synchronization bytes.

[0059] 2) Out of Frame (OOF) Alarm. This occurs when the receiving device's frames are not in exact phase with the received signal. This occurs when the frame header cannot be identified (distinguished between different frames) for several consecutive frames (e.g., five frames). The receiving device experiences an Out of Frame (OOF) alarm and generates one.

[0060] 3) Data frame: This can be an OTN frame or a flexible Ethernet (FlexE) frame, used to carry various service data and enable management and monitoring of service data. The OTN frame can be a fine-grained fgOTN frame. The OTN frame can also be an optical data unit-k (ODUk), ODUCn, ODUflex, or an optical transport unit (OTU) k, OTUCn, or an optical payload unit (OPU), or a flexible OTN (FlexO) frame, or an optical service unit (OSU), etc. The data frame can also be other frame structures suitable for optical networks.

[0061] Figure 3A shows a schematic diagram of the OTN frame structure. An OTN frame can have a 4×4080 bit structure, i.e., 4 rows × 4080 columns. The OTN frame structure includes a frame alignment area, an OTU overhead (OH), an ODU OH, an optical payload unit (OPU) OH, an OPU payload area, and a forward error correction (FEC) area. The first 16 columns are overhead bytes, the last 256 columns are the FEC check area, and the middle 3808 columns are the payload area. The frame alignment overhead can include two parts: a frame alignment signal (FAS) and a multiframe alignment signal (MFAS). Multiple OTN frames constitute an OTN multiframe, for example, 8 OTN frames constitute an OTN multiframe. OPUk is used to carry service data and includes the OPU payload area and OPU OH, where k represents the rate level of the OPU. k = 1, 2, 3, and 4 correspond to 2.5G, 10G, 40G, and 100G rates, respectively. k = flex, or OPUflex, can correspond to any rate level and is used only to carry single-channel services. k = Cn, or OPUCn, corresponds to a rate level n times 100G. ODUk is the information structure used to support OPUk and consists of the OPUk and ODUk OHs. Similarly, the capacity of ODUk is differentiated by k. ODUflex consists of the OPUflex and ODUflex OHs. ODUCn consists of the OPUCn and ODUCn OHs. OTUk consists of the ODUk, FEC area, and OTUk OH. OTUCn consists of the ODUCn and OTUCn OHs, excluding the FEC area.

[0062] Justification Control (JC) byte in the OPU overhead: It is used for data path maintenance and performance monitoring. Byte Redundancy (RES) is a field in the OPU overhead, which is used to indicate redundant information in the protection overhead. Positive justification opportunity byte (NJO) and negative justification opportunity byte (PJO). PJO is an overhead used to determine the optical bearer structure. PJO can help the receiver correctly parse the optical signal to extract the effective payload data. The size of the PJO overhead depends on the type of optical bearer structure used and the number of data frames. The role of NJO and PJO is to ensure that the optical signal in the OTN can be correctly transmitted and parsed in the network. The payload structure identifier (PSI) in the OPU overhead is a field used to identify the payload structure. It can be used to indicate information such as the format, type, and length of the data in the OPU.

[0063] The area corresponding to the multiframe alignment sequence MFAS of 1 is the reserved byte; the area corresponding to the multiframe alignment sequence MFAS of 2 to 17 is the multiplexing structure indication MSI. The MSI area contains the multiplexing structure information of the low-speed ODUj branch signal in the high-speed OPUk signal. According to the MSI indication, the position of the low-speed branch signal in the OPU payload area can be determined.

[0064] TCM1-TCM6 are ODU overheads used to transmit monitoring and control information to ensure transmission quality and reliability. TCM1-TCM6 also monitor ODU transmission conditions, such as transmission error rate, latency, and packet loss, to ensure data is not damaged or lost during transmission. TCM1: Transmits channel error monitoring (BIP-8) and frame synchronization signals. TCM2: Transmits a portion of cross overhead and section monitoring port information. TCM3: Transmits the entire cross overhead and path monitoring port information. TCM4: Transmits channel performance monitoring (PM) information and a portion of cross overhead information. TCM5: Transmits the physical location of channel maintenance personnel and a portion of cross overhead information. TCM6: Transmits protection overhead information and the entire cross overhead information. Each TCM channel is specifically designed to support the transmission and monitoring of ODUk frames.

[0065] The TCMact (TCM Activation) field indicates whether TCM monitoring is enabled for this ODUk channel. If TCMact is 1, TCM monitoring is enabled for this channel; if TCMact is 0, TCM monitoring is not enabled for this channel.

[0066] The Regenerator Section Overhead Byte (RES) is an overhead byte in ODUk, used to transmit information as the optical signal passes through the regenerator. Fixed Transport Frame Overhead (FTFL): The FTFL is the most basic overhead byte in ODUk, providing essential management and protection functions. The FTFL includes essential control information such as frame synchronization, header error detection, frame counts, and port identification. General Communication Channel (GCC): The GCC is a programmable communication channel in ODUk, used to transmit ODUk-related management and control information. The GCC helps network administrators remotely monitor, diagnose, and configure ODUk equipment. Automatic Protection Switching / Path Communication Channel (APS / PCC): The APS / PCC is a protection overhead byte in ODUk, used to implement automatic protection switching and backup path communication. When a primary path fails, the APS / PCC rapidly switches data to the backup path and notifies network administrators. EXP overhead bytes: Used to transmit experimental information, such as test data and debugging information. Signal Monitoring (SM) monitors signal quality and strength. SM continuously monitors signals transmitted on the OUTk channel and provides timely feedback on signal quality. GCC0 (General Communication Channel Zero) translates incoming signals. GCC0 in the OTN translates signals transmitted on the OUTk channel into the standard OTN language so that the receiver can correctly understand the signal.

[0067] Figure 3B shows a schematic diagram of the structure of the fgODUflex frame. The fgODUflex frame is an octet-based block frame structure with 4 rows and 3824 columns. The fgODUflex frame includes an overhead area and a payload area. Columns 1 to 14 and columns 1905 to 1918 of the fgODUflex are dedicated to the fgODUflex overhead area. It consists of frame alignment signals (FAS0 to FAS7), multi-frame alignment signals, path monitoring (PM), TCM1, TCM2, and phase difference accumulation (DA). Columns 15 to 1904 and columns 1919 to 3824 of the fgODUflex are dedicated to the fgOPUflex area. It consists of one fgOPUflex frame.

[0068] The fgODUflex OH information is added to the fgODUflex information payload to create the fgODUflex. It includes information that supports the maintenance and operational functions of the fgODUflex connection. The fgODUflex OH consists of fields dedicated to end-to-end fgODUflex trail and two-stage tandem connection monitoring. The PM / TCM1 / TCM2 fields contain the following subfields: Trace Identifier (TTI), Bit Interleaved Parity (BIP-8), Backward Defect Indication, Backward Error Indication, and Backward Introduced Alignment Error (BEI / BIAE), a status bit indicating the presence of a maintenance signal (STAT), Delay Measurement (DM), and Automatic Protection Switch (APS). It should be noted that BIAE is only applicable to TCM1 or TCM2.

[0069] The fgODUflex Trace Identifier (TTI) is defined as a 32-byte string. For PM, the 8-byte TTI field is defined in rows 1 through 4, columns 1909 and 1910; for TCM1, the 8-byte TTI field is defined in rows 1 through 4, columns 1913 and 1914; and for TCM2, the 8-byte TTI field is defined in rows 1 through 4, columns 1911 and 1912. The complete 32-byte TTI information for PM, TCM1, or TCM2 is transmitted every four frames. The four 8-byte sets in the TTI are indexed by MFAS[7,8]. A bit-interleaved parity-8 (BIP-8) code is defined in the fgODUflex overhead for error detection. Each fgODUflex BIP-8 is calculated over the bits in the fgOPUflex area (columns 15 to 1904 and 1919 to 3824) of fgODUflex frame #i and inserted into the fgODUflex BIP-8 overhead location in fgODUflex frame #i+2. For PM, the BIP-8 is located in row 3, column 11; for TCM1, the BIP-8 is located in row 3, column 8; and for TCM2, the BIP-8 is located in row 3, column 5.

[0070] 4) Path monitoring (PM) provides an end-to-end path monitoring function. The monitoring range of tandem connection monitoring (TCM) is part of the PM monitoring range.

[0071] The OTN includes a six-level TCM overhead (OH). TCM includes a trail trace identifier (TTI), bit interleaved parity 8 (BIP8), backward defect indication (BDI), backward error indication (BEI), state indicator (STAT), and backward incoming alignment error (BIAE). TCM can be configured for nodes that require it. For each node, TCM in the source direction (or sending direction) and TCM in the sink direction (or receiving direction) can be configured in different modes or the same mode.

[0072] The sending direction has two modes: operational and transparent. If a network device uses the operational mode for a certain level of TCM, it will regenerate the TCM at that level, for example, by inserting BIP-8, BEI, BIAE, BDI, and TTI. If a network device uses the transparent mode for a certain level of TCM, it will not process the TCM at that level.

[0073] The receiving direction can be in operational mode, transparent mode, or monitoring mode. If the network device uses the operational mode for a certain level of TCM, the network device monitors the TCM at that level. For example, this includes monitoring overhead such as BIP-8, BEI, BIAE, BDI, and TTI, generating corresponding defects, and performing subsequent processing, such as inserting AIS or generating a trail signal fail (TSF). If the network device uses the monitoring mode for a certain level of TCM, the network device monitors and processes the TCM at that level. For example, this includes monitoring overhead such as BIP-8, BEI, BIAE, BDI, and TTI, generating corresponding defects, but not performing subsequent processing for AIS and TSF. If the network device uses the transparent mode for a certain level of TCM, the network device does not process the TCM at that level.

[0074] 5) Sub-network connection protection (SNCP) involves pre-arranging a dedicated protection route for a sub-network connection. In the event of a sub-network failure, the dedicated protection route takes over the sub-network's transmission responsibility for the entire network. SNCP uses a protection channel for each transmission direction that follows a different route from the working channel. For example, when SNCP is used to transmit traffic between nodes A and B, node A uses a bridge to transmit traffic to node B via sub-network 1 (the working sub-network connection (SNC) or working channel) and sub-network 2 (the protection SNC or protection channel). Node B then uses a switching switch to select a traffic path from either direction based on a switching criterion. Node B then performs a sub-network connection protection group switching, switching from receiving traffic from node A via sub-network 1 to receiving traffic from node A via sub-network 2.

[0075] SNCP adopts a dual-send selective reception mode. Under normal circumstances, the working SNC is selected to receive services. When the working SNC fails, the protection SNC is selected to receive services.

[0076] SNCP includes non-intrusively monitored sub-network connection protection (SNCP / N or SNCN) and SNCP with sublayer monitoring (SNCP / S or SNCS). The monitoring method adopted by SNCP / N is to detect end-to-end or sublayer overhead or operation administration and maintenance (OAM) information in the signal. SNCP / S detects service layer defects, continuity / connectivity defects within the layer network, and error degradation within the layer network by using sublayer overhead / OAM. SNCP / S uses the SF alarm of the PM segment of the service layer and the SF alarm of the TCM segment of this layer as switching conditions. Overhead can be, for example, PM or TCM.

[0077] 6) Alarm indication signal (AIS) is a maintenance signal in the OTN network. The function of AIS is to transmit alarm information, that is, to transmit the signal of service failure of the upstream node to the downstream node or to transmit the information of service layer signal failure to the client layer. The format of AIS maintenance frame and data frame can be the same. The indication field included in the overhead of AIS maintenance frame can be the STAT field in the PM segment overhead or the STAT field in the TCM segment overhead. Table 1 shows the meaning of different STAT values ​​in the PM segment overhead. For example, when the indication field included in the overhead of AIS maintenance frame can be the STAT field in the PM segment overhead, the STAT value in the PM segment overhead is 111.

[0078] Table 1

[0079] Table 2 shows the meanings of different STAT values ​​in the TCM segment overhead. For example, when the indication field included in the overhead of the AIS maintenance frame may be the STAT field of the TCM segment overhead, the value of the STAT field of the TCM segment overhead is 111.

[0080] Table 2

[0081] Exemplarily, when the overhead of the AIS maintenance frame includes the TCM segment overhead and the PM segment overhead, if the TCM segment overhead indicates no alarm (or no fault), the STAT value in the PM segment overhead is 111, and the STAT value of the TCM segment overhead is 001.

[0082] 7) Framing. Framing is used to identify the starting position of a data frame. The overhead of the data frame involved in the embodiments of the present application includes framing indication information (or framing identifier) ​​and overhead information used for management, monitoring and maintenance. Exemplarily, the framing indication information may include a frame alignment signal (FAS) or an alignment marker (AM). The overhead information used for management, monitoring and maintenance may include TCM overhead, such as BIP8, BEI, BIAE, BDI, TTI and other overheads. In some scenarios, the overhead information also includes other information in addition to the overhead of FAS, AM, and TCM.

[0083] 8) Upstream or Downstream. Take the transmission link between device A and device B, for example, where the link passes through device M. When data is transmitted from device A to device B, and device M is located between device A and device B in the data transmission direction, device A is upstream of device M, and device B is downstream of device M. In the transmission direction from device A to device B, device A is the source device, and device B is the sink device. Conversely, when data is transmitted from device B to device A, and device M is located between device A and device B in the data transmission direction, device B is upstream of device M, and device A is downstream of device M. In the transmission direction from device B to device A, device B is the source device, and device A is the sink device.

[0084] In addition, in the description of this application, unless otherwise specified, "plurality" means two or more than two. Furthermore, " / " indicates that the objects associated with each other are in an "or" relationship. For example, A / B can mean A or B. "And / or" in this application is merely a description of the association relationship between associated objects, indicating that three relationships can exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. A and B can be singular or plural. Furthermore, to facilitate the clear description of the technical solutions of the embodiments of this application, the embodiments of this application use terms such as "first" and "second" to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or order of execution, and do not necessarily define differences. It should also be noted that, unless otherwise specified, the specific description of certain technical features in one embodiment can also be used to explain the corresponding technical features mentioned in other embodiments.

[0085] The embodiments of this application can be applied to cascade protection scenarios and segment protection scenarios, such as those for fgOTN pipes. Of course, they are also applicable to cascade protection and segment protection scenarios for other pipes. This application is applicable to any scenario where switching delay increases with the number of hops, resulting in excessive switching performance.

[0086] Figure 4A shows a schematic diagram of a non-cascaded segmented protection scenario. Figure 4A uses the fgOTN pipeline scenario as an example. In Figure 4A, N1, N2, and N3 are three network nodes. The fgOTN pipeline's passthrough path passes through N1, N2, and N3. Node N1 is configured with SNCP, while nodes N2 and N3 are not. In Figure 4A, W_RX represents the receiving end's working path, P_RX represents the receiving end's protection path, and TX represents the transmitting end. The receiving end can also be referred to as the ingress (in), and the transmitting end can also be referred to as the egress (out). The protection switching process is described below with reference to Figure 4A.

[0087] State 1: Before the fault occurs, N1's SNCP protection receives service data (or data frames, signals) from the working path W_RX and forwards it to node N2 via the TX direction. Since nodes N2 and N3 are unprotected, they both receive data via the RX direction and transmit data via the TX direction. As shown in Figure 4B, the black bar indicates the flow of service data from W_RX@N1 to N2 to N3.

[0088] State 2: The SNCP working path on node N1 fails, meaning that the W_RX path on node N1 loses signal input. This failure eventually triggers SNCP protection switching on node N1, causing it to receive data frames from the P_RX path. However, within the time window before the protection switch occurs on node N1, the W_RX failure occurs, and N1 detects the failure, initiates SNCP switching, and completes the SNCP switchover, switching to receiving data frames from the P-RX path.

[0089] State 2.1, Window 1: After a W_RX failure occurs, node N1 detects the W_RX failure. During this period, N1's TX direction (referred to as N1.TX) maintains the original data frame header position (i.e., the original framing position) and continues to transmit. Due to the lack of signal input, the invalid data frame transmitted by N1.TX maintains the pre-failure framing position (i.e., maintains the original framing identifier position, i.e., transmits the invalid data frame according to the framing start position of the data frame received from W_RX), and the payload area is filled with invalid information. At this time, downstream nodes N2 and N3 are unaware of any failure, as shown in Figure 4B.

[0090] For example, the position of the framing identifier of the invalid data frame sent by N1.TX is determined according to the frame header position (or the frame period start sequence number) of the valid data frame received from W_RX. For example, the frame header position (frame period start sequence number) can be the byte or bit at the beginning of the frame period.

[0091] For example, taking the fgOTN frame as an example, the frame header position (frame period starting sequence number) is 0, and the fixed number of bytes occupied by the fgOTN frame is 4*3824. The position of the data frame positioning identifier is 0+4*3824*i, where i represents the i-th frame, i=0, 1, ...

[0092] State 2.2, Window 2: Between the time N1 detects the W_RX failure and the time N1's SNCP switchover completes, N1 has already detected the W_RX failure. Therefore, it inserts an AIS maintenance frame for the fgOTN pipe in the direction of N1.TX. While N1.TX is sending the AIS maintenance frame, the original framing identifier remains in place. Downstream nodes N2 and N3 then receive the AIS maintenance frame and detect the failure.

[0093] State 3: SNCP switching of the N1 node is completed, and the P_RX->E2E service is restored.

[0094] State 3.1, Window 3: First, N1 receives data frames from N1.P_RX. During this period, N1.RX must complete the framing of the N1.P_RX signal. For example, after N1.RX receives two data frames in succession, it updates from the LOF state to the OOF state, and then continues to receive two data frames in succession to complete the framing operation. At the same time, while N1.RX is performing the framing operation, N1.RX continues to maintain the original frame header (that is, the position of the original positioning identifier) ​​and sends AIS maintenance frames or invalid data frames. When N1.TX completes the framing of the signal from N1.P_RX, N1.TX no longer sends AIS maintenance frames or invalid data frames, but instead sends signals with a new frame header. At this time, the N1 node service is restored.

[0095] For example, the position of the framing identifier of the invalid data frame transmitted by N1.TX is determined by the frame header position (or frame period start sequence number) of the valid data frame received from W_RX. For example, the frame header position (frame period start sequence number) can be the byte or bit at the beginning of the frame period. For example, in the case of an fgOTN frame, the frame header position (frame period start sequence number) is 0, and the fixed number of bytes occupied by the fgOTN frame is 4*3824. Therefore, the position of the data frame framing identifier is 0+4*3824*i, where i represents the i-th frame, and i=0, 1, etc.

[0096] The frame header position of the N1.P_RX path is offset relative to the N1.W_RX path, requiring reframing and subsequent positioning rules. For example, if the frame header position of the N1.P_RX path is offset by 50 bytes relative to the N1.W_RX path, and the positioning rules after framing are determined to be 50 + 4 * 3824 * i, the reframing operation is complete.

[0097] In state 3.2, during window 3, N2.RX continues to receive AIS maintenance frames using the original header. Window 4: When service at N1 is restored, N1.TX transmits service data using a new header. During this period, N2.RX is unable to perform framing using the original header, and N2.RX enters the reframing state. During the reframing phase, N2.TX transmits AIS maintenance frames / invalid signals using the original header from before the failure. After N2.RX completes reframing, N2.TX transmits signals using the new header, and service at N2 is restored.

[0098] In state 3.3, during window 4, N3.RX continues to receive AIS maintenance frames with the original header. Window 5: When service at N2 resumes, N2.TX transmits signals with a new header. During this period, N3.RX is unable to frame with the original header and enters the reframing state. During this period, N3.TX transmits AIS maintenance frames with the original header from before the failure. Window 6: After N3.RX completes reframing, N3.TX transmits signals with the new header, and service at N3 resumes.

[0099] As shown above, due to the influence of frame header regeneration, switching performance is related to the number of hops, and the E2E fgOTN protection switching performance cannot be guaranteed.

[0100] Figure 5A shows a schematic diagram of a cascaded segmented protection scenario. Figure 5A uses the fgOTN pipeline scenario as an example. In Figure 5A, N1, N2, and N3 are three network nodes. The fgOTN pipeline's passthrough path passes through N1, N2, and N3. SNCP / S (SNCS) is configured on each of N1, N2, and N3. In Figure 5A, W_RX represents the receiving end's working path, P_RX represents the receiving end's protection path, and TX represents the transmitting end. The receiving end can also be called the ingress (in) and the transmitting end can also be called the egress (out). TCM regeneration is used between N1.TX <--> N2.W_RX & N2.P_RX, and N2.TX <-> N3.W_RX & N3.P_RX. Node N2 is unaware of AIS maintenance frames inserted by N1. Similarly, node N3 is unaware of AIS maintenance frames inserted by N2. The protection switching process is described below with reference to Figure 5A.

[0101] State 1: Before the fault occurs, the SNCS protection of N1 receives service data (data frames) from the working path W_RX and forwards them to the N2 node and the N3 node in the TX direction.

[0102] As shown in FIG5B , the black bar indicates that the service data is transferred from N1.W_RX->N1.TX->N2.W_RX->N2.TX->N3.W_RX->N3.TX.

[0103] State 2: The SNCS working path on node N1 fails, and N1's W_RX path loses signal input. This failure eventually triggers N1's SNCS protection to initiate a protection switch, causing it to receive signals from P_RX. However, within the time window before N1's protection switch occurs, a W_RX failure occurs. N1 detects the W_RX failure, initiates an SNCS switch, and completes the SNCS switchover, receiving signals from P_RX.

[0104] State 2.1, Window 1: From the time W_RX fails until N1 detects the failure, N1.TX continues to transmit with the original frame header. Due to the lack of signal input, N1.TX maintains the pre-failure frame header position, while the payload area is filled with invalid information. This means that N1.TX transmits an invalid data frame. Downstream nodes N2 and N3 are unaware of the failure.

[0105] In state 2.2, window 2, between N1 sensing the W_RX failure and N1 SNCP switchover completion, N1 has already detected the W_RX failure and therefore inserts an AIS maintenance frame for the fgOTN channel in the N1.TX direction. While N1.TX is sending the AIS maintenance frame, the original frame header is retained. Because the scenario is SNCS protection and TCM overhead regeneration occurs, downstream nodes N2 and N3 are unaware of any fault at this time.

[0106] State 3: N1 SNCS switching is completed, and the P_RX->E2E service is restored.

[0107] State 3.1, Window 3: First, N1 receives a signal from N1.P_RX. During this time, N1.RX completes framing of the N1.P_RX signal. For example, after receiving two consecutive data frames, N1.RX updates from the LOF state to the OOF state and then continues to receive two consecutive data frames to complete the framing operation. Meanwhile, while N1.RX is performing the framing operation, N1.TX maintains the original frame header and transmits the TCM overhead regeneration signal. When N1.RX completes framing of the N1.P_RX signal, N1.TX transmits a signal with the new frame header, and service on N1 is restored.

[0108] In state 3.2, during window 3, N2.W_RX continues to receive fault-free signals using the original frame header. Window 4: When service at node N1 resumes, N1.TX transmits signals using the new frame header. During this period, N2.W_RX is unable to frame using the original frame header, and N2.W_RX enters the reframing state. While N2.RX is reframing, N2.TX transmits TCM regeneration signals using the original pre-failure frame header. After N2.W_RX completes reframing, N2.TX transmits signals using the new frame header, and service at node N2 resumes.

[0109] In state 3.3, N1 SNCP switching is complete, and service is restored from P_RX to N3. During Window 4, N3.W_RX continues to receive fault-free signals using the original frame header. Window 5: When service on N2 is restored, N2.TX transmits signals using the new frame header. During this period, N3.W_RX is unable to frame using the original frame header, and N3.W_RX enters the reframing state. While N3.RX is reframing, N3.TX transmits TCM overhead regeneration signals using the original pre-failure frame header. Window 6: After N3.W_RX completes reframing, N3.TX transmits signals using the new frame header, and service on N3 is restored.

[0110] As shown above, in the SNCS scenario, TCM overhead is regenerated segment by segment. However, each node is affected by the frame header regeneration, resulting in hop-by-hop reframing, which cannot guarantee the E2E fgOTN protection switching performance.

[0111] Based on this, an embodiment of the present application provides a method for protection switching of an optical transport network to prevent the nodes downstream of the fault from continuing to transmit AIS with the original frame header, so that all nodes can start re-frame processing from the same frame, so that the switching delay does not increase with the increase in the number of hops, thereby affecting the switching performance.

[0112] The solution provided in the embodiments of the present application is described below from the perspectives of the network device where the fault occurs and the downstream network device of the network device that sends the fault.

[0113] Referring to Figure 6, a flow chart of a method for protection switching of an optical network provided in an embodiment of the present application is provided. Take the first network device as an example where the node having a fault is a fault. An SNCP group is configured between the first network device and the upstream network device of the first network device. There are two transmission paths (or two transmission channels) between the first network device and the upstream network device of the first network device, namely a first transmission path and a second transmission path. One of the transmission paths serves as a working path, and the other transmission path serves as a protection path. There are an inlet port and an outlet port on the first network device, and the inlet port is used to connect the first network device with the upstream network device of the first network device. The outlet port is used to connect the first network device with the downstream network device of the first network device.

[0114] S601: A first network device detects a failure on a first transmission path at an ingress end.

[0115] Exemplarily, a first network device detects an Out of Flow (LOF) alarm on a first transmission path at an ingress port. For example, a data frame stream (also referred to as a data stream) is transmitted between the first network device and an upstream network device. If, during the data frame stream transmission between the first network device and the upstream network device, the frame header cannot be determined for several consecutive frames (e.g., two frames), the first network device detects an Out of Flow (OOF) alarm at the ingress port. Furthermore, if errors are detected in the A1 and A2 bytes for several consecutive frames, an LOF alarm is detected.

[0116] S602: The first network device switches at an ingress end to receive a data frame stream from the upstream network device through a second transmission path.

[0117] S603: The first network device performs a reframing operation on the data frame flow at an ingress end.

[0118] S604 : Before completing the reframing operation at the ingress end, the first network device transparently transmits the data frame flow to the downstream network device at the egress end.

[0119] Before completing the reframing operation, the first network device transparently transmits the data frame stream received from the second transmission path to the exit end, and then the exit end transparently transmits the data frame stream to the downstream network device. Transparently transmitting the data frame stream can be understood as not making any changes to the positioning identifier in the received data frame stream. In the process of reframing, the prior art adds a framing identifier according to the framing rules before protection switching. After the downstream node receives this type of data frame, it can frame and will not start reframing. Therefore, each downstream node needs to wait for the upstream node to reframe and then send the data frame stream with a new frame header to start the reframing operation. In the embodiment of the present application, the downstream nodes can start the reframing operation after receiving the transparently transmitted data frame stream, without waiting for the upstream node to complete the reframing. Ignoring the transmission delay, it can be understood that each downstream hop node starts the reframing operation almost at the same time.

[0120] Referring to FIG. 7 , the case where the first network device detects a LOF alarm (S701) on the first transmission path at the inlet end and then detects a fault is taken as an example. In some embodiments, in the process from the occurrence of a fault on the first transmission path to the detection of the LOF alarm by the first network device at the inlet end, since the first network device does not receive any data frame at the outlet end, the first network device may send an invalid data frame (also referred to as an invalid frame). It should be noted that the invalid data frame may be sent following the data frame stream, and the position of the positioning identifier of each data frame in the data frame stream is determined according to the frame header position (frame cycle start sequence number) of the data frame stream. For example, the position of the framing identifier of the invalid data frame sent by the outlet end is determined according to the frame header position (cycle start sequence number) of the data frame received from the first transmission path. For example, the frame header position (frame cycle start sequence number) may be the byte or bit at the start of the frame cycle. For example, taking the fgOTN frame as an example, the frame header position (frame period starting sequence number) is 0, and the fixed number of bytes occupied by the fgOTN frame is 4*3824. The position of the data frame positioning identifier is 0+4*3824*i, where i represents the i-th frame, i=0, 1, ...

[0121] S702: The first network device inserts an AIS maintenance frame at the egress port. The overhead area of ​​the AIS maintenance frame includes a framing identifier. The AIS maintenance frame is also sent according to the original frame header. Specifically, the insertion position of the framing identifier in the AIS maintenance frame can be determined based on the framing rules of the data frame stream received from the first transmission path. Alternatively, the insertion position of the framing identifier can be determined based on the frame period start sequence number of the data frame stream before the failure of the first transmission path occurred.

[0122] S703: The first network device sends the AIS maintenance frame to the downstream network device at the egress end. The first network device then executes S704-S706, see S602-S604, which will not be described in detail here.

[0123] In one possible implementation, the pipeline to which the data frame stream belongs has a state machine for recording the pipeline status. When the first network device detects a LOF alarm generated by the first transmission path at the ingress end, the pipeline status can be updated to an alarm indication state. The alarm indication state is used to indicate a fault (or an alarm) in the upstream direction of the first network device. The alarm indication state can also be referred to as an alarm state, a fault state, a dAIS state, or other terms, which are not specifically limited in this embodiment of the present application.

[0124] In one example, when the first network device detects at the ingress that a LOF alarm has been generated on the first transmission path, the first network device may update the status of the pipe at the egress to an alarm indication state. In another example, when the first network device detects at the ingress that a LOF alarm has been generated on the first transmission path, the first network device may update the status of the pipe at the ingress to an alarm indication state. In yet another example, when the first network device detects at the ingress that a LOF alarm has been generated on the first transmission path, the first network device may update the status of the pipes at both the ingress and egress to an alarm indication state. Of course, in some scenarios, if the ingress and egress of the first network device are on the same board, only one state machine may be configured, requiring only the state of that state machine to be modified. In other scenarios, if the ingress and egress are on different boards, the state of the state machines of each board may be modified. In some embodiments, the first network device may determine whether a data frame stream needs to be transparently transmitted based on the alarm indication state. That is, upon completing protection switching and receiving a data frame stream, the first network device may determine whether a data frame stream needs to be transparently transmitted based on the alarm indication state. It can also be described that the alarm indication state is used to instruct the first network device to transparently transmit the data frame flow received after the protection switching to the downstream network device.

[0125] In some examples, the duration of the alarm indication state can be configured to be greater than or equal to the execution duration of the reframe operation. Therefore, the data frame stream can be transparently transmitted to the downstream network device at the egress end before the alarm indication state is terminated. In other examples, the termination time of the alarm indication state is later than the completion time of the protection switching. In some implementation scenarios, the alarm indication state can be terminated after the reframe operation is completed. In one possible example, the termination time of the alarm indication state is later than or equal to the completion time of the reframe operation.

[0126] In some possible implementations, an SNCS group may be configured between the first network device and its upstream network device, and an SNCS group may also be configured between the first network device and its downstream network device. The overhead area of ​​the AIS maintenance frame sent by the first network device to the downstream network device then includes a PM segment overhead and a TCM segment overhead. The PM segment overhead indicates a fault on the first network device. The TCM segment overhead indicates that the fault has not extended downstream from the first network device. In other words, the downstream network device of the first network device is no longer aware of the fault due to the TCM segment overhead.

[0127] In one possible example, the TCM segment overhead of an AIS maintenance frame indicates that the fault has not extended downstream to the first network device, thereby instructing the downstream network device to perform non-intrusive monitoring of the PM segment overhead. However, if the PM segment overhead indicates a fault on the first network device, the downstream network device is prohibited from performing SNCS switching. If the PM segment overhead indicates a fault on the first network device, the downstream network device will no longer send invalid data frames downstream according to the previous framing rules during reframing, but will transparently transmit the received data frame stream.

[0128] Refer to FIG8 , which is a flowchart of another method for protection switching of an optical network provided by an embodiment of the present application. Take the second network device as an example where the downstream node having a fault is a second network device. The second network device has an inlet port and an outlet port. The inlet port is used to connect the second network device with the upstream network device of the second network device. The outlet port is used to connect the second network device with the downstream network device of the second network device.

[0129] S801: A second network device receives an AIS maintenance frame from an upstream network device of the second network device at an ingress end.

[0130] S802: The second network device sends the AIS maintenance frame to the downstream network device through the egress port.

[0131] S803: After a set time period has passed since the second network device received the AIS maintenance frame, the second network device receives a data frame stream from the upstream network device at the ingress end. The data frame stream may be a valid data frame stream used to carry service data.

[0132] The above S803 can be understood as when the data frame stream is received at the ingress end, that is, the network device that has failed in the upstream direction of the second network device has completed protection switching.

[0133] S804: The second network device performs a reframing operation on the data frame flow at the ingress end, and transparently transmits the data frame flow to a downstream network device of the second network device at the egress end before completing the reframing operation.

[0134] In one possible implementation, the pipe to which the data frame stream belongs has a state machine for recording the pipe's status. Upon receiving an AIS maintenance frame, the first network device may update the pipe's status to an alarm indication state. The alarm indication state indicates a fault (or an alarm) upstream of the second network device. In one example, upon receiving an AIS maintenance frame, the second network device may update the pipe's status at the egress end to an alarm indication state. In another example, upon receiving an AIS maintenance frame, the first network device may update the pipe's status at the ingress end to an alarm indication state. In yet another example, upon receiving an AIS maintenance frame, the first network device may update the pipe's status at both the ingress and egress ends to an alarm indication state. In some scenarios, if the ingress and egress ends of the first network device are on the same board, only one state machine may be configured, requiring only the state of that state machine to be modified. In other scenarios, if the ingress and egress ends are on different boards, the state of the state machines of each board may be modified.

[0135] In some examples, the duration of the alarm indication state can be configured to be greater than or equal to the execution duration of the reframe operation. Therefore, before the alarm indication state terminates, the data frame stream can be transparently transmitted to the downstream network device at the egress end, that is, during the execution of the reframe, the received data frame stream carrying business data can be transparently transmitted. In other examples, the termination time of the alarm indication state is later than the completion time of the protection switching. In some implementation scenarios, the alarm indication state can be terminated after the reframe operation is completed. In one possible example, the termination time of the alarm indication state is later than or equal to the completion time of the reframe operation.

[0136] The present application can be applied to an end-to-end networking mode. In the end-to-end networking, SNCP groups can be configured in full or in part. In one implementation scenario, no SNCP group is configured between the second network device and the upstream network device of the second network device.

[0137] In another implementation scenario, an SNCP group, such as an SNCS group, is also configured between the second network device and its upstream network device. The overhead area of ​​the AIS maintenance frame received by the second network device also includes a PM segment overhead and a TCM segment overhead; the PM segment overhead indicates that a fault exists upstream of the second network device; and the TCM segment overhead indicates that the fault does not extend to the second network device. Upon receiving the AIS maintenance frame, the second network device may non-intrusively monitor the AIS maintenance frame to transparently transmit the data frame stream at the egress to the downstream network device of the second network device if it determines that the PM segment overhead indicates that a fault exists upstream of the second network device.

[0138] In some possible scenarios, when the alarm indication state is adopted, the second network device can non-intrusively monitor the AIS maintenance frame when receiving the AIS maintenance frame, so as to update the pipeline state to the alarm indication state when it is determined that the PM segment overhead indicates that there is a fault in the upstream direction of the second network device.

[0139] This application can be applied to end-to-end networking. In an end-to-end network, SNCP groups can be fully configured (e.g., in a cascade protection switching scenario) or partially configured (e.g., in a non-cascade protection switching scenario). The following describes the solutions provided by the embodiments of this application in conjunction with these two scenarios.

[0140] FIG9A is a flow chart illustrating protection switching for an optical transport network according to an embodiment of the present application. FIG9A uses the non-cascaded segmented protection scenario described in FIG4A as an example, namely, an fgOTN with N1, N2, and N3 passing through. SNCP is configured on the N1 node, while SNCP is not configured on the N2 and N3 nodes. W_RX represents the working path of the receiving end, P_RX represents the protection path of the receiving end, and TX represents the transmitting end. The receiving end may also be referred to as the ingress end (in), and the transmitting end may also be referred to as the egress end (out).

[0141] S901: N1 detects a LOF alarm on W-RX at the ingress.

[0142] As shown in Figure 9B, in State 1, before a fault occurs, SNCP protection on N1 receives data frames from the working path W_RX and forwards them to node N2 at the egress port. Since nodes N2 and N3 are unprotected, they both receive data in the RX direction and transmit data in the TX direction. As shown in Figure 9B, the black bars indicate the data frame transmission from W_RX@N1 to N2 to N3.

[0143] State 2: The SNCP working path of node N1 fails, that is, there is no signal input on the W_RX path of node N1.

[0144] State 2.1, Window 1: After a W_RX failure occurs, node N1 detects the W_RX failure. During this period, N1's egress node maintains the original data frame header position (i.e., the original framing position) and continues to transmit. Due to the lack of signal input, the invalid data frame transmitted by N1's egress node maintains the pre-failure framing position (i.e., maintains the original framing identifier position, i.e., transmits the invalid data frame according to the framing start position of the data frame received from W_RX), and the payload area is filled with invalid information. At this point, downstream nodes N2 and N3 are unaware of any failure, as shown in Figure 9B.

[0145] At S902, N1 inserts an AIS maintenance frame at the egress end. The AIS maintenance frame is also sent according to the original frame header. That is, the insertion position of the framing identifier of the AIS maintenance frame can be determined based on the framing rules of the data frame stream received from the first transmission path. Alternatively, the insertion position of the framing identifier can be determined based on the frame period start sequence number of the data frame stream before the failure of the first transmission path occurs.

[0146] In state 2.2, window 2, from the time N1 senses the W_RX failure to the time N1 SNCP switchover completes, N1 has already sensed the W_RX failure and therefore inserts an AIS maintenance frame for the fgOTN channel at the egress. While N1's egress sends the AIS maintenance frame, the original framing identifier position is maintained.

[0147] S903 , N1 sends the AIS maintenance frame to N2 at the egress end, so that N2 receives the AIS maintenance frame from the ingress end.

[0148] In window 2, node N2 receives the AIS maintenance frame and thus senses the fault.

[0149] S904, N2 sends an AIS maintenance frame from the egress end to N3, so that N3 receives the AIS maintenance frame at the ingress end.

[0150] In window 2, node N3 receives the AIS maintenance frame and thus senses the fault.

[0151] S905 , N1 switches at the ingress end to receiving the data frame flow through the W_RX path.

[0152] State 3: SNCP switching of the N1 node is completed, and the P_RX->E2E service is restored.

[0153] S906 , N1 performs a reframing operation on the data frame flow at the ingress end, and transparently transmits the data frame flow to N2 at the egress end before completing the reframing operation at the ingress end.

[0154] State 3.1, Window 3: First, N1 receives data frames from N1.P_RX. During this time, N1.P_RX completes framing of the N1.P_RX signal. For example, after receiving two consecutive data frames, N1.RX updates from the LOF state to the OOF state and then continues to receive two consecutive data frames to complete the framing operation. Meanwhile, while N1 is performing the framing operation at the ingress, it transparently transmits each data frame in the data frame stream. During the framing operation at the ingress, N1 suppresses frame header regeneration. Specifically, it no longer maintains the original frame header to send AIS maintenance frames or invalid frames. Instead, it directly transmits the data frame stream received from P_RX to N2 according to the location identifier of the data frame stream received from P_RX. Until N1 completes reframing, it transparently transmits the frame header of the data frame stream received from P_RX. After reframing, it resumes framing according to the new frame header location rules and continues to transmit the data frame stream.

[0155] Optionally, as previously described, upon detecting a LOF alarm, N1 can update the pipe state to the dAIS state. Based on the dAIS state, N1 can suppress frame header regeneration. Specifically, N1 no longer sends AIS maintenance frames or invalid frames with the original frame header. Instead, it directly sends frames to N2 based on the location identifier of the data frame stream received from P_RX. For details, refer to the previous description of the dAIS state and will not be repeated here.

[0156] S907, N2 receives the data frame stream at the ingress end.

[0157] S908 , N2 performs a reframing operation on the data frame flow at the ingress end, and transparently transmits the data frame flow to N3 at the egress end before completing the reframing operation at the ingress end.

[0158] During window 3, N2 first receives a data frame stream from N1. N2 is unable to frame the data frame using the original header, so N2X enters the reframing state and N2 completes the data frame framing. Meanwhile, while N2 is performing the framing operation at the ingress, it transparently transmits each data frame in the data frame stream. During the framing operation at the ingress, N2 suppresses header regeneration, meaning it no longer maintains the original header and sends AIS maintenance frames or invalid frames. Instead, it directly sends the received data frame stream's positioning identifier to N3. Until N2 completes the reframing, it transparently transmits the received data frame stream's header. After the reframing is complete, it continues framing according to the new header positioning rules and continues sending the data frame stream.

[0159] Optionally, as previously described, upon detecting a LOF alarm, N2 can update the pipe state to the dAIS state. Based on the dAIS state, N2 can suppress frame header regeneration. Specifically, N2 no longer sends AIS maintenance frames or invalid frames with the original frame header. Instead, it directly sends the received data frame stream to N3 based on the location identifier of the received data frame stream. For details, refer to the previous description of the dAIS state and will not be repeated here.

[0160] State 3.2, Window 4: After N2 completes the framing operation, it continues to frame according to the positioning rules of the new frame header and continues to send the data frame stream.

[0161] S909, N3 receives the data frame stream at the ingress end.

[0162] S910, N3 performs a reframing operation on the data frame flow at the ingress end, and transparently transmits the data frame flow at the egress end before completing the reframing operation at the ingress end.

[0163] During window 3, N3 first receives a data frame stream from N1. N3 is unable to frame the data frame using the original frame header, so N3X enters the reframing state and completes the data frame framing. Meanwhile, while N3 is performing the framing operation at the ingress, each data frame in the data frame stream is transparently transmitted. During the framing operation at the ingress, N3 suppresses frame header regeneration, meaning it no longer maintains the original frame header and sends AIS maintenance frames or invalid frames. Instead, it directly sends the received data frame stream's positioning identifier to N3. Until N3 completes the reframing, it transparently transmits the frame header of the received data frame stream. After the reframing is complete, framing continues according to the positioning rules of the new frame header and continues to send the data frame stream.

[0164] Optionally, as previously described, upon detecting a LOF alarm, N3 can update the pipe state to the dAIS state. Based on the dAIS state, N3 can suppress frame header regeneration. Specifically, N3 no longer sends AIS maintenance frames or invalid frames with the original frame headers. Instead, it directly sends the received data frame stream to N3 based on the location identifier of the data frame stream. For details, refer to the previous description of the dAIS state and will not be repeated here.

[0165] During window 4, after N2 completes the framing operation, N3 continues to perform framing according to the positioning rule of the new frame header and continues to send the data frame stream.

[0166] As described above, N1, N2, and N3 regenerate the frame header during the reframing period, transparently transmitting the new frame header received by N1.P_RX while reframing. At this point, the switching performance is independent of the number of hops, that is, all nodes enter the reframing state simultaneously, which can ensure the E2E fgOTN protection switching performance.

[0167] FIG10A shows a schematic diagram of a protection switching process for an optical transport network according to an embodiment of the present application. FIG10A uses the cascaded segmented protection scenario described in FIG5A as an example, namely, an fgOTN network with nodes N1, N2, and N3 passing through. SNCS groups are configured on nodes N1, N2, and N3. W_RX represents the working path of the receiving end, P_RX represents the protection path of the receiving end, and TX represents the transmitting end. The receiving end can also be called the ingress end (in), and the transmitting end can also be called the egress end (out).

[0168] S1001: N1 detects a LOF alarm on W-RX at the ingress.

[0169] As shown in FIG10B , state 1: before a fault occurs, the SNCS protection of N1 receives data frames from the working path W_RX and forwards them to nodes N2 and N3 from the egress end.

[0170] As shown in FIG10B , the black bar indicates that the service data is transferred from N1.W_RX->N1.TX->N2.W_RX->N2.TX->N3.W_RX->N3.TX.

[0171] State 2: The SNCS working path on node N1 fails, and N1's W_RX path loses signal input. This failure eventually triggers N1's SNCS protection to switch to receiving signals from P_RX. However, within the time window before N1's protection switch occurs, the W_RX fails. N1 detects the W_RX failure, initiates SNCS switching, and completes the SNCS switchover, receiving data frames from P_RX.

[0172] State 2.1, Window 1: From the time W_RX fails until N1 detects the failure, N1's egress node continues to transmit with the original frame header. Due to the lack of input signal, N1.TX maintains the pre-failure frame header position, while the payload area is filled with invalid information. This means that N1's egress node transmits an invalid data frame. At this point, downstream nodes N2 and N3 are unaware of the failure, as shown in Figure 10B.

[0173] S1002, N1 inserts an AIS maintenance frame at the egress end. The AIS maintenance frame is also sent according to the original frame header, that is, the insertion position of the framing identifier of the AIS maintenance frame can be determined according to the framing rule of the data frame stream received from the first transmission path, or it can be described as the insertion position of the framing identifier being determined according to the frame period start sequence number of the data frame stream before the failure of the first transmission path. The overhead area of ​​the AIS maintenance frame also includes PM segment overhead and TCM segment overhead. The PM segment overhead indicates that there is a fault on N1. The TCM segment overhead indicates that the fault does not extend to the downstream direction of N1, that is, N2 and N3 can no longer sense the fault through the TCM segment overhead.

[0174] In state 2.2, window 2, from the time N1 senses the W_RX fault until the time N1's SNCP switchover completes, N1 has already sensed the W_RX fault and therefore inserts an AIS maintenance frame for the fgOTN channel downstream of N1.TX. While N1.TX is sending the AIS maintenance frame, the original frame header (including the original framing identifier) ​​is retained. Because the scenario is SNCS protection, TCM overhead regeneration occurs. That is, the TCM segment overhead indicates that the fault has not continued downstream of N1. Therefore, N2 and N3 are unaware of any fault at this time.

[0175] S1003 , N1 sends the AIS maintenance frame to N2 at the egress end, so that N2 receives the AIS maintenance frame from the ingress end.

[0176] In window 2, node N2 receives the AIS maintenance frame and does not detect a fault based on the TCM segment overhead.

[0177] S1004: N2 performs non-intrusive monitoring of the PM segment overhead.

[0178] S1005 , N2 sends an AIS maintenance frame from the egress end to N3 , so that N3 receives the AIS maintenance frame at the ingress end.

[0179] In window 2, node N3 receives the AIS maintenance frame and does not detect a fault based on the TCM segment overhead.

[0180] S1006: N3 performs non-intrusive monitoring of the PM segment overhead.

[0181] S1007 , N1 switches at the ingress end to receiving the data frame flow through the W_RX path.

[0182] State 3: SNCP switching of the N1 node is completed, and the P_RX->E2E service is restored.

[0183] S1008 , N1 performs a reframing operation on the data frame flow at the ingress end, and transparently transmits the data frame flow to N2 at the egress end before completing the reframing operation at the ingress end.

[0184] State 3.1, Window 3: First, N1 receives data frames from N1.P_RX. During this time, N1.P_RX completes framing of the N1.P_RX signal. For example, after receiving two consecutive data frames, N1.RX updates from the LOF state to the OOF state and then continues to receive two consecutive data frames to complete the framing operation. Meanwhile, while N1 is performing the framing operation at the ingress, it transparently transmits each data frame in the data frame stream. During the framing operation at the ingress, N1 suppresses frame header regeneration. Specifically, it no longer maintains the original frame header to send AIS maintenance frames or invalid frames. Instead, it directly transmits the data frame stream received from P_RX to N2 according to the location identifier of the data frame stream received from P_RX. Until N1 completes reframing, it transparently transmits the frame header of the data frame stream received from P_RX. After reframing, it resumes framing according to the new frame header location rules and continues to transmit the data frame stream.

[0185] Optionally, as previously described, upon detecting a LOF alarm, N1 can update the pipe state to the dAIS state. Based on the dAIS state, N1 can suppress frame header regeneration. Specifically, N1 no longer sends AIS maintenance frames or invalid frames with the original frame header. Instead, it directly sends the data frame stream received from P_RX to N2 based on the location of the location identifier. For details, refer to the previous description of the dAIS state and will not be repeated here.

[0186] S1009, N2 receives the data frame stream at the ingress end.

[0187] S1010, N2 performs a reframing operation on the data frame flow at the ingress end, and when it monitors that the PM segment overhead indicates that there is a fault in the upstream direction of N2, it transparently transmits the data frame flow to N3 at the egress end before completing the reframing operation at the ingress end.

[0188] During window 3, N2 first receives a data frame stream from N1. N2 is unable to frame with the original frame header, so N2X enters the reframing state and N2 needs to complete the framing of the data frame. At the same time, when it is monitored that the PM segment overhead indicates that there is a fault in the upstream direction of N2, each data frame in the data frame stream is transparently transmitted during the framing operation performed at the inlet end of N2. During the framing operation performed at the inlet end, N2 suppresses the regeneration of the frame header, that is, it no longer continues to maintain the original frame header to send AIS maintenance frames or invalid frames. Instead, it is sent directly to N3 according to the position of the positioning identifier of the received data frame stream. Before N2 completes the reframing, the frame header of the received data frame stream is transparently transmitted. After the reframing is completed, the framing continues according to the positioning rule of the new frame header and the data frame stream continues to be sent.

[0189] Optionally, as previously described, upon detecting a LOF alarm, N2 can update the pipe state to the dAIS state. Based on the dAIS state, N2 can suppress frame header regeneration. Specifically, N2 no longer sends AIS maintenance frames or invalid frames with the original frame header. Instead, it directly sends the received data frame stream to N3 based on the location identifier of the received data frame stream. For details, refer to the previous description of the dAIS state and will not be repeated here.

[0190] State 3.2, Window 4: After N2 completes the framing operation, it continues to frame according to the positioning rules of the new frame header and continues to send the data frame stream.

[0191] S1011, N3 receives a data frame stream at the ingress end.

[0192] S1012, N3 performs a reframe operation on the data frame flow at the ingress end, and monitors that the PM segment overhead indicates that there is a fault in the upstream direction of N3, so as to transparently transmit the data frame flow at the egress end before completing the reframe operation at the ingress end.

[0193] During window 3, N3 first receives a data frame stream from N1. N3 is unable to frame with the original frame header, so N3X enters the reframing state and N3 needs to complete the framing of the data frame. At the same time, when it is monitored that the PM segment overhead indicates that there is a fault in the upstream direction of N3, each data frame in the data frame stream is transparently transmitted during the framing operation performed at the inlet end of N3. During the framing operation performed at the inlet end, N3 suppresses the regeneration of the frame header, that is, it no longer continues to maintain the original frame header to send AIS maintenance frames or invalid frames. Instead, it is sent directly to N3 according to the position of the positioning identifier of the received data frame stream. Before N3 completes the reframing, the frame header of the received data frame stream is transparently transmitted. After the reframing is completed, the framing continues according to the positioning rule of the new frame header, and the data frame stream continues to be sent.

[0194] Optionally, as previously described, upon detecting a LOF alarm, N3 can update the pipe state to the dAIS state. Based on the dAIS state, N3 can suppress frame header regeneration. Specifically, N3 no longer sends AIS maintenance frames or invalid frames with the original frame headers. Instead, it directly sends the received data frame stream to N3 based on the location identifier of the data frame stream. For details, refer to the previous description of the dAIS state and will not be repeated here.

[0195] During window 4, after N2 completes the framing operation, N3 continues to perform framing according to the positioning rule of the new frame header and continues to send the data frame stream.

[0196] As described above, in the SNCS scenario, TCM overhead is regenerated segment by segment. However, each node performs non-intrusive monitoring of the fgOTN PM layer. If an upstream fault is detected, frame header regeneration is suppressed, and the new N1.P_RX frame header is transparently transmitted while reframing. In this way, switching performance is independent of the number of hops. That is, all nodes enter the reframing state simultaneously, ensuring E2E fgOTN protection.

[0197] Based on the same inventive concept as the above-mentioned embodiment, the present application also provides an apparatus for protection switching in an optical transport network. The method, apparatus, and system are based on the same inventive concept. Since the method, apparatus, and system solve similar problems, the implementation of the apparatus and method can refer to each other, and any repetitions will not be repeated.

[0198] The device can be used in a network device (such as a first network device or N1). The device can specifically be a processor, a chip, a chip system, or a module in a processor for performing network device functions. The device can be implemented by the circuit board in Figure 2. Figure 11 is a structural schematic diagram of a possible device for protection switching of an optical transport network in an embodiment of the present application. As shown in Figure 11, the device includes a detection unit 1101 and a processing unit 1102. Optionally, the device also includes a sending unit 1103.

[0199] In one example, the apparatus is applied to a first network device, wherein the detection unit 1101 is configured to execute S601, the processing unit 1102 is configured to execute S602 and S603, and the sending unit 1103 is configured to execute S604 to send a data frame stream. In another example, the detection unit 1101 is configured to execute S701, the processing unit 1102 is configured to execute S702, S704, and S705, and the sending unit 1103 is configured to execute S703 and S706.

[0200] Optionally, the above three units may also execute other relevant optional steps executed by the first network device or N1 mentioned in any of the above embodiments, which will not be repeated here.

[0201] The device can be used in a network device (such as a second network device or N2 or N3), and the device can specifically be a processor, a chip, a chip system, or a module in a processor for executing network device functions, etc. The device can be implemented by the circuit board in Figure 2. Figure 12 is a structural diagram of a possible device for protection switching of an optical transport network in an embodiment of the present application. As shown in Figure 12, the device includes a receiving unit 1201 and a processing unit 1202. Optionally, the device also includes a sending unit 1203. The receiving unit 1201 is used to execute S801 and S803. The processing unit 1202 is used to execute the reframe operation in S804, and the sending unit 1203 is used to execute the transparent transmission operation in S804.

[0202] Optionally, the above three units may also execute other relevant optional steps executed by the second network device or N2 or N3 mentioned in any of the above embodiments, which will not be repeated here.

[0203] The division of units in the embodiments of the present application is illustrative and is only a logical functional division. In actual implementation, other division methods may be used. In addition, the functional units in the various embodiments of the present application can be integrated into a processor, or can exist physically separately, or two or more units can be integrated into a single unit. The above-mentioned integrated units can be implemented in the form of hardware or software functional units.

[0204] It can be understood that the above-mentioned device provided in the embodiment of the present application can implement all the method steps implemented by the corresponding equipment in the above-mentioned method embodiment, and can achieve the same technical effect. The parts and beneficial effects of this embodiment that are the same as those in the method embodiment will not be described in detail here.

[0205] Based on the same technical concept, embodiments of the present application also provide a device. This device can implement the functions implemented by the network device in the above embodiments. The device may include a processor and an optical transceiver. The optical transceiver is configured to transmit and receive data frame streams or AIS maintenance frames. The processor is configured to process the transmitted and received data frame streams or AIS maintenance frames.

[0206] Based on the same technical concept, an embodiment of the present application also provides a device that can implement the functions implemented by the relevant devices in the above embodiments. As shown in Figure 13, the device 1300 may include a transceiver 1301, a memory 1303 and a processor 1302. The transceiver 1301, the memory 1303 and the processor 1302 can be connected via a bus 1304. The transceiver 1301 can be used for device communication, such as for sending or receiving signals. The memory 1303 is coupled to the processor 1302 and can be used to store the programs and data necessary for the device 1300 to implement various functions. The above memory 1303 and processor 1302 can be integrated into one or independent of each other.

[0207] For example, the transceiver 1301 may be a communication port, such as a communication port (or interface) used for communication between network elements. The transceiver 1301 may also be referred to as a transceiver unit or a communication unit. The processor 1302 may be implemented as a processing chip or a processing circuit. The transceiver 1301 may receive or transmit information wirelessly or wiredly.

[0208] In addition, according to the needs of actual use, the device provided in the embodiment of the present application may include a processor, and the processor calls an external transceiver and / or memory to implement the above-mentioned functions or steps or operations. The device provided in the embodiment of the present application may also include a memory, and the processor calls and executes the program stored in the memory to implement the above-mentioned functions or steps or operations. Alternatively, the device provided in the embodiment of the present application may also include a processor and a transceiver (or communication interface), and the processor calls and executes the program stored in the external memory to implement the above-mentioned functions or steps or operations. Alternatively, the device provided in the embodiment of the present application may also include a processor, a memory, and a transceiver.

[0209] Based on the same concept as the above-mentioned method embodiment, an embodiment of the present application also provides a computer-readable storage medium on which program instructions (or computer programs, instructions) are stored. When the program instructions are executed by the processor, the computer executes the operations performed by the network device in the above-mentioned method embodiment or any possible implementation of the method embodiment.

[0210] Based on the same concept as the above-mentioned method embodiment, the present application also provides a computer program product, including program instructions. When the computer program product is called and executed by a computer, it can enable the computer to implement the operations performed by the network device in the above-mentioned method embodiment and any possible implementation method of the method embodiment.

[0211] Based on the same concept as the above method embodiment, this application also provides a chip or chip system, which is coupled to a transceiver and is used to implement the operations performed by the network device in the above method embodiment or any possible implementation of the method embodiment. The chip system may include the chip, as well as components such as memory and a communication interface.

[0212] Based on the same concept as the above method embodiment, an embodiment of the present application further provides a communication system. The communication system includes multiple network devices, such as a first network device and a second network device. Another example includes N1, N2, and N3. The network devices can execute the methods shown in Figures 6, 7, and 8.

[0213] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0214] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each flow and / or box in the flow chart and / or block diagram, as well as the combination of the flow chart and / or box in the flow chart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more flow charts and / or one or more boxes in the block diagram.

[0215] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0216] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0217] Obviously, those skilled in the art may make various modifications and variations to this application without departing from the scope of protection of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A protection switching method for an optical transport network, characterized in that: include: The first network device detects a fault in the first transmission path at an ingress end; the ingress end is used to connect the first network device with an upstream network device of the first network device; The first network device switches at an ingress end to receive a data frame stream from the upstream network device through a second transmission path; The first network device performs a reframe operation on the data frame stream at the inlet end; before completing the reframe operation at the inlet end, the first network device transparently transmits the data frame stream to the downstream network device of the first network device at the outlet end, and the outlet end is used to connect the first network device and the downstream network device.

2. The method according to claim 1, wherein The first network device detects a fault on the first transmission path at an ingress end, including: The first network device detects at an ingress end that a frame loss LOF alarm occurs on the first transmission path.

3. The method according to claim 2, wherein The first network device switches at an ingress end to receive the data frame stream from the upstream network device through the second transmission path, and the method further includes: When the first network device detects at the ingress end that a LOF alarm is generated on the first transmission path, the first network device inserts an alarm indication signal AIS maintenance frame at the egress end, wherein the overhead area of ​​the AIS maintenance frame includes a framing identifier, and the insertion position of the framing identifier is determined according to the frame header position of the data frame flow before the failure of the first transmission path occurs; The first network device sends the AIS maintenance frame to the downstream network device at the egress end.

4. The method according to claim 3, wherein The method further comprises: When the first network device detects that a LOF alarm is generated on the first transmission path at the ingress end, the first network device updates the state of the pipeline to which the data frame flow belongs to an alarm indication state, where the alarm indication state is used to indicate that a fault exists in the upstream direction of the first network device; Transparently transmitting the data frame flow to the downstream network device at the egress end includes: Before the alarm indication state is terminated, transparently transmitting the data frame stream to the downstream network device at the egress end; The duration of the alarm indication state is greater than or equal to the execution duration of the reframing operation.

5. The method according to claim 3 or 4, wherein: A subnetwork connection protection (SNCS) group for sublayer monitoring is configured between the first network device and a downstream network device of the first network device, the overhead area of ​​the AIS maintenance frame further includes a path monitoring (PM) segment overhead and a tandem connection monitoring (TCM) segment overhead, and the PM segment overhead indicates that a fault exists on the first network device; Before the first network device sends the AIS maintenance frame to the downstream network device at the egress end, the method further includes: The first network device modifies the TCM segment overhead of the AIS maintenance frame at the egress end; the modified TCM segment overhead of the AIS maintenance frame indicates that the fault has not continued to the downstream direction of the first network device, and is used to instruct the downstream network device to perform non-intrusive monitoring of the PM segment overhead, but prohibits SNCS switching when the PM segment overhead is monitored to indicate that a fault exists on the first network device.

6. The method according to any one of claims 1 to 5, wherein: The data frames in the data frame flow are fine-grained optical transport network fgOTN frames.

7. A protection switching method for an optical transport network, characterized in that: include: The second network device receives an AIS maintenance frame from an upstream network device of the second network device at an inlet end, and sends the AIS maintenance frame to a downstream network device through an outlet end; the inlet end is used to connect the second network device with the upstream network device; the outlet end is used to connect the second network device with the downstream network device; The second network device receives the data frame stream from the upstream network device at the inlet end after a set time period has passed since the AIS maintenance frame was received; The second network device performs a reframing operation on the data frame flow at the ingress end, and transparently transmits the data frame flow to a downstream network device of the second network device at the egress end before completing the reframing operation.

8. The method according to claim 7, wherein The method further comprises: When the second network device receives the AIS maintenance frame, it updates the state of the pipe to which the data frame flow belongs to an alarm indication state, where the alarm indication state is used to indicate that a fault exists in the upstream direction of the second network device; Transparently transmitting the data frame flow to the downstream network device at the egress end includes: Before the alarm indication state is terminated, transparently transmitting the data frame stream to the downstream network device at the egress end; The duration of the alarm indication state is greater than or equal to the execution duration of the reframing operation.

9. The method according to claim 8, wherein No subnet connection protection (SNCP) group is configured between the second network device and an upstream network device of the second network device.

10. The method according to claim 7 or 8, characterized in that A subnetwork connection protection (SNCS) group with sublayer monitoring is configured between the second network device and an upstream network device of the second network device. The overhead area of ​​the AIS maintenance frame further includes a path monitoring (PM) segment overhead and a tandem connection monitoring (TCM) segment overhead. The PM segment overhead indicates that a fault exists in the upstream direction of the second network device. The TCM segment overhead indicates that the fault does not extend to the second network device. After the second network device receives the AIS maintenance frame, and before transparently transmitting the data frame stream to the downstream network device at the egress end, the method further includes: The AIS maintenance frame is non-intrusively monitored, and it is determined that the PM segment overhead indicates a fault in an upstream direction of the second network device.

11. The method according to any one of claims 7 to 10, wherein: The data frames in the data frame flow are fine-grained optical transport network fgOTN frames.

12. A protection switching device for an optical transport network, characterized in that: comprising a processor and a memory, wherein: The memory is used to store program code; The processor is configured to read and execute the program code stored in the memory to implement the method according to any one of claims 1 to 11.

13. A chip, characterized in that: The chip is connected to a memory and is used to read and execute program codes stored in the memory to implement the method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a software program, which implements the method according to any one of claims 1 to 11 when read and executed by one or more processors.

15. A computer program product comprising instructions, characterized in that: When the method is executed on a computer, the computer is enabled to execute the method according to any one of claims 1 to 11.

Images