Preventing invalid defect detection during OTN out-of-frame states

1. A method for processing a report of a defect during an Out-Of-Frame (OOF) condition, comprising: detecting the OOF condition at a downstream node; detecting an indication of the defect caused by the OOF condition that causes creation of a report: suppressing the report associated with the indication of the defect; determining whether the OOF condition is clear; if the OOF condition is clear, determining whether the indication of the defect is still present such that the defect is a valid defect; and if the indication of the defect is not present, cancelling the report after the OOF condition is clear and before the OOF condition becomes a Loss Of Frame (LOF) condition or a Loss of Signal (LOS) condition since the defect is an invalid defect caused by the OOF condition which is now cleared, wherein the cancelling of the report prevents a control plane from rerouting a connection associated with the ODUk frame.

2. The method of claim 1 , further comprising: providing the report if the indication of the defect is present.

3. The method of claim 1 , further comprising: determining whether the OOF condition persists for more than a predetermined period of time when it is determined that the OOF condition is not clear.

4. The method of claim 3 , wherein it is determined that the OOF condition does not persist for more than the predetermined period of time, further comprises: repeating the detecting the OOF condition, the detecting the indication of the defect caused by the OOF condition, the suppressing the report associated with the indication of the defect, and the determining whether the OOF condition is clear.

5. The method of claim 3 , wherein it is determined that the OOF condition exceeds the predetermined period of time, further comprises: declaring the Loss Of Frame (LOF) condition.

6. The method of claim 3 , wherein predetermined period of time is three milliseconds.

7. The method of claim 1 , wherein the OOF condition is caused by a change in timing of an OTUk (Optical Transport Unit) frame due to a timing reference change of an ODUk (Optical channel Data Unit) frame.

8. The method of claim 7 , wherein timing reference change of the ODUk frame is caused by a change in a cross connection of the ODUk frame from one ODUk client to another ODUk client, from an ODU-AIS (Alarm Indication Signal), an ODU-OCI (Open Connection Indication) condition to an ODUk client, or any combination thereof.

9. The method of claim 1 , wherein the detecting the defect caused by an OOF condition occurs within five frames.

10. The method of claim 2 , wherein the report is provided to a control plane.

11. A network node which processes a report of a defect during an Out-Of-Frame (OOF) condition, comprising: a network interface; and a processor, coupled to the network interface, configured to (i) detect the OOF condition at a downstream node, (ii) detect an indication of the defect caused by the OOF condition that causes creation of a report, (iii) suppress the report associated with the indication of the defect, (iv) determine whether the OOF condition is clear, (v) if the OOF condition is clear, determine whether the indication of the defect is still present such that the defect is a valid defect, and (vi) if the indication of the defect is not present, cancel the report after the OOF condition is clear and before the OOF condition becomes a Loss Of Frame (LOF) condition or a Loss of Signal (LOS) condition since the defect is an invalid defect caused by the OOF condition which is now cleared, wherein the canceled report prevents a control plane from rerouting a connection associated with the ODUk frame.

12. The network node of claim 11 , wherein the processor is further configured to: provide the report if the indication of the defect is present.

13. The network node of claim 11 , wherein the processor is further configured to: determine whether the OOF condition persists for more than a predetermined period of time when it is determined that the OOF condition is not clear.

14. The network node of claim 13 , wherein it is determined that the OOF condition does not persist for more than the predetermined period of time, the processor is further configured to: repeat the detecting the OOF condition, the detecting the indication of the defect caused by the OOF condition, the suppressing the report associated with the indication of the defect, and the determining whether the OOF condition is clear.

15. The network node of claim 13 , wherein it is determined that the OOF condition exceeds the predetermined period of time, wherein the processor is further configured to: declare the Loss Of Frame (LOF) condition.

16. The network node of claim 13 , wherein predetermined period of time is three milliseconds.

17. The network node of claim 11 , wherein the OOF condition is caused by a change in timing of an OTUk (Optical Transport Unit) frame due to a timing reference change of an ODUk (Optical channel Data Unit) frame.

18. The network node of claim 17 , wherein timing reference change of the ODUk frame is caused by a change in a cross connection of the ODUk frame from one ODUk client to another ODUk client, from an ODU-AIS (Alarm Indication Signal), an ODU-OCI (Open Connection Indication) condition to an ODUk client, or any combination thereof.

19. The network node of claim 11 , wherein the detecting the defect caused by an OOF condition occurs within five frames.