Fault propagation in segmented protection

Abstract

The disclosure provides an interconnecting node for interconnecting first and second protected domains, the second protected domain comprising a working path and a protection path for linear protection in a network for traffic forwarding between two end-nodes. The interconnecting node comprises at least one interface for receiving first monitoring information from the first protected domain, a monitoring unit for detecting an isolation condition of the interconnecting node within the first protected domain based on the first monitoring information, and generating second monitoring information to be transmitted to the working path so that a failure in the working path is detectable based on the second monitoring information at a far-end node of the working path. If an isolation condition is detected, the monitoring unit starts transmitting alarm indication information to the working path for suppressing at the far-end node an alarm reporting regarding a failure in the working path.

Claims

1. Interconnecting node for interconnecting a first protected domain and a second protected domain, the second protected domain comprising a working path and a protection path for linear protection in a network for traffic forwarding between two end-nodes, wherein the first or second protected domain represents a protected portion of an end-to-end connection, and wherein the interconnecting node comprises a processor and a memory, the memory is configured to store a program, and the processor invokes the program in the memory and is configured to: receive a first monitoring information from the first protected domain, and detect an isolation condition of the interconnecting node within the first protected domain based on the first monitoring information, and generate a second monitoring information, and transmit the second monitoring information over the working path of the second protected domain so that a failure in the working path is detectable based on the second monitoring information at a far-end node of the working path, and start a transmission of alarm indication information (AIS) over the working path of the second protected domain for suppressing at the far-end node an alarm reporting regarding a failure in the working path of the second protected domain, when the isolation condition of the interconnecting node within the first protected domain is detected.

2. The interconnecting node according to claim 1, wherein the processor is further configured to: prevent the transmission of the second monitoring information to the working path of the second protected domain when the isolation condition of the interconnecting node within the first protected domain is detected.

3. The interconnecting node according to claim 1, wherein, the first protected domain comprises a given working path and a given protection path for linear protection; and the processor is configured to: detect that the interconnecting node is isolated within the first protected domain if a failure in the given working path and a failure of a vertical path are detected, the vertical path connecting the interconnecting node with a second interconnecting node in the first protected domain.

4. The interconnecting node according to claim 2, wherein, the first protected domain comprises a given working path and a given protection path for linear protection; and the processor is configured to: detect that the interconnecting node is isolated within the first protected domain if a failure in the given working path and a failure of a vertical path are detected, the vertical path connecting the interconnecting node with a second interconnecting node in the first protected domain.

5. The interconnecting node according to claim 1, wherein the far-end node of the second working path is one of the two end-nodes.

6. The interconnecting node according to claim 1, wherein, the processor is further configured to: when an isolation condition of the interconnecting node within the first protected domain is detected, generate and start a transmission of modified second monitoring information to the working path of the second protected domain, said modified second monitoring information indicating that a detected failure on the working path is caused by fault propagation of a failure in the first protected domain.

7. The interconnecting node according to claim 2, wherein, the processor is further configured to: when an isolation condition of the interconnecting node within the first protected domain is detected, generate and start a transmission of modified second monitoring information to the working path of the second protected domain, said modified second monitoring information indicating that a detected failure on the working path is caused by fault propagation of a failure in the first protected domain.

8. The interconnecting node according to claim 6, wherein, the processor is further configured to: when the isolation condition of the interconnecting node within the first protected domain is detected, concurrently start the transmission of the modified second monitoring information to the working path of the second protected domain, and start the transmission of AIS to the working path of the second protected domain.

9. The interconnecting node according to claim 1, wherein the far-end node of the second working path is connected to a further protected domain used for traffic forwarding between the two end-nodes.

10. The interconnecting node according to claim 6, wherein the processor is further configured to: receive modified first monitoring information from the first protected domain, and distinguish between a reception of the first monitoring information and of the modified first monitoring information, and detect that a failure is located in a further working path interconnected with the first protected domain, when the modified first monitoring information is received.

11. The interconnecting node according to claim 1, wherein the network is a packet network, preferably an Ethernet network or a network based on Multi-Protocol Label Switching Transport Profile (MPLS-TP), the first monitoring information and second monitoring information is respectively transmitted by means of Continuity Check Message (CCM) Operations, Administration and Maintenance (OAM) packets, and the alarm indication information, is transmitted as an Alarm Indication Signal (AIS) OAM packet.

12. The interconnecting node according to claim 2, wherein the network is a packet network, preferably an Ethernet network or a network based on Multi-Protocol Label Switching Transport Profile (MPLS-TP) the first monitoring information and second monitoring information are respectively transmitted by means of Continuity Check Message (CCM) Operations, Administration and Maintenance (OAM) packets, and the alarm indication information, is transmitted as an Alarm Indication Signal (AIS) OAM packet.

13. The interconnecting node according to claim 1, wherein the network is a Time-Division Multiplexing (TDM) network, preferably Optical Transport Network (OTN) or Synchronous Digital Hierarchy (SDH) and the first monitoring information, the second monitoring information and the alarm indication information are respectively transmitted by means of specific bytes in an overhead of a TDM frame.

14. The interconnecting node according to claim 2, wherein the network is a Time-Division Multiplexing (TDM) network, preferably Optical Transport Network (OTN) or Synchronous Digital Hierarchy (SDH) and the first monitoring information, the second monitoring information and the alarm indication information are respectively transmitted by means of specific bytes in an overhead of a TDM frame.

15. Method for interconnecting via an interconnecting node, a first protected domain and a second protected domain, the first or second protected domain representing a protected portion of an end-to-end connection, and the second protected domain comprising a working path and a protection path for linear protection in a network for traffic forwarding between two end-nodes, wherein the method comprises: receiving a first monitoring information from the first protected domain; and detecting an isolation condition of the interconnecting node within the first protected domain based on the first monitoring information, and generating a second monitoring information, wherein transmitting the second monitoring information to the working path of the second protected domain, so that a failure in the working path is detectable based on the second monitoring information at a far-end node of the working path, and starting a transmission of alarm indication information to the working path of the second protected domain for suppressing at the far-end node an alarm reporting regarding a failure in the working path of the second protected domain, when the isolation condition of the interconnecting node within the first protected domain is detected.

16. Computer program having a non-transitory program code for performing the method according to claim 15, wherein the computer program runs on a computing device.

17. The method according to claim 15, wherein the method further comprises: stopping the transmission of the second monitoring information over the working path of the second protected domain and starting the transmission of AIS over the working path, when the isolation condition of the interconnecting node within the first protected domain is detected.

Description

BRIEF DESCRIPTION OF DRAWINGS

(1) The above aspects and implementation forms of the present disclosure will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which:

(2) FIG. 1 shows a system according to a first embodiment of the present disclosure.

(3) FIG. 2 shows a first scenario of the system according to the first embodiment of the present disclosure.

(4) FIG. 3 shows a second scenario of the system according to the first embodiment of the present disclosure.

(5) FIG. 4 shows an interconnecting node according to an embodiment of the present disclosure.

(6) FIG. 5 shows a monitoring unit of an interconnecting node according to an embodiment of the present disclosure.

(7) FIG. 6 shows a state machine for transmitting the second monitoring information by an interconnecting node according to an embodiment of the present disclosure.

(8) FIG. 7 shows a possible implementation of a protocol data unit (PDU) of the modified second monitoring information according to an embodiment of the present disclosure.

(9) FIG. 8 shows a state machine for transmitting the alarm indication information by an interconnecting node according to an embodiment of the present disclosure.

(10) FIG. 9 shows a first scenario of a system according to a second embodiment of the present disclosure.

(11) FIG. 10 shows a second scenario of a system according to the second embodiment of the present disclosure.

(12) FIG. 11 shows a system with a protected domain according to the state of the art.

(13) FIG. 12 shows a system with cascaded protected domains according to the state of the art.

(14) FIG. 13 shows a system with Dual Node Interconnection (DNI) according to the state of the art.

DESCRIPTION OF EMBODIMENTS

(15) FIG. 1 shows a system 100 according to a first embodiment of the present disclosure.

(16) Particularly, FIG. 1 shows an interconnecting node N1 for interconnecting a first protected domain 111 and a second protected domain 121. The second protected domain 121 comprises a working path 122 and a protection path 123 for linear protection in a network for traffic forwarding between two end-nodes. In this configuration, the end nodes E and W between which the interconnecting node N1 is interposed are far-end nodes for N1 in the first and second protected domain respectively. In other configurations including more than two protected domains, the far-end nodes may also be interconnecting nodes as will be described in more detail in the following with reference to FIGS. 9 and 10. An end node is a node located at the extremity of the domain of interest, where segmented protection is implemented. The end node may have the same features of an interconnecting node or may be a different structure depending on the node and network configuration.

(17) The interconnecting node N1 comprises at least one interface 401, 402 shown in FIG. 4 adapted to receive first monitoring information from the first protected domain 111.

(18) The interconnecting node N1 comprises a monitoring unit 405 shown in FIG. 4 adapted to detect an isolation condition of the interconnecting node N1 within the first protected domain 111 based on the first monitoring information, and to generate second monitoring information.

(19) The interface 401, 402 of the interconnecting node N1 is adapted to transmit the second monitoring information to the working path 122 of the second protected domain 121 so that a failure in the working path 122 is detectable based on the second monitoring information at a far-end node W of the working path 122.

(20) When an isolation condition of the interconnecting node N1 within the first protected domain 111 is detected, the monitoring unit 405 is adapted to concurrently prevent the transmission of the second monitoring information and to start a transmission of alarm indication information (AIS) to the working path 122 of the second protected domain 121 for suppressing at the far-end node W an alarm reporting regarding a failure in the working path 122 of the second protected domain 121.

(21) Particularly, the first protected domain 111 shown in FIG. 1 may comprise a first working path 112 and a first protection path 113 for linear protection. Alternatively, the first protected domain may not use linear protection and thus have a different structure. The inventive interconnecting node can be connected to a first domain having any kind of protection known in the art. According to the different protection, such as for instance a ring protection, implemented in the first domain the interconnecting node will use a corresponding protocol to communicate with the end node of the first domain.

(22) Particularly, the network may be a packet network, advantageously an Ethernet network or a network based on Multi-Protocol Label Switching-Transport Profile (MPLS-TP). The first monitoring information and second monitoring information may then be respectively transmitted by means of CCM OAM packet(s). The alarm indication information (AIS) may be transmitted as AIS OAM packet(s).

(23) Particularly, the first protected domain 111 and the second protected domain 121 are interconnected by means of a pair 101 of nodes comprising the interconnecting node N1 and a second interconnecting node N2. Particularly, the interconnecting node N1 and a second interconnecting node N2 are connected by means of at least a vertical path. The second interconnecting node in this embodiment may also be indicated as peer interconnecting node. In the embodiment of FIG. 1, they are connected by means of a first vertical path 114 and a second vertical path 124. The interconnecting node N1 comprises an end node 102 of the working path 112 of the first protected domain 111, and an end node 103 of the working path 122 of the second protected domain 121, while the second interconnecting node N2 comprises an end node 107 of the protection path 113 of the first protected domain 111, and an end node 108 of the protection path 123 of the second protected domain 121. The first vertical path 114 connects the respective end nodes 102 and 107 of the first protected domain 111, while the second vertical path 124 connects the respective end nodes 103 and 108 of the second protected domain 121.

(24) FIG. 2 shows a first failure scenario of the system according to the first embodiment of the present disclosure.

(25) In a step S201 according to the disclosure, the interconnecting node N1, i.e. its monitoring unit 405, is adapted to detect an isolation condition of the interconnecting node N1 within the first protected domain 111 based on the first monitoring information.

(26) In a step S202, when an isolation condition of the interconnecting node N1 within the first protected domain 111 is detected, the interconnecting node N1, i.e. its monitoring unit 405, is adapted to concurrently induce a detection of a failure by the far-end node of the second protected domain, which in this embodiment corresponds to the end node W, and inhibit the triggering of an alarm. In an Ethernet network for instance this can be achieved by preventing the transmission of the second monitoring information and to start a transmission of alarm indication information to the working path 122 of the second protected domain 121.

(27) In case of a different network environment, such as an OTN network, the above can be achieved by replacing the monitoring information by an alarm indication information. Specifically, the alarm indication information may be transmitted to the far-end node in the overhead of an OTN frame in the place of the monitoring information used for indicating to the far-end node that a failure occurred. In this case, reception by the far-end node of the modified OTN frame including the alarm indication information will be interpreted as an indication of a failure in the first protected domain and concurrent request of suppression of an alarm reporting.

(28) The stop of transmission of monitoring information and concurrent transmission of alarm indication information with reference to the implementation described herein has to be intended both (1) stopping transmission of the CCM or similar frames and concurrent transmission of alarm indication information (in packet networks) and (2) replacement of monitoring information in an OTN or similar frame with alarm indication information in case of OTN or similar networks.

(29) In a step S203, the far-end node W of the second protected domain 121 detects a defect, as if the second working path was failed, due to the not reception of the second monitoring information, and suppresses, as a response to the reception of the alarm indication information, an alarm reporting regarding a failure in the working path 122 of the second protected domain 121.

(30) Particularly, FIG. 2 shows an example of the implementation of the disclosure as an Ethernet network where both the first and the second domains are linear protected, for example the first and second domain are SNC/S protected. Accordingly, segmented protection is deployed for interconnecting the two SNC/S protected domains 111, 121. In this case, when the interconnecting node N1 detects to be isolated within the protected domain 111, it should trigger protection switching at the far-end node W of protected domain 121. In such a configuration, a failure is detected by the interconnecting node N1 when the interconnecting node N1 detects a dLOC defect on the working line in the first protected domain. Clearly in case of a different protection scheme for the first protected domain, the failure in the first protected domain will be detected according to a different protocol. Implementation of failure detection in a nonlinear protected domain will not be discussed in the following, but it will be clear that the disclosure is not limited to a configuration in which the first domain is linearly protected.

(31) For simplicity purposes, this embodiment assumes that the horizontal paths between the protected domains 111, 121 within the two interconnected node N1, N2, i.e. the horizontal path between nodes 102 and 103 and the horizontal path between nodes 107 and 108, are always active paths when faults are detected on the vertical paths 114, 124 between the two interconnected node N1, N2. The disclosure may work even if these paths are activated based on the known information about interconnecting nodes isolation conditions.

(32) The working path failure can be either uni-directional or bi-directional while the vertical path failures are assumed to be all bi-directional. This embodiment assumes that SNC/S DNI within both protected domains is implemented according to document WD09-21, A solution for Ethernet DNI scenario in G.mdsp (SP #4), Huawei, October 2015.

(33) Since the vertical paths between the two interconnected nodes N1, N2 are failed, the second interconnected node N2 enables transmission of CCM and APS frames on both the protection paths.

(34) If the working path failure is unidirectional in the direction from interconnected node N1 to end-node E, end-node E can trigger protection switching within the first protected domain 111 and inform the second interconnected node N2, via APS message exchange, that interconnected node N1 is isolated within protected domain 111. Cascading of protection switching toward protected domain 121 could be achieved according to the prior art.

(35) If the working path failure is unidirectional in the direction from end-node E to interconnected node N1, protection switching actions are triggered as depicted in FIG. 2.

(36) In step S201, interconnecting node N1 detects dLOC on the working path 112 of the first protected domain 111. This means that interconnecting node N1 detects failure within the first protected domain 111. The dLOC detection is an example of failure detection in that the interconnecting node N1 detects a stop in CCM transmission between E and N1, i.e. detects an interruption in the regular reception of the CCM transmission from end-node E.

(37) It can be noted that only interconnecting node N1 can understand, based on the detected dLOC on the vertical path 114 and on the working path 112 within the first protected domain 111, that it is isolated within the first protected domain 111. Second interconnecting node N2 has no knowledge of interconnecting node N1 isolation condition.

(38) In step S202, interconnecting node N1 stops CCM transmission and starts AIS transmission toward far-end node W on the working path 122 within the second protected domain 121. The start of AIS transmission is an example of the transmission start of alarm indication information according to the present disclosure.

(39) In step S203, far-end node W detects dLOC on the working path 122, within the second protected domain 121, but the reception of AIS frames advantageously suppresses alarm reporting.

(40) In step S204, far-end node W triggers protection switching within the second protected domain 121.

(41) In step S205, far-end node W sends an SF(1,1) APS message to node N2. It can be noted that second interconnecting node N2 thinks, based on the detected dLOC on the vertical path 124 within second protected domain 121 and on the received SF(1,1) APS message, that interconnecting node N1 is isolated within the second protected domain 121. The SF(1,1) indicates an APS message, as defined in the ITU-T Recommendation G.8031/11342 (June 2011), section 11.1, where the Request/State field is set to SF (Signal Fail for working, 1011) as defined in table 11-1. The argument (1,1) indicates that the Requested Signal and Bridged Signal fields (see ITU-T Recommendation G.8031/11342 (January 2015), FIGS. 11-1 and 11-2 in section 11.1) are set to 1.

(42) In step S206, second interconnecting node N2 triggers protection switching within the second protected domain 121.

(43) In step S207, second interconnecting node N2 sends NR(1,1) APS messages to far-end node W. The NR(1,1) indicates an APS message, as defined in the ITU-T Recommendation G.8031/11342 (June 2011), section 11.1, where the Request/State field is set to NR (No Request, 0000) as defined in table 11-1. The argument (1,1) indicate that the Requested Signal and Bridged Signal fields in APS-specific information (see ITU-T Recommendation G.8031/11342 (January 2015), FIGS. 11-1 and 11-2 in section 11.1) are set to 1.

(44) In step S208, since the second interconnecting node N2 thinks that interconnecting node N1 is isolated within the second protected domain 121, it also triggers protection switching within the first protected domain 111.

(45) In step S209, second interconnecting node N2 sends SF(1,1) APS messages to node E.

(46) In step S210, node E triggers protection switching within the first protected domain 111.

(47) In step S211, node E sends NR(1,1) APS messages to the second interconnecting node N2.

(48) As a result, the traffic between the end-nodes E and W is fully recovered through the path E-N2-W.

(49) FIG. 3 shows a second failure scenario of the system according to the first embodiment of the present disclosure.

(50) If the working path failure is bidirectional between the end-node E and the interconnecting node N1, the nodes E, N1 and N2 cannot distinguish this case from the unidirectional failures cases they can address. Protection switching actions are triggered by concurrent actions initiated by end-node E and interconnecting node N1 triggered by the detection of the failure on their receive side, as depicted in FIG. 3.

(51) In step S301, the end-node E detects dLOC on the working path 112.

(52) In step S302, the end-node E triggers protection switching within the first protected domain 111.

(53) In step S303, the end-node E sends SF(1,1) APS messages to the second interconnecting node N2. It can be noted that the second interconnecting node N2 knows, based on the detected dLOC on the vertical path 114 within the first protected domain 111 and the received SF(1,1) APS message, that the interconnecting node N1 is isolated within the first protected domain 111.

(54) In step S304, interconnecting node N2 triggers protection switching within the first protected domain 111. It can be noted that the steps S301 to S304 are the same steps that end-node E and second interconnecting node N2 would take when the failure on the working path 112 is unidirectional in the direction from interconnecting node N1 to end-node E.

(55) In step S305, interconnecting node N1 detects dLOC on the working path 112 of the first protected domain 111.

(56) In step S306, interconnecting node N1 stops CCM transmission towards the second protected domain 121 and starts AIS transmission toward the far-end node W on the working path 122 within the second protected domain 121.

(57) In step S307, the far-end node W detects dLOC on the working path 122 but, similarly to step S203 of FIG. 2, the reception of AIS frames advantageously suppresses alarm reporting.

(58) In step S308, the far-end node W triggers protection switching within the protected domain 121.

(59) In step S309, the far-end node W sends SF(1,1) APS message to the second interconnecting node N2. It can be noted that the steps S305 to S309 are the same as the steps S201 to S205 according to FIG. 2 when the failure on the working path 112 is unidirectional in the direction from the end-node E to the interconnecting node N1.

(60) In step S310, since the second interconnecting node N2 thinks that the interconnecting node N1 is isolated within the second protected domain 121, it will generate SF(1,1) APS messages toward end-node E, similarly to step S209 in FIG. 2 according to the case of unidirectional path failure in the direction from end-node E to interconnecting node N1.

(61) In step S311, since the second interconnecting node N2 knows that the interconnecting node N1 is isolated within the first protected domain 111, it will generate SF(1,1) APS messages toward node W, similarly to the case of unidirectional path failure in the direction from the interconnecting node N1 to the node E.

(62) FIG. 9 shows a first scenario of a system 900 according to a second embodiment of the present disclosure.

(63) The system 900 comprises two interconnecting nodes N11, N21 according to the present disclosure. The structure and functioning of the interconnecting nodes N11, N21 are advantageously the same as for interconnecting node N1 of the first embodiment. The system 900 comprises two end-nodes E, W, the two interconnecting nodes N11, N21, and three protected domains 911, 921, 931 that are serially interconnected between the two end-nodes E, W. The interconnecting node N11 interconnects the first and second protected domains 911, 921, while the interconnecting node N21 interconnects the second and third protected domains 921, 931. The interconnecting node N21 is located in the second protected domain downstream from the point of view of N11 at the end of the second protected domain. In this document an interconnecting node or an end node located at the end of a protected domain and directly connected through a working path with the interconnecting node N11 will be called far-end node. Similarly, node N11 can be seen as a far-end node in the second protected domain from the point of view of the interconnecting node N21.

(64) Advantageously, the interconnecting node N11 interconnects respective the working paths 912, 922 of the two protected domains 911, 921, while the interconnecting node N21 interconnects the working paths 922, 932 of the two protected domains 921, 931. Further on, peer interconnecting nodes N12, N22 are responsible for interconnecting the protection paths 913, 923, 933 of the protected domains 911, 921, 931.

(65) The scenario of FIG. 9 is similar to the scenario of FIG. 2 in that the interconnecting node N11 is isolated within the protected domain 911. Advantageously, the interconnecting node N11 detects such an isolation condition within the protected domain 911 by detecting a failure, e.g. dLOC, in the working path 912 of and a failure of a vertical path between interconnecting node N11 and peer interconnecting node N12. We focus in this example on a case where both vertical paths between interconnecting node N11 and peer interconnecting node N12 within both protected domains 911, 921 present a failure. The scenario of FIG. 9 differs from the scenario of FIG. 2 in that also both vertical paths between interconnecting node N21 and peer interconnecting node N22 within both protected domains 921, 931 present a failure.

(66) Similarly to the interconnecting node N1 of the first embodiment, the interconnecting node N11 comprises: at least one interface 401, 402 adapted to receive first monitoring information from the protected domain 911; and a monitoring unit 405 adapted to detect an isolation condition of the interconnecting node N11 within the protected domain 911 based on the first monitoring information, and to generate second monitoring information.

(67) The interface 401, 402 of the interconnecting node N11 is adapted to transmit the second monitoring information to the working path 922 of the protected domain 921 so that a failure in this working path 922 is detectable, e.g. by the far-end node N21 of the working path 922, based on the second monitoring information.

(68) When an isolation condition of the interconnecting node N11 within the protected domain 911 is detected, the monitoring unit 405 is adapted to concurrently prevent the transmission of the second monitoring information and to start a transmission of alarm indication information to the working path 922 of the protected domain 921 for suppressing at the far-end node N21 an alarm reporting regarding a failure in the working path 922 of the protected domain 921. The meaning of prevention of transmission of monitoring information in different network environments has already been discussed in the previous paragraphs, in particular with reference to FIGS. 2 and 3 and will not be repeated here.

(69) Further on and in addition to the interconnecting node N1 of the first embodiment, when an isolation condition of the interconnecting node N11 within the protected domain 911 is detected, the monitoring unit of said interconnecting node N11 is adapted to generate and start a transmission of modified second monitoring information to the working path 922 of the second protected domain 921. Said modified second monitoring information indicates, e.g. to the far-end node N21 of the working path 922, that a detected failure on the working path 922 is caused by fault propagation of a failure in the first protected domain 911.

(70) Advantageously, the far-end node of the protected domain 921, i.e. the interconnecting node N21, may understand when protection switching within the protected domain 921 is triggered by a failure on the working path 922 within that protection domain 921 or by the cascading actions triggered by a fault within an upstream protected domain like the protected domain 911.

(71) Advantageously, when the isolation condition of the interconnecting node N11 within the first protected domain 911 is detected, the monitoring unit of the interconnecting node N11 is also adapted to concurrently start the transmission of the modified second monitoring information to the working path 922 of the second protected domain 921, and start the transmission of alarm indication information to the working path 922 of the second protected domain 921. Transmission of alarm indication is optional and is done for backward compatibility purposes. In this realization, the modified monitoring information has also the function of the alarm indication information. Consequently, transmission of a dedicated frame for the alarm indication information, such as transmission of an AIS frame, for instance in the Ethernet case, may be avoided.

(72) According to the present disclosure, the interconnecting node N21, which corresponds to the far-end node of the working path 922, is adapted to: receive first monitoring information from the protected domain 921, and detect an isolation condition of the interconnecting node N21 within the protected domain 921 based on the first monitoring information, similarly to the first embodiment; and receive modified first monitoring information from the protected domain 921.

(73) The first monitoring information received by the interconnecting node N21 advantageously corresponds to the second monitoring information transmitted by the interconnecting node N11. The modified first monitoring information received by the interconnecting node N21 advantageously corresponds to the modified second monitoring information transmitted by the interconnecting node N11. More specifically, the first monitoring information received by the interconnecting node N21 is the second monitoring information generated by the interconnecting node N11 and transmitted from the interconnecting node N11 to the interconnecting node N21.

(74) Particularly, the interconnecting node N21 then may distinguish between the reception of the first monitoring information and of the modified first monitoring information. Accordingly, when the modified first monitoring information is received, the interconnecting node N21 detects that a failure is located in a working path located upstream of the working path 922 to which it is connected. Also, the interconnecting node N21 detects an isolation condition of the interconnecting node N21 within the protected domain 921 based on the received first monitoring information. In other words, the interconnecting node N21 detects a failure located in the working path 922 of the protected domain 921 based on the received first monitoring information.

(75) On the one hand, the transmission of the modified second monitoring information by the interconnecting node N11, i.e. the reception of the modified first monitoring information by the interconnecting node N21, is illustrated by FIG. 9.

(76) On the other hand, FIG. 10 illustrates the transmission of the second monitoring information by the interconnecting node N11, i.e. the reception of the first monitoring information by the interconnecting node N21. In the particular scenario of FIG. 10, there is indeed a failure of the working path 922 of the protected domain 921. The interconnecting node N21 then detects such a failure located in the working path 922 of the protected domain 921 based on the received first monitoring information.

(77) In the scenario of FIG. 10 regarding a failure within protected domain 921, interconnecting node N21 detects that it is isolated within protected domain 921, and prepares transmission of alarm indication information. In packet based network environments, such as Ethernet networks the interconnecting nodes inserts AIS frames and switches off CCM frame generation on the working path 932 within protected domain 931 triggering protection switching action within protected domain 931. Node N22 would think that node N21 is isolated within protected domain 931 based on the received SF(1,1) from node W and the failure state of the vertical path within protected subnetwork 931 and therefore will generated SF(1,1) on the protection path 923 within protected subnetwork 921. The SF(1,1) from node N22 will be received by node N11 (through node N12) which would trigger protection switching within protected subnetwork 921. Traffic forwarding is recovered through the E-N11-N12-N22-W path.

(78) In the scenario of FIG. 9 regarding a failure within protected domain 911, interconnecting node N21 receives CCM frames with a different OpCodei.e. receives the modified monitoring information, can understand that the working path within the protected domain 921 is healthy and therefore that protection switching within protected domain 921 needs to be triggered because of a cascading action caused by interconnected node isolation within an upstream protected domain.

(79) In the failure scenario of FIG. 9, the interconnecting node N21 could either:

(80) 1) trigger protection switching within the protected domain 931, likewise in the failure scenario of FIG. 10, i.e. it could decide to cascade protection switching action towards protected domain 931 and recover traffic forwarding, or

(81) 2) do not take any action and cause traffic loss, i.e. it could decide not to cascade protection switching actions toward protected domain 931.

(82) According to the first embodiment comprising transmitting alarm indication information, the interconnecting node N1 terminating the working path 112 should trigger protection switching at the far-end node W of the working path 122 when it detects that it is isolated in the adjacent protected subnetwork 111 and it cannot communicate with its peer interconnecting node N2.

(83) The solution according to the first embodiment is that such an interconnecting node N1 should insert a set of OAM information elements, based on existing OAM standards, within the maintenance entity monitoring the working path that, when received by the far-end node (implementing existing SNC/S standard) would both trigger protection switching as well as suppress S203 alarm reporting, in a backward compatible wayi.e. without requiring changes to the existing implementation.

(84) In OTN networks it is sufficient to insert within the OTN frame overhead the alarm indication information in form of TCM AIS information.

(85) For Ethernet networks, it is advantageously proposed to concurrently: stop S202 transmission of CCM frames on the maintenance entity monitoring the working path: this would be sufficient to trigger protection switching and selection of the protection path as the active one; insert S202 alarm indication information in form of MS frames on the same maintenance entity: this will suppress S203 alarm reporting of dLOC at the far end node thus not triggering any unnecessary maintenance actions.

(86) According to the second embodiment, in order to avoid cascading of protection switching across multiple protected domains, beyond just the two adjacent ones, the interconnecting node N11 should also transmit modified second monitoring information by e.g. inserting additional OAM information elements, not yet defined in existing OAM standards, within the maintenance entity monitoring the working path to allow the far-end node to understand when protection switching within the protected domain is triggered by a failure on the working path within that protection domain or by the cascading actions triggered by a fault within an upstream protected domain. The far-end node can use this information just for reporting/logging purposes or, if it is interconnected to another downstream protected domain, to decide whether or not to further cascade protection switching actions toward that downstream protected domain.

(87) The reporting purpose means that the operator can monitor this condition either by reading a state or by receiving a secondary alarm/notification (i.e., not triggering any maintenance action). The logging purpose means that the interconnecting node can record this status in a log that the operator can read.

(88) This new OAM informationthe modified second monitoring informationis designed to be backward compatible, such that when received by a legacy node (i.e. nodes supporting existing SNC/S standard), it can be ignored (the legacy node will behave likewise in the first embodiment). There is no need to enable/disable this capability in the interconnection node depending on whether the far-end node supports it or not and therefore the operations are simplified and not error prone.

(89) The additional features of the second embodiment are advantageous and may be implemented/standardized if is e.g. needed to log/report cascading actions, differently than other secondary fault conditions within the protected domain, and it is always desired to cascade protection switching across multiple domains even if not adjacent.

(90) In OTN networks it is sufficient, in addition to insertion of TCM AIS information, to set within the OTN frame overhead one of the reserved bits, such that: legacy interconnecting nodes (i.e., nodes supporting existing SNC/S standard) will ignore this bit and trigger protection switching, without raising any primary alarm, because of the received TCM AIS information (likewise in the first embodiment); interconnecting nodes implementing the second embodiment can detect reception of TCM AIS and trigger protection switching, without raising any primary alarmlikewise in the first embodimentand, detecting also that this new bit is set, they can report/log this information and/or decide whether or not to further cascade protection switching actions toward the downstream protected domain, if any.

(91) In Ethernet networks, two options are possible. The first option is to set the reserved bits of the Ethernet AIS frames, such that: legacy interconnecting nodes (i.e., nodes supporting existing SNC/S standard) will ignore this bit and suppress dLOC alarm reporting because of the received AIS frame (likewise in the first embodiment); interconnecting nodes implementing the second embodiment can suppress dLOC alarm reporting (likewise in the first embodiment) and, detecting also that this new bit is set, they can report/log this information.

(92) Due to the different rates of AIS and CCM, it is not worthwhile taking fast consequent action (i.e. decide whether or not to further cascade protection switching actions toward the downstream protected domain) using AIS information. This is in line with current Ethernet standards where reception of AIS frames does not trigger protection switching actions.

(93) The second option in Ethernet networks consists in changing the value of the OpCode field in the transmitted CCM frames, instead of stopping their transmission: legacy interconnecting nodes (i.e., nodes supporting existing SNC/S standard) will discard these unknown OAM frames and, since CCM frames are not received, also detect dLOC: protection switching is triggered and primary alarm reporting is suppressed by the reception of the AIS frames (likewise in the first embodiment); interconnecting nodes implementing the second embodiment can detect reception of CCM frames with different OpCode and, in this case, should trigger protection switching without raising any alarm (likewise in the first embodiment) and they can also report/log this information and/or decide whether or not to further cascade protection switching actions toward the downstream protected domain, if any.

(94) It is worth noting that legacy nodes cannot support DNI and therefore they do not need to further propagate protection switching actions toward subsequent protected domain.

(95) FIG. 4 shows an interconnecting node according to an embodiment of the present disclosure.

(96) The interconnecting node 400 comprises at least one interface 401, 402 adapted to receive first monitoring information from the first protected domain, and particularly from a working path 412 of the first protected domain.

(97) The interconnecting node 400 comprises a monitoring unit 405 adapted to detect an isolation condition of the interconnecting node within the first protected domain based on the first monitoring information, and to generate second monitoring information.

(98) The interface 401, 402 is adapted to transmit the second monitoring information to the working path 422 of the second protected domain so that a failure in the working path 422 of the second protected domain is detectable based on the second monitoring information at a far-end node of the working path 422.

(99) When an isolation condition of the interconnecting node within the first protected domain is detected, the monitoring unit 405 is adapted to concurrently prevent the transmission of the second monitoring information and to start a transmission of alarm indication information to the working path 422 of the second protected domain for suppressing at the far-end node an alarm reporting regarding a failure in the working path 422 of the second protected domain.

(100) Particularly, the interface 401, 402 may comprise two distinct interfaces 401, 402 for respectively receiving the first monitoring information from the working path 412 of the first protected domain, and transmitting the second monitoring information to the working path 422 of the second protected domain.

(101) A possible implementation for the interconnecting node N1 is described in FIG. 4 as an example. Said FIG. 4 shows the high level block diagram for such a possible implementation of an interconnecting node 400 of interconnecting node N1.

(102) In this implementation, it is assumed that the interconnecting node N1, 400 sends/receives traffic to/from the two working paths 412, 422 and vertical paths 414, 424 toward three line interfaces 401, 402, 403: one interface 401 for the working path 412 within the first protected domain 111, one interface 402 for the working path 422 within the first protected domain 121 and one interface 403 for both the vertical paths 414, 424. The two working paths 412, 422 and the vertical paths 414, 424 respectively correspond to the working paths 112, 122 and the vertical paths 114, 124 of FIG. 1.

(103) The traffic for these three interfaces is processed by a processing unit 404. The processing unit 404 will process the traffice.g., Ethernet framesreceived from the line, as specified in relevant standards, understand to which connection the traffic belongs to and decide how it has to be further processed. The traffic to be forwarded will be passed to a switching unit 406, together with the information needed to properly forward it toward the egress.

(104) The traffic received from the line can contain OAM informatione.g., Ethernet OAM frames or OTN frame overhead bytesto be processed locally by the node: this information will be sent to an OAM unit 405, together with the information identifying the associated maintenance entity. The OAM unit 405 is an example of the monitoring unit according to the present disclosure.

(105) The processing unit 404 is also responsible to properly formatting the egress traffic, received from the switching unit 406, for being transmitted toward the line. The processing unit 404 can also receive OAM information from the OAM unit 405 to be forwarded either toward the linetogether with the traffic received from the switching unit 406or towards the switching unit 406together with the traffic received from the line.

(106) FIG. 5 shows a monitoring unit of an interconnecting node according to an embodiment of the present disclosure, and particularly shows a possible implementation of a monitoring unit 500 of the OAM unit 405 of FIG. 4. FIG. 5 depicts monitoring unit 500 implemented in a packet based environment, such as an Ethernet network. A monitoring unit implemented in an interconnecting node of a network different than Ethernet, such as for instance an OTN network, may include functional blocks different than those illustrated in FIG. 5. As an example a monitoring unit for an OTN network may include a functional block for processing OAM information in the received overhead of an OTN frame or to request the Processing Unit to set the overhead of an OTN frame information describing the type of failure with alarm indication information. Such functional block may replace the CCM and AIS generate blocks of the monitoring unit 500 of FIG. 5.

(107) The OAM unit 500 is decomposed in different functional blocks implementing different OAM functions. The OAM unit comprises a mux/demux unit 501 that multiplexes the OAM information generated by the OAM functional blocks toward the processing unit 404 and demultiplexes the OAM information received from the processing unit 404 toward the OAM functional block(s). In case of Ethernet, the demultiplexing of received OAM frames toward different OAM processing units is based on the OpCode field in the Ethernet OAM PDU, as defined in ITU-T Recommendation G.8013/Y.1731 (August 2015), OAM functions and mechanisms for Ethernet-based networks (in particular chapter 9).

(108) The OAM unit 500 comprises a CCM block 502 that generates CCM frames and processes received CCM frames on a given maintenance entity, implementing the CCM state machines defined in ITU-T Recommendation G.8021 (April 2015), section 8.1.7, Characteristics of Ethernet transport network equipment functional blocks. The CCM block 502 supports many instances of these state machines, one for each maintenance entity. It also provides, for each maintenance entity, dLOC (and other CCM-related defect) information to a Consequent Action process, as defined in ITU-T Recommendation G.8021 (April 2015), chapter 6.2. The Consequent Action process is implemented in a Consequent Action block 503 shown in FIG. 5.

(109) FIG. 6 shows a state machine for transmitting the second monitoring information by an interconnecting node according to an embodiment of the present disclosure. Particularly, FIG. 6 defines the state machine of the CCM generation process, i.e. of the CCM block 502 of FIG. 5.

(110) The generation of the CCM frames on each maintenance entity is started/stopped based on the operator's configuration, which corresponds to the input MI_CC_Enable, as defined in ITU-T Recommendation G.8021 (April 2015), section 8.1.7.2. In order to support cascading of protection switching actions, the state machine should also consider a new input, which is referred to as SF_Cascade in FIGS. 5 and 6.

(111) For the first embodiment, the CCM block should start/stop CCM generation based on the logical and between MI_CC_Enable and the SF_Cascade signal as shown in FIG. 6.

(112) For the second embodiment, the state machine is almost the same as in FIG. 8-17 of ITU-T Recommendation G.8021 (April 2015) but the CCM( ) function will take also the SF_Cascade input parameter: if the SF_Cascade is false, the generated CCM frame will have the OpCode set to 1 (existing standard OpCode value defined for CCM frames); if the SF_Cascade is true, the generated CCM frame will have the OpCode set to one of the value reserved for future standardization (e.g., value 39).

(113) Alternatively, if SF_Cascade is true, a VSM or an EXM frame can be generated instead of CCM. This VSM PDU would have most of the fields set to the same values of the corresponding field in the CCM frame. As shown in FIG. 7, the differences are: OpCode is set 51 (existing standard OpCode value defined for VSM frames); OUI is set to the OUI value assigned to the vendor implementing this solution; SubOpCode is set to any value the vendor choses to identify this modified CCM frames (e.g., value 1); TLV Offset is set to 74 (i.e., the value of the TLV Offset defined for CCM plus 4, since there are 4 additional bytes before the TLV area starts to carry the OUI and SubOpCode fields).

(114) In order to insert also AIS frames, a new AIS generation process or CMC block 502 should be added to generate AIS frames on a given maintenance entity when requested by the SF_cascad signal. The state machine of the AIS generation process is similar to the state machine of the AIS insert process, as defined in FIGS. 8-9 of ITU-T Recommendation G.8021 (April 2015). The difference would be: AIS frames are inserted within a given maintenance entity and not within its client layer (or sub-layer) connections; AIS frame generation is triggered by SF_cascade signal rather than by the aAIS consequent action.

(115) An example of the resulting state machine is shown in FIG. 8.

(116) According to the second embodiment, one of the Reserved bits (e.g., bit 8) of the Flag field in the AIS frame will be set to 1. The format of the AIS Flag field is shown in FIGS. 9.7-2 of ITU-T Recommendation G.8013/Y.1731 (August 2015).

(117) In order to trigger protection switching actions between adjacent protected subnetworks a new Cascade Logic block 504 is implemented in the monitoring unit 500 of FIG. 5. The Cascade Logic block 504 receives information about the signal fail status of a given maintenance entity via an aTSF signal generated, as per standard implementation, by the Consequent Action block 503 and trigger protection switching cascading action, via the SF_Cascade toward the CCM and AIS Generate blocks 502 and 505.

(118) The Cascade Logic block is configured, for each SNC/S DNI protected domain, with the following information: The maintenance entity monitoring the working and vertical paths for each SNC/S protected domain: for example, it is configured with the information about which maintenance entities are monitoring the working and protection paths of the SNC/S protected domains 1 and 2; The pair of adjacent SNC/S protected domains: for example that protected domains 1 and 2 are adjacent.

(119) This block is able to detect whether the node N1 is isolated within a protected domain based on the aTSF information for the associated maintenance entities: when aTSF is asserted for both maintenance entities, the node is isolated.

(120) For example, when the aTSF for the maintenance entities monitoring the working path 112 W1 and vertical path 114 V1 of SNC/S protected domain 111 is asserted, node N1 is considered isolated within protected domain 111 PD1:
N1_isolation[PD1]=aTSF[W1] and aTSF[V1]

(121) When node isolation within a given SNC/S domain is detected, the Cascade Logic block is responsible to trigger protection switching in the adjacent protected domain by asseting the SF_Cascade signal, toward the CCM and the AIS generated blocks, for the maintenance entity monitoring the working path.

(122) For example when N1 is considered isolated within protected domain 111, the block knows, by configuration, that the adjacent protected domain is protected domain 121 and it also knows, by configuration, which is the maintenance entity associated with the working path 122 W2 of SNC/S protected domain 121 PD2:
Adjacent_PD[PD1]=PD2
Working_Path[PD2]=W2

(123) In order to support the second embodiment, the CCM block should be updated to accept both standard CCMs as well as modified CCM. As a consequence, dLOC would not be triggered when standard CCMs are not received but modified CCM are received instead. Anew defect dXCC should also be detected and reported to both the consequent action block and the Cascade Logic, when modified CCMs are received instead of standard CCMs.

(124) The defect correlation block should be modified to generate aTSF[ ] also in case dXCC is received: this information will also be used by the protection switching process (not shown) to trigger protection switching.

(125) The Cascade Logic, if configured not to cascade protection switching actions across multiple domain (MI_SF_Cascade_Multi) should not consider the node isolated in case dXCC is reported for the maintenance entity:
N1_isolation[PD1]=aTSF[W1] and aTSF[V1] and (not (dXCC[W1]) and (not MI_SF_Cascade_Multi))).

(126) In TDM network environments, such as for instance in an OTN network, the alarm indication information and the monitoring information is embedded in the OTN frame and specifically in the ODUk overhead of an OTN frame as defined for instance in ITU-T Recommendation G.709/Y.1331 (February 2012), section 15.8.1 FIGS. 15-12 to 15-14. Accordingly, the monitoring and AIS information for the working path are sent within the TCM # i byte associated with the TCM used for monitoring the working path. Specifically, referring to the TCM # i overhead format (see for instance FIGS. 15-14 for instance in ITU-T Recommendation G.709/Y.1331 (February 2012), section 15.8.1) the monitoring and AIS information are sent in the STAT bits of the TCM # i overhead format. The following table 1 indicates the STAT bits of the TCM format (see also table 15-5 for instance in ITU-T Recommendation G.709/11331 (February 2012), section 15.8.2.2.5):

(127) TABLE-US-00001 TABLE 1 ODUk TCM status interpretation TCM byte 3 bits 6 7 8 Status 0 0 0 No source TC 0 0 1 In use without IAE 0 1 0 In use with IAE 0 1 1 Reserved for future international standardization 1 0 0 Reserved for future international standardization 1 0 1 Maintenance signal: ODUk-LCK 1 1 0 Maintenance signal: ODUk-OCI 1 1 1 Maintenance signal: ODUk-AIS

(128) According to ITU-T Recommendation G.709/11331 (February 2012), section 15.8.2.2.5, monitoring information is inserted by setting the STA bits to either 001 to indicate that there is no incoming alignment error (IAE), or to 010 to indicate that there is an incoming alignment error. Setting the STA bits to a value different than 001 or 010 can be seen as stopping the insertion of the monitoring information.

(129) According to the disclosure, when an interconnecting node, for instance interconnecting node N1 in FIGS. 1 to 3 is isolated, the STA bits are set to 111 instead, corresponding to the status Mainteinance signal: ODUk-AIS. Setting of the STA bits may be done by the TC-CMEP ingress point.

(130) In OTN network environments, modified monitoring information may be transmitted using the reserved bits in the OTUk overhead (RES). The ODUk overhead of the OTN frame is illustrated in in ITU-T Recommendation G.709/Y.1331 (February 2012), section 15.8.1 FIGS. 15-12 and the reserved bits are described in section 15.8.2.7. As an example, the reserved bits may be two bytes located in row 1, columns 13 and 14 of the OTUk overhead. Such a choice would assure backward compatibility.

(131) Alternatively, the reserved codepoints within the TCM bytes may be used. The reserved codepoints may be the bits 011 or 100 in table 1 above. In a further alternative, the APS/PCC bites in the ODUk frame.

(132) The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word comprising does not exclude other elements or steps and the indefinite article a or an does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.