Protection switching method and node
10674240 ยท 2020-06-02
Assignee
Inventors
Cpc classification
H04J3/085
ELECTRICITY
H04Q2011/0081
ELECTRICITY
International classification
G02F1/00
PHYSICS
H04J3/16
ELECTRICITY
H04J3/08
ELECTRICITY
Abstract
A protection switching method, including sending, by a first end node, a first protection switching request message to an intermediate node in response to a fault occurring on a working trail between the first end node and a second end node, wherein a protection trail of the working trail comprises the first end node, the second end node, and at least one intermediate node, receiving, by the first end node, a second protection switching request message from the intermediate node, and switching service data to the protection trail for transmission in response to receiving the second protection switching request message, where one overhead frame of each of the first and second protection switching request messages has at least two overhead information groups, and each of the at least two overhead information groups comprises a request type field, a request signal identifier field, and a bridge flag field.
Claims
1. A protection switching method for shared mesh protection (SMP), comprising: sending, by a first end node, a first protection switching request message to an intermediate node in response to a fault occurring on a working trail between the first end node and a second end node, wherein a protection trail of the working trail comprises the first end node, the second end node, and at least one intermediate node; receiving, by the first end node, a second protection switching request message from the intermediate node; and switching service data to the protection trail for transmission in response to receiving the second protection switching request message; wherein one overhead frame of each of the first protection switching request message and the second protection switching request message comprises at least two overhead information groups, and each of the at least two overhead information groups comprises a request type field, a request signal identifier field, and a bridge flag field; and wherein the request type field indicates a fault type of the working trail, wherein the request signal identifier field indicates a service identifier of a service that requests a protection resource, and wherein the bridge flag field indicates whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been bridged.
2. The method according to claim 1, wherein each of the at least two overhead information groups further comprises a request flag field, wherein the request flag field is indicates whether the service corresponding to the service identifier indicated by the request signal identifier field requests the protection resource.
3. The method according to claim 2, wherein each of the at least two overhead information groups further comprises a reserved field, wherein the request type field occupies 4 bits, the request signal identifier field occupies 8 bits, the request flag field occupies 1 bit, the bridge flag field occupies 1 bit, and the reserved field occupies 2 bits.
4. The method according to claim 2, wherein the request type field occupies 4 bits, the request signal identifier field occupies 10 bits, the request flag field occupies 1 bit, and the bridge flag field occupies 1 bit.
5. The method according to claim 2, wherein each of the at least two overhead information groups further comprises a reserved field, wherein the request type field occupies 4 bits, the request signal identifier field occupies 9 bits, the request flag field occupies 1 bit, the bridge flag field occupies 1 bit, and the reserved field occupies 1 bit.
6. The method according to claim 1, wherein the overhead information group further comprises a selector flag field, wherein the selector flag field indicates whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been selected.
7. The method according to claim 1, wherein the first protection switching request message and the second protection switching request message are each an automatic protection switching (APS) message.
8. The method according to claim 1, wherein each of the at least two overhead information groups further comprises a selector flag field, wherein the selector flag field indicates whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been selected.
9. The method according to claim 1, wherein the bridge flag field occupies 1 bit.
10. A first end node for shared mesh protection (SMP), comprising: a cross-connect board; a first optical transport network (OTN) communication board connected to the cross-connect board and configured to communicate on an OTN; and a main control board connected to the cross-connect board and the first OTN communication board, wherein the main control board is configured to control the first OTN communication board to: send a first protection switching request message to an intermediate node in response to a fault occurring on a working trail between the first end node and a second end node, wherein a protection trail of the working trail comprises the first end node, the second end node, and at least one intermediate node; and receive a second protection switching request message from the intermediate node; wherein the main control board is further configured to control the cross-connect board to switch service data to the protection trail for transmission in response to the second protection switching request message; wherein one overhead frame of each of the first protection switching request message and the second protection switching request message comprises at least two overhead information groups, and each of the at least two overhead information groups comprises a request type field, a request signal identifier field, and a bridge flag field; and wherein the request type field indicates a fault type of the working trail, wherein the request signal identifier field indicates a service identifier of a service that requests a protection resource, and wherein the bridge flag field indicates whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been bridged.
11. The first end node according to claim 10, wherein each of the at least two overhead information groups further comprises a request flag field, and wherein the request flag field indicates whether the service corresponding to the service identifier indicated by the request signal identifier field requests the protection resource.
12. The first end node according to claim 11, wherein each of the at least two overhead information groups further comprises a reserved field, wherein the request type field occupies 4 bits, the request signal identifier field occupies 8 bits, the request flag field occupies 1 bit, the bridge flag field occupies 1 bit, and the reserved field occupies 2 bits.
13. The first end node according to claim 11, wherein the request type field occupies 4 bits, the request signal identifier field occupies 10 bits, the request flag field occupies 1 bit, and the bridge flag field occupies 1 bit.
14. The first end node according to claim 11, wherein each of the at least two overhead information groups further comprises a reserved field, wherein the request type field occupies 4 bits, the request signal identifier field occupies 9 bits, the request flag field occupies 1 bit, the bridge flag field occupies 1 bit, and the reserved field occupies 1 bit.
15. The first end node according to claim 10, wherein the first protection switching request message and the second protection switching request message are automatic protection switching (APS) messages.
16. The first end node according to claim 10, wherein each of the at least two overhead information groups further comprises a selector flag field, wherein the selector flag field indicates whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been selected.
17. An intermediate node for shared mesh protection (SMP), comprising: a cross-connect board; one or more optical transport network (OTN) communication boards connected to the cross-connect board and configured to communicate on an OTN; and a main control board connected to the cross connect board and the one or more OTN communication boards, wherein the main control board is configured to control the one or more OTN communication boards to: receive a first protection switching request message from a first end node in response to a fault occurring on a working trail between the first end node and a second end node, wherein a protection trail of the working trail comprises the first end node, the second end node, and the intermediate node; send the first protection switching request message to a downstream, adjacent, node of the intermediate node; receive a second protection switching request message from the downstream adjacent node of the intermediate node; and send a second protection switching request message to the first end node; wherein one overhead frame of the first protection switching request message and the second protection switching request message comprises at least two overhead information groups, wherein each of the at least two overhead information groups comprises a request type field, a request signal identifier field, and a bridge flag field, wherein the request type field indicates a fault type of the working trail, wherein the request signal identifier field indicates a service identifier of a service that requests a protection resource, and wherein the bridge flag field indicates whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been bridged.
18. The intermediate node according to claim 17, wherein each of the at least two overhead information groups further comprises a request flag field, wherein the request flag field indicates whether the service corresponding to the service identifier indicated by the request signal identifier field requests the protection resource.
19. The intermediate node according to claim 17, wherein each of the at least two overhead information groups further comprises a reserved field, wherein the request type field occupies 4 bits, the request signal identifier field occupies 8 bits, the request flag field occupies 1 bit, the bridge flag field occupies 1 bit, and the reserved field occupies 1 bit or 2 bits.
20. The intermediate node according to claim 17, wherein the bridge flag field occupies 1 bit.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1) The following briefly describes the accompanying drawings required for describing the background and the embodiments.
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
(20)
(21)
(22)
(23)
(24)
(25)
(26)
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
(27) The following describes the embodiments of the present disclosure with reference to the accompanying drawings.
(28) SMP allows a protection resource to be shared by a plurality of working trails, and the plurality of working trails do not need to have a same source node and a same sink node.
(29) To implement protection switching of a service, an APS (Automatic Protection Switched, automatic protection switching) overhead needs to be configured for a protection trail that bears the service. The APS overhead may represent an overhead of a plurality of protection switching types, such as SMP, 1+1 protection, 1:1 protection, and linear protection. An APS message carrying the APS overhead is used to represent a protection switching signaling message, such as an SMP protection switching signaling message, and one frame of every eight frames of APS overheads indicates an SMP protection switching signaling message. A link granularity of the APS overhead depends on a link granularity of a protection trail that bears a service on a faulty working trail. APS overheads with different link granularities are corresponding to different transmission bandwidths and timeslot resource quantities, but have a same APS overhead encoding format. In an Optical Transport Network (OTN), a smallest link granularity is Optical channel Data Unit (ODU) 0 whose bandwidth is 1.25 G and that occupies one timeslot resource. Other link granularities may include ODU1, ODU2, ODU3, and ODU4 whose bandwidths are respectively 2.5 G, 10 G, 40 G, and 100 G and that respectively occupy 2, 8, 32, and 80 timeslot resources. For example, when an ODU2 link is used to protect a service in an ODU0 link, during protection switching, one of eight timeslots is used, and an overhead of the ODU2 should be used.
(30) In the prior art, signaling transfer of protection switching is performed by using an APS overhead encoding format shown in
(31) A signaling transfer direction may be from the source node to the sink node or from the sink node to the source node. An upstream direction and a downstream direction are relative, either direction may be the upstream direction, and the other direction is the downstream direction. The embodiments of the present disclosure provide description by using an example in which the node A is a source node of S1 and P1 and a node B is a sink node on S1 and P1. On S1 or P1, a direction from the node A to the node B is the downstream direction, and a direction from the node B to the node A is the upstream direction.
(32) Specifically, after determining that a resource between A and E is available, the source node A on P1 completes bridging with the downstream node E, and sends a signal fail message SF (W1, W1) to the downstream node E. Resource availability includes the resource between A and E is idle, or the resource between A and E is occupied by a low-priority service. The signal fail message may be represented by using an APS overhead, and an APS overhead encoding format is SF (W1, W1), where SF (W1, W1) indicates a signal failure, to request to activate the protection trail, and indicates that a node that sends the message has completed bridging.
(33) After receiving the signal fail message SF (W1, W1), the node E determines that a resource between E and F is available, and the node E completes bridging and sends the same signal fail message SF (W1, W1) to a downstream node F. Processing procedures of the node F and a node G are similar to that of the node E, and details are not described herein.
(34) The sink node B on P1 does not establish a selector and a bridge until the sink node B on P1 receives the signal fail message SF (W1, W1) and then determines that a protection resource between G and B is available. Then, the node B sends a reverse request message RR (W1, W1) to the upstream node G, to instruct the node G to establish a selector. The reverse request message may be represented by using an APS overhead whose encoding format is RR (W1, W1), indicating a reverse request, to request to activate the protection trail, and indicating that a node that sends the reverse request message has completed bridging.
(35) After receiving the reverse request message RR (W1, W1), and determining that a resource between G and F is available, the node G establishes a selector, and sends the same reverse request message RR (W1, W1) to the upstream node F. Processing procedures of the node F and the node E are similar to that of the node G, and details are not described.
(36) Protection switching of W1 is not completed until the source node A receives the reverse request message RR (W1, W1) and then establishes a selector. That is, W1 is switched from the working trail S1 to the protection trail P1.
(37) If the APS overhead encoding format in the prior art is used, overhead resource waste is caused because a reserved field is not fully used. Therefore, an embodiment of the present disclosure proposes an APS overhead encoding format, so that an overhead resource can be fully used. As shown in
(38) A (1) Request Type is included in the 1.sup.st bit to the 4.sup.th bit, and represents a protection switching request type such as SF, SD, RR, NR, MS, or FS. For example, SF is used in a scenario in which a fault occurs on a working trail and a service is switched from the working trail to a protection trail, SD is used in a scenario in which a signal on a working trail is degraded and a service is switched from the working trail to a protection trail, RR is used as a message in response to SF, SD, or the like, NR is used in a scenario in which a fault is removed from a working trail and a service is switched from a protection trail to the working trail, MS and FS are respectively used in a manual switching scenario and a forced switching scenario.
(39) (2) Request Signal ID is included in the 5.sup.th bit to the 12.sup.th bit, and represents a service ID, for example, W1, of a service that requests a protection trail resource when a fault occurs on a working trail. When the service corresponding to the service ID is in a normal state and does not request the protection trail resource, Request Signal ID may be set to all zeros. The working trail and the protection trail may be corresponding to a same service ID. For example, a service ID of a service corresponding to S1 and P1 is W1, and a service ID of a service corresponding to S2 and P2 is W2.
(40) A (3) Request Flag (RF) is included in the 13.sup.th bit, and represents whether a service whose service ID is Request Signal ID has been requested. When a fault occurs on a working trail, a protection trail resource corresponding to the service whose service ID is Request Signal ID is requested, and RF may be set to 1, or when no fault occurs on a working trail, a protection trail resource corresponding to the service whose service ID is Request Signal ID is not requested, and RF may be set to 0. When Request Signal ID is set to all zeros, the RF flag bit has no meaning.
(41) A (4) Bridge Flag (BF) is included in the 14.sup.th bit, and represents whether a bridge is established on a node corresponding to a protection trail for a service whose service ID is Request Signal ID. If a bridge has been established on the node corresponding to the protection trail for the service whose service ID is Request Signal ID, BF is set to 1, or if no bridge is established on the node corresponding to the protection trail for the service whose service ID is Request Signal ID, BF is set to 0. When Request Signal ID is set to all zeros, the BF flag bit has no meaning.
(42) Optionally, bit locations of the foregoing four types of information in the APS overhead encoding are not limited to the foregoing implementation. For example, locations of RF and BF are interchangeable.
(43) Optionally, because Request Flag may be further uniquely identified by using Request Type, Request Flag may not be included in the foregoing encoding format. As shown in
(44) Optionally, as shown in
(45) Optionally, a length of the service ID of the service that requests the protection trail resource is not limited to 8 bits, and may be increased to 9 bits or 10 bits. If a bit increase is required, RF and BF are moved backward to a next bit, to occupy a bit in the Resv reserved field. For example, if Request Signal ID needs to be represented by 9 bits, the 1.sup.st bit to the 4.sup.th bit are Request Type, the 5.sup.th bit to the 13.sup.th bit are Request Signal ID, the 14.sup.th bit is RF, the 15.sup.th bit is BF, and the 16.sup.th bit is Resv. If Request Signal ID needs to be represented by 10 bits, the 1.sup.st bit to the 4.sup.th bit are Request Type, the 5.sup.th bit to the 14.sup.th bit are Request Signal ID, the 15.sup.th bit is RF, and the 16.sup.th bit is BF. If the foregoing encoding format further includes Selector Flag, only one bit in the reserved field is available, and in this case, the service ID may be increased to 9 bits.
(46) In the encoding format proposed in this embodiment of the present disclosure, the 17.sup.th bit to the 32.sup.nd bit and the 1.sup.st bit to the 16.sup.th bit have same meaning, but are corresponding to different timeslots. For example, an ODU1 link includes two timeslots. The foregoing 4-byte encoding format is considered as one frame. In one frame, the 1.sup.st bit to the 16.sup.th bit represent a timeslot 1, and the 17.sup.th bit to the 32.sup.nd bit represent a timeslot 2. For a link granularity that occupies more than two timeslots, such as ODU2, ODU3, or ODU4, an APS message needs to be represented by 4 frames, 16 frames, or 40 frames. In this embodiment of the present disclosure, because one frame indicates overhead information of two timeslots, a frame quantity is reduced by half compared with the prior art. That is, an overhead resource is saved by 50%, so that an APS overhead field is fully used.
(47)
(48) The following describes, with reference to several examples, the APS overhead encoding format proposed in this embodiment of the present disclosure.
(49)
(50)
(51)
(52) The following specifically describes a step performed by each node in the signaling procedures shown in
(53) Node A: When detecting that a fault occurs on a working trail, the node A sends a signal fail message to a downstream node E. In addition, the node A receives a reverse request message from the downstream node E.
(54) Specifically, that the node A detects that a fault occurs on the working trail S1 may be as follows. The node A detects a link fault, or the node B detects a link fault and then notifies the node A of the link fault. When detecting that a fault occurs on the working trail, the node A may establish a bridge, for example, the bridge 3 shown in
(55) Specifically, a time at which the node A receives the reverse request message RR (W1, 1, 1) from the node E depends on a time at which the node E sends the message to the node A. For details, refer to a step performed by the node E. After receiving the RR (W1, 1, 1) message sent by the node E, the node A determines that the resource between the node A and the node E is available, and establishes a selector between E and A, for example, the selector 4 shown in
(56) The signal fail message sent by the node A to the downstream node E may be represented by using an APS overhead whose encoding format is SF (W1, 1, 1), indicating a signal failure and indicating that a protection trail P1 has been requested by W1 and a bridge has been established. The reverse request message received by the node A from the downstream node E may be represented by using an APS overhead whose encoding format is RR (W1, 1, 1), indicating a reverse request, to request to activate the protection trail P1 of W1, and indicating that a node that sends the message has established a bridge. Specifically, for the overhead encoding format of the signal fail message SF (W1, 1, 1) and the overhead encoding format of the reverse request message RR (W1, 1, 1), refer to the embodiments shown in
(57) Node E: After receiving the signal fail message from the node A, the node E sends the signal fail message to a downstream node F, and sends the reverse request message to the upstream node A. In addition, the node E receives a reverse request message from the downstream node F.
(58) Specifically, after receiving the signal fail message SF (W1, 1, 1), the node E may establish a bridge, for example, the bridge 1 of the node E shown in
(59) The node E may first send the signal fail message SF (W1, 1, 1) to the downstream node F, and then send the reverse request message RR (W1, 1, 1) to the upstream node A. Alternatively, the node E may first send the RR (W1, 1, 1) message to the upstream node A, and then send the SF (W1, 1, 1) message to the downstream node F.
(60) Specifically, the node E may send the RR (W1, 1, 1) message to the node A immediately after receiving the SF (W1, 1, 1) message from the node A. Optionally, the node E may send the RR (W1, 1, 1) message to the node A after receiving the RR (W1, 1, 1) message sent by the node F.
(61) A time at which the node E receives the reverse request message RR (W1, 1, 1) from the node F depends on a time at which the node F sends the message to the node E. For details, refer to a process in which the node A receives the RR (W1, 1, 1) message from the node E. After receiving the RR (W1, 1, 1) message from the node F, the node E establishes a bridge, for example, the bridge 2 of the node E shown in
(62) Node F: After receiving the signal fail message from the upstream node E, the node F sends the signal fail message to a downstream node G, and sends the reverse request message to the upstream node E. In addition, the node F receives a reverse request message from the downstream node G.
(63) A processing procedure of the node F is similar to that of the node E, and details are not described.
(64) Node G: After receiving the signal fail message from the upstream node F, the node G sends the signal fail message to the downstream node B, and sends the reverse request message to the upstream node F. In addition, the node G receives a reverse request message from the downstream node B.
(65) A processing procedure of the node G is similar to that of the node E, and details are not described.
(66) Node B: After receiving the signal fail message from the upstream node G, the node B sends the reverse request message to the upstream node G.
(67) Specifically, after receiving the signal fail message SF (W1, 1, 1) from the upstream node G, the node B determines that a resource between the node B and the node G is available, establishes a selector between G and B and a bridge between B and G, and sends the reverse request message to the upstream node G. Specifically, the node B may first establish the selector between G and B and then establish the bridge between B and G, or may first establish the bridge between B and G and then establish the selector between G and B, or may simultaneously establish the selector between G and B and the bridge between B and G.
(68) In this embodiment of the present disclosure, alternatively, the node B may send a signal fail message to the node A, the node A may send a reverse request message to the node B, and a signaling procedure is similar thereto. Alternatively, as shown in
(69) In the APS overhead encoding format proposed in this embodiment of the present disclosure, because an APS message of one frame can indicate overheads of two timeslots, overhead resource utilization is improved, so that protection switching efficiency is improved when a fault occurs on the working trail.
(70)
(71) The following specifically describes a step performed by each node in the signaling procedures shown in
(72) Node A: When detecting that a fault is removed from a working trail, the node A sends a first no-request message to a downstream node E, and receives a second no-request message from the downstream node E.
(73) Generally, fault removal may be successively detected by a source node and a sink node, or may be detected by either of a source node and a sink node, or may be simultaneously detected by a source node and a sink node. After detecting that the fault is removed from the working trail S1, when sending the first no-request message NR (W1, 0, 1) to the node E, the node A may release a selector between E and A. Optionally, the node A may release the selector between E and A before sending the NR (W1, 0, 1) message or after sending the NR (W1, 0, 1) message.
(74) Specifically, a time at which the node A receives the second no-request message NR (0, 0, 0) from the node E depends on a time at which the node E sends the message to the node A. For details, refer to a step performed by the node E. The node A releases a bridge between A and E after receiving the NR (0, 0, 0) message from the node E.
(75) The first no-request message sent by the node A to the downstream node E may be represented by using an APS overhead whose encoding format is NR (W1, 0, 1), indicating that a protection resource corresponding to W1 is not requested but a bridge has been established. The second no-request message received by the node A from the downstream node E may be represented by using an APS overhead whose encoding format is NR (0, 0, 0), indicating that the protection resource is not requested and a bridge has not been established.
(76) Node E: The node E receives the first no-request message from the upstream node A, sends the first no-request message to a downstream node F, and sends the second no-request message to the upstream node A. In addition, the node E receives a second no-request message from the downstream node F.
(77) Specifically, after receiving the first no-request message NR (W1, 0, 1) from the upstream node A and sending the first no-request message, the node E releases a selector between F and E, for example, the selector 2 of the node E shown in
(78) The node E may first send the first no-request message NR (W1, 0, 1) to the downstream node F, and then send the second no-request message NR (0, 0, 0) to the upstream node A. Alternatively, the node E may first send the NR (0, 0, 0) message to the upstream node A, and then send the NR (W1, 0, 1) to the downstream node F.
(79) Specifically, the node E may send the NR (0, 0, 0) message to the node A immediately after receiving the NR (W1, 0, 1) message from the node A. Optionally, the node E may send the NR (0, 0, 0) message to the node A after receiving the NR (0, 0, 0) message from the node F.
(80) A time at which the node E receives the second no-request message NR (0, 0, 0) from the node F depends on a time at which the node F sends the message to the node E. For details, refer to a process in which the node A receives the NR (0, 0, 0) message from the node E. After receiving the NR (0, 0, 0) message from the node F, the node E releases a bridge between E and F, for example, the bridge 1 shown in
(81) Node F: After receiving the first no-request message from the upstream node E, the node F sends the first no-request message to a downstream node G, and sends the second no-request message to the upstream node E. In addition, the node F receives a second no-request message from the downstream node G.
(82) A processing procedure of the node F is similar to that of the node E, and details are not described.
(83) Node G: After receiving the first no-request message from the upstream node F, the node G sends the first no-request message to the downstream node B, and sends the second no-request message to the upstream node F. In addition, the node G receives a second no-request message from the downstream node B.
(84) A processing procedure of the node G is similar to that of the node F, and details are not described.
(85) Node B: After receiving the first no-request message from the upstream node G, the node B sends the second no-request message to the upstream node G.
(86) Specifically, after receiving the first no-request message NR (W1, 0, 1) from the upstream node G, the node B releases a bridge between B and G and a selector between G and B, and sends the second no-request message NR (0, 0, 0) to the upstream node G. Specifically, the node B may first release the selector between G and B and then release the bridge between B and G, or may first release the bridge between B and G and then release the selector between G and B, or may simultaneously release the selector between G and B and the bridge between B and G.
(87) In this embodiment of the present disclosure, alternatively, the node B may send a first no-request message to the node A, the node A sends a second no-request message to the node B, and a signaling procedure is similar thereto. Alternatively, as shown in
(88) In the APS overhead encoding format proposed in this embodiment of the present disclosure, because an APS message of one frame can indicate overheads of two timeslots, overhead resource utilization is improved, so that service recovery efficiency is improved when the fault is removed from the working trail.
(89)
(90) The following specifically describes a step performed by each node in the signaling procedures shown in
(91) Node C: When detecting that a fault occurs on a working trail, the node C sends a first signal fail message to a downstream node E, and receives a first signal fail message from the downstream node E.
(92) This embodiment of the present disclosure provides description by using an example in which the node C is a source node of S2 and P2 and the node D is a sink node of S2 and P2. On S2 or P2, a direction from the node C to the node D is a downstream direction, and a direction from the node D to the node C is an upstream direction.
(93) Specifically, that the node C detects that a fault occurs on the working trail S2 may be as follows. The node C detects a link fault, or the node D detects a link fault and then notifies the node C of the link fault. When detecting that a fault occurs on the working trail, the node C may establish a bridge between C and E after the node C determines that a resource between the node C and the node E is available. Resource availability herein means that the resource is idle, that is, the resource is not occupied by another service. After establishing the bridge between C and E, the node C may send the first signal fail message SF (W2, 1, 1) to the downstream node E.
(94) A time at which the node C receives the first signal fail message SF (W2, 1, 1) from the downstream node E depends on a time at which the node D initiates a protection switching signaling procedure to the node C. For details, refer to steps performed by the node D and the node E. After receiving the SF (W2, 1, 1) message sent by the node E, the node C determines that the resource between the node C and the node E is available, and establishes a selector between E and C.
(95) The first signal fail message may be transferred by using an APS message, and an encoding format is SF (W2, 1, 1), indicating a signal failure and indicating that a protection trail P2 has been requested by W2 and has been bridged. Specifically, for the overhead encoding format of the signal fail message SF (W2, 1, 1), refer to the embodiments shown in
(96) Node E: After receiving the first signal fail message from the upstream node C, the node E sends a second signal fail message to a downstream node F, receives a first signal fail message from the downstream node F, and sends the first signal fail message to the upstream node C.
(97) Specifically, after receiving the first signal fail message SF (W2, 1, 1) from the upstream node C, the node E detects that a resource between E and F is occupied by W1, does not establish a bridge between E and F, and sends a second signal fail message SF (W2, 1, 0) to the downstream node F. After receiving the SF (W2, 1, 1) message from the node C, the node E determines that a resource between the node E and the upstream node C is available, and may establish a selector between C and E. Optionally, the node E may establish the selector between C and E after receiving the first signal fail message SF (W2, 1, 1) from the downstream node F. The node E may compare priorities of W1 and W2, and after determining that the priority of W2 is higher than the priority of W1, instruct the node E to revert the service W1 from P1 to the working trail S1 on the upstream node A of P1. Optionally, the node E may instruct, by using the node F and the node G, the node B to revert the service W1 to the working trail S1. A reversion process of the service W1 is similar to the signaling procedures in
(98) A time at which the node E receives the first signal fail message SF (W2, 1, 1) sent by the downstream node F depends on the time at which the node D initiates the protection switching signaling procedure to the node C. After receiving the SF (W2, 1, 1) message from the node F, and determining that the resource between the node E and the node F is available, the node E establishes a selector between F and E. In addition, after determining that the resource between the node E and the node C is available, the node E establishes a bridge between E and C. After establishing the bridge between E and C, the node E sends the SF (W2, 1, 1) message to the upstream node C.
(99) After receiving the SF (W2, 1, 1) message from the downstream node F, the node E determines that the resource between the node E and the node F is available, and establishes a bridge between E and F. Optionally, if the node E has not established the selector between C and E, the node E may further establish the selector between C and E at this time. Further, the node E sends an SF (W2, 1, 1) message to the downstream node F. Specifically, the node E may first send the SF (W2, 1, 1) message to the upstream node C, and then send the SF (W2, 1, 1) message to the downstream node F. Alternatively, the node E may first send the SF (W2, 1, 1) message to the downstream node F, and then send the SF (W2, 1, 1) message to the upstream node C.
(100) Specifically, the node E sends the second signal fail message SF (W2, 1, 0) to the downstream node F, indicating a signal failure and indicating that the protection trail P2 has been requested by W2 but a bridge has not been established.
(101) Node F: The node F receives the second signal fail message from the upstream node E, sends the second signal fail message to a downstream node G, receives a first signal fail message from the downstream node G, and sends the first signal fail message to the upstream node E.
(102) A processing procedure of the node F is similar to that of the node E, and details are not described.
(103) Node G: The node G receives the second signal fail message from the upstream node F, sends the first signal fail message to the downstream node D, receives a first signal fail message from the downstream node D, and sends the first signal fail message to the upstream node F.
(104) After receiving the second signal fail message SF (W2, 1, 0) from the upstream node F, the node G detects that a resource between the node G and the downstream node D is available, establishes a bridge between G and D, and sends the first signal fail message SF (W2, 1, 1) to the downstream node D. After receiving the SF (W2, 1, 0) message from the node F, the node G instructs the node B to revert W1 from the protection trail P1 to the working trail S1. In this case, a resource between the node G and the node F is not occupied by another service, and the node G may establish a selector between F and G. Optionally, the node G may establish the selector between F and G after receiving the first signal fail message SF (W2, 1, 1) sent by the upstream node F.
(105) After the node G receives the first signal fail message SF (W2, 1, 1) from the downstream node D, if the node G has received the second signal fail message SF (W2, 1, 0) from the upstream node F at this time, the node G may determine that the resource between the node G and the node F has been released by the service W1 and the resource between G and F is available. The node G may establish a bridge between G and F and establish a selector between D and G, and the node G sends the SF (W2, 1, 1) message to the upstream node F.
(106) Optionally, the node G may first receive the SF (W2, 1, 1) message from the node D, and then receive the SF (W2, 1, 0) message from the node F. As shown in
(107) A time at which the node G receives the SF (W2, 1, 1) message from the node F depends on a time at which the node F sends the message. The node F may send the SF (W2, 1, 1) message to the node G immediately after receiving the SF (W2, 1, 1) message from the node G. Alternatively, the node F may send the SF (W2, 1, 1) message to the node G after receiving the SF (W2, 1, 1) message from the node E.
(108) Node D: The node D receives the first signal fail message from the upstream node G, and sends the first signal fail message to the upstream node G.
(109) The node D may further establish a selector between G and D and a bridge between G and D after detecting that a fault occurs on the working trail and determining that a resource between the node G and the node D is not occupied by another service and is in an available state. Further, the node D sends the first signal fail message SF (W2, 1, 1) to the upstream node G.
(110) The node D may initiate the protection switching signaling procedure after detecting that a fault occurs on the working trail S2. Alternatively, the node D initiates the protection switching signaling procedure after receiving the SF (W2, 1, 1) message from the upstream node G. Specifically, the node D may send the first signal fail message SF (W2, 1, 1) to the upstream node G before receiving the first signal fail message SF (W2, 1, 1) from the upstream node G. Alternatively, the node D may send the SF (W2, 1, 1) message to the upstream node G after receiving the SF (W2, 1, 1) message from the upstream node G.
(111) In this embodiment, the node C or the node D may individually initiate the protection switching signaling procedure. Alternatively, as shown in
(112) In the APS overhead encoding format proposed in this embodiment of the present disclosure, because an APS message of one frame can indicate overheads of two timeslots, an APS overhead field is fully used, so that protection switching efficiency is improved when a fault occurs on the working trail.
(113)
(114) Specifically, the sending module 141 is configured to, when a fault occurs on the working trail between the first end node and a second end node, send a first protection switching request message to an intermediate node, where the protection trail of the working trail includes the first end node, the second end node, and at least one intermediate node.
(115) The receiving module 142 is configured to receive a second protection switching request message from the intermediate node, and switch service data to the protection trail for transmission.
(116) One overhead frame of the first protection switching request message and the second protection switching request message includes at least two overhead information groups, and the overhead information group includes a request type field, a request signal identifier field, and a bridge flag field.
(117) The request type field indicates a fault type of the working trail, the request signal identifier field indicates a service identifier of a service that requests a protection resource, and the bridge flag field indicates whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been bridged.
(118) Optionally, the overhead information group further includes a request flag field, where the request flag field is used to indicate whether the service corresponding to the service identifier indicated by the request signal identifier field requests the protection resource.
(119) Optionally, the overhead information group further includes a reserved field, where the request type field occupies 4 bits, the request signal identifier field occupies 8 bits, the request flag field occupies 1 bit, the bridge flag field occupies 1 bit, and the reserved field occupies 2 bits.
(120) Optionally, the request type field occupies 4 bits, the request signal identifier field occupies 10 bits, the request flag field occupies 1 bit, and the bridge flag field occupies 1 bit.
(121) Optionally, the overhead information group further includes a reserved field, where the request type field occupies 4 bits, the request signal identifier field occupies 9 bits, the request flag field occupies 1 bit, the bridge flag field occupies 1 bit, and the reserved field occupies 1 bit.
(122) Optionally, the overhead information group may further include a selector flag field, where the selector flag bit field is used to indicate whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been selected.
(123) Optionally, the first protection switching request message and the second protection switching request message are APS messages.
(124) In this embodiment of the present disclosure, in a process in which a node performs protection switching, because one overhead frame of a protection switching request message may include information about two overhead groups, to indicate overheads of two timeslots, an overhead field is fully used, so that protection switching efficiency is improved.
(125)
(126) The receiving module 152 is configured to, when a fault occurs on a working trail between a first end node and a second end node, receive a first protection switching request message from the first end node, where the protection trail of the working trail includes the first end node, the second end node, and at least one intermediate node.
(127) The sending module 151 is configured to send the first protection switching request message to a downstream adjacent node of the intermediate node.
(128) The receiving module 152 is configured to receive a second protection switching request message from the downstream adjacent node of the intermediate node.
(129) The sending module 151 is configured to send a second protection switching request message to the first end node.
(130) One overhead frame of the first protection switching request message and the second protection switching request message includes at least two overhead information groups, and the overhead information group includes a request type field, a request signal identifier field, and a bridge flag field.
(131) The request type field indicates a fault type of the working trail, the request signal identifier field indicates a service identifier of a service that requests a protection resource, and the bridge flag field indicates whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been bridged.
(132) Optionally, the overhead information group further includes a request flag field, where the request flag field is used to indicate whether the service corresponding to the service identifier indicated by the request signal identifier field requests the protection resource.
(133) Optionally, the overhead information group further includes a reserved field, where the request type field occupies 4 bits, the request signal identifier field occupies 8 bits, the request flag field occupies 1 bit, the bridge flag field occupies 1 bit, and the reserved field occupies 2 bits.
(134) Optionally, the request type field occupies 4 bits, the request signal identifier field occupies 10 bits, the request flag field occupies 1 bit, and the bridge flag field occupies 1 bit.
(135) Optionally, the overhead information group further includes a reserved field, where the request type field occupies 4 bits, the request signal identifier field occupies 9 bits, the request flag field occupies 1 bit, the bridge flag field occupies 1 bit, and the reserved field occupies 1 bit.
(136) Optionally, the overhead information group may further include a selector flag field, where the selector flag bit field is used to indicate whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been selected.
(137) Optionally, the first protection switching request message and the second protection switching request message are APS messages.
(138) In this embodiment of the present disclosure, in a process in which a node performs protection switching, because one overhead frame of a protection switching request message may include information about two overhead groups, to indicate overheads of two timeslots, an overhead field is fully used, so that protection switching efficiency is improved.
(139)
(140) The receiving module 162 is configured to, when a fault occurs on the working trail between a first end node and the second end node, receive a first protection switching request message from an intermediate node, where the protection trail of the working trail includes the first end node, the second end node, and at least one intermediate node.
(141) The sending module 161 is configured to send a second protection switching request message to the intermediate node.
(142) One overhead frame of the first protection switching request message and the second protection switching request message includes at least two overhead information groups, and the overhead information group includes a request type field, a request signal identifier field, and a bridge flag field.
(143) The request type field indicates a fault type of the working trail, the request signal identifier field indicates a service identifier of a service that requests a protection resource, and the bridge flag field indicates whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been bridged.
(144) Optionally, the overhead information group further includes a request flag field, where the request flag field is used to indicate whether the service corresponding to the service identifier indicated by the request signal identifier field requests the protection resource.
(145) Optionally, the overhead information group further includes a reserved field, where the request type field occupies 4 bits, the request signal identifier field occupies 8 bits, the request flag field occupies 1 bit, the bridge flag field occupies 1 bit, and the reserved field occupies 2 bits.
(146) Optionally, the request type field occupies 4 bits, the request signal identifier field occupies 10 bits, the request flag field occupies 1 bit, and the bridge flag field occupies 1 bit.
(147) Optionally, the overhead information group further includes a reserved field, where the request type field occupies 4 bits, the request signal identifier field occupies 9 bits, the request flag field occupies 1 bit, the bridge flag field occupies 1 bit, and the reserved field occupies 1 bit.
(148) Optionally, the overhead information group may further include a selector flag field, where the selector flag bit field is used to indicate whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been selected.
(149) Optionally, the first protection switching request message and the second protection switching request message are APS messages.
(150) In this embodiment of the present disclosure, in a process in which a node performs protection switching, because one overhead frame of a protection switching request message may include information about two overhead groups, to indicate overheads of two timeslots, the reserved field in an overhead field is fully used, so that protection switching efficiency is improved.
(151)
(152) This embodiment of the present disclosure provides description by using an example in which the system includes the first end node, the intermediate node, and the second end node. There may be a plurality of intermediate nodes.
(153) When a fault occurs on a working trail between the first end node and the second end node, the first end node sends a first protection switching request message to the intermediate node, where a protection trail of the working trail includes the first end node, the second end node, and at least one intermediate node.
(154) The intermediate node receives the first protection switching request message from the first end node, and sends the first protection switching request message to the second end node.
(155) The second end node receives the first protection switching request message from the intermediate node, and sends a second protection switching request message to the intermediate node.
(156) The intermediate node receives the second protection switching request message from the second end node, and sends a second protection switching request message to the first end node.
(157) The first end node receives the second protection switching request message from the intermediate node, and switches service data to the protection trail for transmission.
(158) One overhead frame of the first protection switching request message and the second protection switching request message includes at least two overhead information groups, and the overhead information group includes a request type field, a request signal identifier field, and a bridge flag field.
(159) The request type field indicates a fault type of the working trail, the request signal identifier field indicates a service identifier of a service that requests a protection resource, and the bridge flag field indicates whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been bridged.
(160) In this embodiment of the present disclosure, in a process in which a node performs protection switching, because one overhead frame of a protection switching request message may include information about two overhead groups, to indicate overheads of two timeslots, an overhead field is fully used, so that protection switching efficiency is improved.
(161)
(162) The main control board 181 is connected to the OTN tributary board 182, the cross-connect board 183, and the OTN line board 184 by using a bus or in a direct manner, and has a function of controlling and managing the OTN tributary board 182, the cross-connect board 183, and the OTN line board 184.
(163) The OTN tributary board 182 implements encapsulating and mapping of a client service. There are a plurality of types of client services, for example, an ATM (Asynchronous Transfer Mode) service, an SDH (Synchronous Digital Hierarchy) service, an Ethernet service, a CPRI (Common Public Radio Interface) service, and a storage service. Specifically, the tributary board 182 is configured to receive a client service from the client side, encapsulates the received client service and maps the received client service to an ODU signal, and adds a corresponding OTN management monitoring overhead. On the OTN tributary board 182, the ODU signal may be a lower order ODU signal, for example, ODU0, ODU1, ODU2, ODU3, and ODUflex, and the OTN management monitoring overhead may be an ODU overhead. Different types of client services are encapsulated and mapped to different ODU signals in different manners.
(164) The cross-connect board 183 implements a full cross-connection between a tributary board and a line board, and implements flexible cross-connection grooming of an ODU signal. Specifically, the cross-connect board may transmit an ODU signal from any tributary board to any line board, or transmit an OTU signal from any line board to any line board, or transmit a client signal from any tributary board to any tributary board.
(165) The OTN line board 184 generates an OTU (Optical Channel Transport Unit) signal by using an ODU signal and sends the OTU signal to the line side. Before generating the OTU signal by using the ODU signal, the OTN line board 184 may multiplex a plurality of lower order ODU signals into a higher order ODU signal. Then, a corresponding OTN management monitoring overhead is added to the higher order ODU signal to form the OTU signal, and the OTU signal is sent to an optical transfer channel of the line side. On the OTN line board, the higher order ODU signal may be ODU1, ODU2, ODU3, ODU4, or the like, and the OTN management monitoring overhead may be an OTU overhead.
(166) The main control board 181 may have a processor that executes pre-configured program code stored in a non-transitory computer readable medium, and may control any one or more boards of the OTN tributary board 182, the cross-connect board 183, or the OTN line board 184 to implement the following functions.
(167) For example, when detecting that a fault occurs on a working trail between a first end node and a second end node, the OTN line board 184 or the OTN tributary board 182 sends a first protection switching request message to an intermediate node, where a protection trail of the working trail includes the first end node, the second end node, and at least one intermediate node. The OTN line board 184 or the OTN tributary board 182 receives a second protection switching request message from the intermediate node.
(168) The cross-connect board 183 switches service data to the protection trail for transmission.
(169) One overhead frame of the first protection switching request message and the second protection switching request message includes at least two overhead information groups, and the overhead information group includes a request type field, a request signal identifier field, and a bridge flag field.
(170) The request type field indicates a fault type of the working trail, the request signal identifier field indicates a service identifier of a service that requests a protection resource, and the bridge flag field indicates whether the protection resource corresponding to the service identifier indicated by the request signal identifier field has been bridged.
(171) Optionally, the overhead information group further includes a request flag field, where the request flag field is used to indicate whether the service corresponding to the service identifier indicated by the request signal identifier field requests the protection resource.
(172) Optionally, the overhead information group further includes a reserved field, where the request type field occupies 4 bits, the request flag field occupies 1 bit, and the bridge flag field occupies 1 bit. The request signal identifier field may occupy 8 bits, 9 bits, or 10 bits, and a corresponding reserved field occupies 2 bits, 1 bit, or 0 bits.
(173) In this embodiment of the present disclosure, because one overhead frame of an APS message may include information about two overhead groups, to indicate overheads of two timeslots, an overhead field is fully used, so that protection switching efficiency is improved.
(174) Specifically, the OTN device 180 shown in
(175) A person of ordinary skill in the art may understand that, each aspect of the present disclosure or a possible implementation of each aspect may be specifically implemented as a system, a method, or a computer program product. Therefore, each aspect of the present disclosure or a possible implementation of each aspect may use forms of hardware only embodiments, software only embodiments (including firmware, resident software, and the like), or embodiments with a combination of software and hardware, which are uniformly referred to as circuit, module, or system herein. In addition, each aspect of the present disclosure or the possible implementation of each aspect may take a form of a computer program product, where the computer program product is computer-readable program code stored in a computer-readable medium.
(176) A person of ordinary skill in the art may be aware that, the units and algorithm steps in the examples described with reference to the embodiments disclosed in this specification may be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are performed by hardware or software depends on particular applications and design constraint conditions of the technical solutions. A person skilled in the art may use different methods to implement the described functions for each particular application, but it should not be considered that the implementation goes beyond the scope of the present disclosure.