Как локализовать ошибку

16.2.1 Background

Fault localization is a basic component in fault management systems, because it identifies the reason for the fault that can best explain the observed network disorders (namely, symptoms). Examples of fault symptoms include unreachable hosts or networks, slow response, high utilization, and so on. Most fault reasoning algorithms use a bipartite directed acylic graph to describe the symptom-fault correlation, which represents the causal relationship between each fault f_i and a set of its observed symptoms Sfi. [1]. Symptom-fault causality graphs provide a vector of correlation likelihood measures p(s_i|f_i) to bind a fault fi to a set of its symptoms S_fi. Similarly, symptom-intrusion causality graphs can be constructed based on attack graphs [2] (see also Chapter 9) to describe the alarm-intrusion correlation. For simplicity, in the rest of this section, we will focus on fault reasoning and diagnosis. However, similar techniques are applicable to identification of security attacks/intrusions.

Two approaches are commonly used in fault reasoning and localization: passive diagnosis [1, 3–5] and active probing [6–9]. In the passive approach, all symptoms are passively collected and then processed to infer the root faults. In the active approach, faults are detected by conducting a set of probing actions. The passive approach causes less intrusiveness in management networks. However, it may take a long time to discover the root faults, particularly if the symptom loss ratio is high. On the other hand, although an active probing approach is more efficient to quickly identify faults, probing might cause significant overhead, particularly in large-scale networks. In this section, we will show a novel fault localization technique that integrates the advantage of both passive and active monitoring into one framework, called active integrated fault reasoning (AIR). In our approach, if the passive reasoning is not sufficient to explain the problem, AIR selects optimal probing actions to discover the most critical symptoms that are important to explain the problem. But such symptoms may have been lost or corrupted during passive fault reasoning. Our approach significantly improves the performance of fault localization while minimizing the intrusiveness of active fault reasoning.

AIR consists of three modules: fault reasoning (FR), fidelity evaluation (FE), and action selection(AS). The fault reasoning module passively analyzes observed symptoms and generates a fault hypothesis. The fault hypothesis is then sent to a fidelity evaluation module to verify whether the fidelity value of the reasoning result is satisfactory. If the correlated symptoms necessary to explain the fault hypothesis are observed (i.e., there is high fidelity), then the fault reasoning process terminates. Otherwise, a list of most likely unobserved symptoms that can contribute to the fault hypothesis fidelity is sent to the action selection module. The AS module then performs selected actions to determine which symptoms have occurred but are not observed (i.e., lost) and accordingly adjusts the hypothesis fidelity value. If the new fidelity value is satisfactory, then the reasoning process terminates; otherwise, the new symptom evidence is fed into the FR module to create a new hypothesis. This process is recursively invoked until a highly credible hypothesis is found.

The section is organized as follows. In Section 16.2.2, related work is discussed. In Section 16.2.3, we discuss our research motivation and the problem formalization. In Section 16.2.4, we describe the components and algorithms of AIR. In Section 16.2.5, we present a simulation study to evaluate AIR performance and accuracy.

5.1 Program Slicing: Early Work

The first attempt to automate fault localization is static slicing [47,48], which is a technique that uses static dependence analysis to identify the set of program statements (slice), that could be responsible for an erroneous program state that occurred at a particular location in a program, termed slicing criterion. Dynamic slicing [7,8,49,50], a test-driven technique that extracts a slice from an execution trace, is potentially much more precise and, therefore, more beneficial for fault localization than static slicing, as it could be seen when contrasting Figs. 1 and 2 in Section 2.1. Despite this fact, dynamic slicing is still considered too imprecise, as dynamic slices are typically unmanageably large, which requires the developer to exert considerable effort to locate the faulty statements.

Depending on the problem at hand, two main types of slices could be computed, backward and forward. Backward slices include the statements that influence a given slicing criterion, whereas forward slices include the statements that get influenced by a given slicing criterion. Note that if the type of a slice is not specified, a backward slice is usually meant.

There are practically hundreds of early articles written on program slicing and dozens of proposed slicing techniques, but we opt not to further our discussion of earlier work since slicing, just by itself, has shown limited success in fault localization. One example of an early work that attempted to improve the fault localization capabilities of slicing is the technique presented by Agrawal et al. [51]. That technique is based on dicing, a dice being the set difference of two slices. It conjectures that the fault resides in the execution slice (trace) of a failing run but does not reside in the execution slice of a passing run, an assumption that does not generally hold.

Background

The first instances of these techniques (eg, [1,2]) were clever, disruptive, and promising. Case in point, the work by Jones and colleagues [1] was awarded an ACM SIGSOFT Outstanding Research Award, and Liblit’s dissertation, which was based on [2], received an ACM Doctoral Dissertation Award. Unfortunately, however, SBFL somehow became too popular for its own good; a few years after these first and a few other innovative techniques were presented, researchers started to propose all sorts of variations on the initial idea. In most cases, these variations simply consisted of using a different formula for the ranking and showing slight improvements in the effectiveness of the approach. This trend is still in effect today, to some extent.

5 Conclusion

In this chapter, Disqover, a new fault localization technique, was presented. This technique exploits automated test case generation tools to generate a large number of test cases and implements a novel algorithm to find commonalities between the failing test cases by automatically replaying them, and extracting their sequence covers, i.e., execution traces. As debugging costs continue to be more expensive, the benefits of automated debugging and fault localization techniques will become more tangible. Nowadays, static analysis methods are so advanced and integrated in pretty much all of software development IDEs. Also, software instrumentation techniques are prevalent, and it is not uncommon to have instrumented versions of software in a production setting for various dynamic analysis purposes. However, either technique, static or dynamic, is not sufficient by itself to accurately identify software faults. Hybrid approaches can make static and dynamic approaches complement each other to achieve the best of the two worlds. In this chapter, we presented one such approach, and we hope it attracts the research community attention to the value of hybrid approaches. Such approaches are not limited to improve fault localization only, but also performance testing, memory profiling, and software structure and quality in general.

7.3 Fault Localization

Once test cases that origin from CT are executed, their unique structure consisting of parameter value combinations allows systematic fault localization. This is achieved by locating failure-triggering parameter value combinations in failing tests, known as identifying failure-inducing combinations. Since accurately identifying minimal failure-inducing combinations is a hard problem, most existing techniques come up with candidates for failure-inducing combinations, i.e., combinations that are likely to trigger failures but are not guaranteed to do so.

There are two major approaches for identifying failure-inducing combinations. The first approach takes a single failing test case as input, and isolates a minimal value combination that triggers the observed failure. Zhang and Zhang propose a fault characterization method called Faulty Interaction Characterization (FIC) and its binary search alternative FIC_BS [10]. The method uses the failing test case as a seed for the generation of additional test cases that assist in locating a failure-inducing combination that occurs in the original test case. By executing the additional test cases and observing their results, one can eliminate combinations that no longer induce the failure and narrow down on the failure-inducing ones. Complexity-wise, FIC is very efficient. Its complexity is only O(k) (where k is the number of parameters), while there are 2^K potential failure-inducing combinations in a failing test case. However, there are two important assumptions that reduce its applicability in practice: (1) there are no constraints in the model, and (2) no new failures are introduced when the failing test case is modified to produce new test cases. A different technique that eliminates these assumptions was proposed by Niu et al. [120]. By building a tuple relation tree (TRT) for a failing test case, they allow a clear view of its interactions and can also handle multiple, possibly overlapping, failure-inducing combinations.

The second approach takes a set of test cases as input and their execution results (pass/fail), and identifies failure-inducing combinations that may occur in them. Yilmaz et al. describe a fault localization technique based on machine learning [121]. It takes a covering array and its execution results as inputs and builds a classification tree that models the failing test cases. The model is evaluated by using it to predict the results of new test cases. Since the model encodes the information that will predict a failure, it assists developers in understanding the root cause of the failure.

Shi et al. propose a different fault localization technique, in which given a set of test cases and their execution results, candidates for failure-inducing combinations are identified [122]. These are combinations that appear only in failing test cases and not in passing ones. Next, for each failing test case, n additional test cases are generated to isolate its failure-inducing combination, where n is the number of model parameters. The initial candidate set is reduced based on the execution results of the additional test cases. More recently, another technique was suggested along with a tool called BEN [123–125]. In this technique, combinations are first ranked based on how suspicious they are in inducing failures. Next, additional test cases are created to refine the ranking, and the process repeats iteratively until either failure-inducing combinations are detected, or the set of suspicious combinations is empty.

15.1.3 Application of Instantaneous Frequency for Disturbance Propagation

The time of arrival of disturbance signals on high-voltage transmission lines is of great interest for relay and fault localization. Traditional fault localization in a transmission line network is based on a fault-study using voltage and current measurements. The traditional methodology is subject to inaccurate results, because the calculation depends on the rough assumption of the fault impedance and the type of fault. Power system monitoring systems employ GPS (global positioning systems) receivers to provide time synchronized data. GPS synchronized data enables one to solve the fault location problem based on time-of-arrival of the disturbance waveforms. The propagation properties of high voltage transmission lines have been carefully treated and shown to be dispersive [7]. To treat the time synchronized disturbance data, an accurate estimation of the arrival time is critical. In this section, an application example is provided to show how the instantaneous frequency can be utilized for the arrival time estimation.

As the transmission line is characterized by frequency-dependent attenuation and dispersion, different frequencies suffer different amounts of attenuation and also propagate with different phase and group velocities; consequently, the waveforms observed at different buses appear “distorted” or “dispersed” from the original waveform. Therefore, it is difficult to assign time-of-arrival for “distorted” signals. There are perhaps many ways to determine time-of-arrival; however, in this section we focus on one, namely instantaneous frequency.

5.3.2 OTN monitoring

In OTN, per-layer monitoring has been defined. OAM is supported by path-trace and loop installations. Fault localization is possible with electrical and optical supervisory signals. It is possible to detect signal degradations and switch upon these conditions. Several protection and restoration mechanisms have been, or are still being, defined for OTN. Linear (point-to-point) subnetwork connection (SNC) protection mechanisms are defined in ITU-T Recommendation G.873.1 for the ODUk level. 1+1 and 1:N linear protection are supported. Further mechanisms include trail (OCh, OMS) 1+1 protection as defined in ITU-T Recommendation G.872. Shared-ring protection for the ODUk level is defined in Recommendation G.873.2. OTN restoration is standardized in ITU-T ASON.

In Figure 5.34, three cascaded carrier and two nested vendor domains are shown. Since one TCM layer can be reused for the metro carrier domains X and Y and the vendor domain B, three TCM layers are required in total.

10.6.1 Capacitance measurement

When the center conductor of a cable is not exposed to seawater (open fault), a capacitance measurement may be used for the fault localization. The capacitance between the center conductor (copper tube) and the outside conductor (seawater) is measured, and the fault location is estimated from the test results. The cable and/or repeater parameters, which were obtained during the factory tests or commissioning and acceptance tests, are used to calculate the distance of the fault from the shore station.

6 Handling Failures

Although testing of modern web applications has received increasing attention in the recent past, there has been limited work on what happens after a test reveals an error. After a test fails, the fault localization process much be undertaken by developers in order to identify the fault responsible for the failure. However, when a web application test assertion fails, determining the faulty program code responsible for the failure can be a challenging endeavor.

AutoFlox [62] is an automated technique for localizing code-terminating DOM-related JavaScript errors—a DOM access function returns a null, undefined, or incorrect value, which then propagates into several variables and eventually causes an exception in JavaScript code execution. AutoFlox takes a code-terminating line of JavaScript code as input and performs dynamic analysis and backward slicing of the web application to localize the cause of these JavaScript faults.

When a fault is localized, the next natural step would be to repair the fault. Vejovis [64] is a technique that tries to automatically find a fix for a JavaScript fault. First, the authors try to understand common fixes applied by programmers to JavaScript faults. Based on these findings, they propose an automated technique for providing repair suggestions for DOM-related JavaScript faults.

Related to program repair are prevention techniques. For instance, Jensen et al. [65] and Meawad et al. [66] introduce techniques that transform unsafe eval calls in JavaScript code to functionally equivalent without the use of eval.

MPLS-TP OAM Procedures

MPLS-TP provides mechanisms to support in-band OAM functions such as continuity check, connectivity verification, loss measurement, delay measurement, remote defect indication, and alarm indication signal. Like legacy transport networks, these mechanisms allow for fault localization, performance monitoring, remote indications, and alarm suppression. Rather than define new OAM protocols, the MPLS-TP IETF drafts specify mechanisms (via G-Al/G-Ach) to reuse traditional MPLS and carrier Ethernet OAM procedures such as BFD and Y.1731.

The BFD and Y.1731 procedures can be used to monitor LSPs, sections, or PWs. In addition, recent IETF drafts also define Fault OAMs (AIS, RDI, and LKR) for signal failure detection, for propagation of the signal fail condition across layers, and for alarm suppression. MPLS-TP provides mechanisms to support in-band OAM functions such as continuity check, connectivity verification, loss measurement, delay measurement, remote defect indication, and alarm indication signal.

16.2.1 Background

Fault localization is a basic component in fault management systems, because it identifies the reason for the fault that can best explain the observed network disorders (namely, symptoms). Examples of fault symptoms include unreachable hosts or networks, slow response, high utilization, and so on. Most fault reasoning algorithms use a bipartite directed acylic graph to describe the symptom-fault correlation, which represents the causal relationship between each fault f_i and a set of its observed symptoms Sfi. [1]. Symptom-fault causality graphs provide a vector of correlation likelihood measures p(s_i|f_i) to bind a fault fi to a set of its symptoms S_fi. Similarly, symptom-intrusion causality graphs can be constructed based on attack graphs [2] (see also Chapter 9) to describe the alarm-intrusion correlation. For simplicity, in the rest of this section, we will focus on fault reasoning and diagnosis. However, similar techniques are applicable to identification of security attacks/intrusions.

Two approaches are commonly used in fault reasoning and localization: passive diagnosis [1, 3–5] and active probing [6–9]. In the passive approach, all symptoms are passively collected and then processed to infer the root faults. In the active approach, faults are detected by conducting a set of probing actions. The passive approach causes less intrusiveness in management networks. However, it may take a long time to discover the root faults, particularly if the symptom loss ratio is high. On the other hand, although an active probing approach is more efficient to quickly identify faults, probing might cause significant overhead, particularly in large-scale networks. In this section, we will show a novel fault localization technique that integrates the advantage of both passive and active monitoring into one framework, called active integrated fault reasoning (AIR). In our approach, if the passive reasoning is not sufficient to explain the problem, AIR selects optimal probing actions to discover the most critical symptoms that are important to explain the problem. But such symptoms may have been lost or corrupted during passive fault reasoning. Our approach significantly improves the performance of fault localization while minimizing the intrusiveness of active fault reasoning.

AIR consists of three modules: fault reasoning (FR), fidelity evaluation (FE), and action selection(AS). The fault reasoning module passively analyzes observed symptoms and generates a fault hypothesis. The fault hypothesis is then sent to a fidelity evaluation module to verify whether the fidelity value of the reasoning result is satisfactory. If the correlated symptoms necessary to explain the fault hypothesis are observed (i.e., there is high fidelity), then the fault reasoning process terminates. Otherwise, a list of most likely unobserved symptoms that can contribute to the fault hypothesis fidelity is sent to the action selection module. The AS module then performs selected actions to determine which symptoms have occurred but are not observed (i.e., lost) and accordingly adjusts the hypothesis fidelity value. If the new fidelity value is satisfactory, then the reasoning process terminates; otherwise, the new symptom evidence is fed into the FR module to create a new hypothesis. This process is recursively invoked until a highly credible hypothesis is found.

The section is organized as follows. In Section 16.2.2, related work is discussed. In Section 16.2.3, we discuss our research motivation and the problem formalization. In Section 16.2.4, we describe the components and algorithms of AIR. In Section 16.2.5, we present a simulation study to evaluate AIR performance and accuracy.

5.1 Program Slicing: Early Work

The first attempt to automate fault localization is static slicing [47,48], which is a technique that uses static dependence analysis to identify the set of program statements (slice), that could be responsible for an erroneous program state that occurred at a particular location in a program, termed slicing criterion. Dynamic slicing [7,8,49,50], a test-driven technique that extracts a slice from an execution trace, is potentially much more precise and, therefore, more beneficial for fault localization than static slicing, as it could be seen when contrasting Figs. 1 and 2 in Section 2.1. Despite this fact, dynamic slicing is still considered too imprecise, as dynamic slices are typically unmanageably large, which requires the developer to exert considerable effort to locate the faulty statements.

Depending on the problem at hand, two main types of slices could be computed, backward and forward. Backward slices include the statements that influence a given slicing criterion, whereas forward slices include the statements that get influenced by a given slicing criterion. Note that if the type of a slice is not specified, a backward slice is usually meant.

There are practically hundreds of early articles written on program slicing and dozens of proposed slicing techniques, but we opt not to further our discussion of earlier work since slicing, just by itself, has shown limited success in fault localization. One example of an early work that attempted to improve the fault localization capabilities of slicing is the technique presented by Agrawal et al. [51]. That technique is based on dicing, a dice being the set difference of two slices. It conjectures that the fault resides in the execution slice (trace) of a failing run but does not reside in the execution slice of a passing run, an assumption that does not generally hold.

Background

The first instances of these techniques (eg, [1,2]) were clever, disruptive, and promising. Case in point, the work by Jones and colleagues [1] was awarded an ACM SIGSOFT Outstanding Research Award, and Liblit’s dissertation, which was based on [2], received an ACM Doctoral Dissertation Award. Unfortunately, however, SBFL somehow became too popular for its own good; a few years after these first and a few other innovative techniques were presented, researchers started to propose all sorts of variations on the initial idea. In most cases, these variations simply consisted of using a different formula for the ranking and showing slight improvements in the effectiveness of the approach. This trend is still in effect today, to some extent.

5 Conclusion

In this chapter, Disqover, a new fault localization technique, was presented. This technique exploits automated test case generation tools to generate a large number of test cases and implements a novel algorithm to find commonalities between the failing test cases by automatically replaying them, and extracting their sequence covers, i.e., execution traces. As debugging costs continue to be more expensive, the benefits of automated debugging and fault localization techniques will become more tangible. Nowadays, static analysis methods are so advanced and integrated in pretty much all of software development IDEs. Also, software instrumentation techniques are prevalent, and it is not uncommon to have instrumented versions of software in a production setting for various dynamic analysis purposes. However, either technique, static or dynamic, is not sufficient by itself to accurately identify software faults. Hybrid approaches can make static and dynamic approaches complement each other to achieve the best of the two worlds. In this chapter, we presented one such approach, and we hope it attracts the research community attention to the value of hybrid approaches. Such approaches are not limited to improve fault localization only, but also performance testing, memory profiling, and software structure and quality in general.

7.3 Fault Localization

Once test cases that origin from CT are executed, their unique structure consisting of parameter value combinations allows systematic fault localization. This is achieved by locating failure-triggering parameter value combinations in failing tests, known as identifying failure-inducing combinations. Since accurately identifying minimal failure-inducing combinations is a hard problem, most existing techniques come up with candidates for failure-inducing combinations, i.e., combinations that are likely to trigger failures but are not guaranteed to do so.

There are two major approaches for identifying failure-inducing combinations. The first approach takes a single failing test case as input, and isolates a minimal value combination that triggers the observed failure. Zhang and Zhang propose a fault characterization method called Faulty Interaction Characterization (FIC) and its binary search alternative FIC_BS [10]. The method uses the failing test case as a seed for the generation of additional test cases that assist in locating a failure-inducing combination that occurs in the original test case. By executing the additional test cases and observing their results, one can eliminate combinations that no longer induce the failure and narrow down on the failure-inducing ones. Complexity-wise, FIC is very efficient. Its complexity is only O(k) (where k is the number of parameters), while there are 2^K potential failure-inducing combinations in a failing test case. However, there are two important assumptions that reduce its applicability in practice: (1) there are no constraints in the model, and (2) no new failures are introduced when the failing test case is modified to produce new test cases. A different technique that eliminates these assumptions was proposed by Niu et al. [120]. By building a tuple relation tree (TRT) for a failing test case, they allow a clear view of its interactions and can also handle multiple, possibly overlapping, failure-inducing combinations.

The second approach takes a set of test cases as input and their execution results (pass/fail), and identifies failure-inducing combinations that may occur in them. Yilmaz et al. describe a fault localization technique based on machine learning [121]. It takes a covering array and its execution results as inputs and builds a classification tree that models the failing test cases. The model is evaluated by using it to predict the results of new test cases. Since the model encodes the information that will predict a failure, it assists developers in understanding the root cause of the failure.

Shi et al. propose a different fault localization technique, in which given a set of test cases and their execution results, candidates for failure-inducing combinations are identified [122]. These are combinations that appear only in failing test cases and not in passing ones. Next, for each failing test case, n additional test cases are generated to isolate its failure-inducing combination, where n is the number of model parameters. The initial candidate set is reduced based on the execution results of the additional test cases. More recently, another technique was suggested along with a tool called BEN [123–125]. In this technique, combinations are first ranked based on how suspicious they are in inducing failures. Next, additional test cases are created to refine the ranking, and the process repeats iteratively until either failure-inducing combinations are detected, or the set of suspicious combinations is empty.

15.1.3 Application of Instantaneous Frequency for Disturbance Propagation

The time of arrival of disturbance signals on high-voltage transmission lines is of great interest for relay and fault localization. Traditional fault localization in a transmission line network is based on a fault-study using voltage and current measurements. The traditional methodology is subject to inaccurate results, because the calculation depends on the rough assumption of the fault impedance and the type of fault. Power system monitoring systems employ GPS (global positioning systems) receivers to provide time synchronized data. GPS synchronized data enables one to solve the fault location problem based on time-of-arrival of the disturbance waveforms. The propagation properties of high voltage transmission lines have been carefully treated and shown to be dispersive [7]. To treat the time synchronized disturbance data, an accurate estimation of the arrival time is critical. In this section, an application example is provided to show how the instantaneous frequency can be utilized for the arrival time estimation.

As the transmission line is characterized by frequency-dependent attenuation and dispersion, different frequencies suffer different amounts of attenuation and also propagate with different phase and group velocities; consequently, the waveforms observed at different buses appear “distorted” or “dispersed” from the original waveform. Therefore, it is difficult to assign time-of-arrival for “distorted” signals. There are perhaps many ways to determine time-of-arrival; however, in this section we focus on one, namely instantaneous frequency.

5.3.2 OTN monitoring

In OTN, per-layer monitoring has been defined. OAM is supported by path-trace and loop installations. Fault localization is possible with electrical and optical supervisory signals. It is possible to detect signal degradations and switch upon these conditions. Several protection and restoration mechanisms have been, or are still being, defined for OTN. Linear (point-to-point) subnetwork connection (SNC) protection mechanisms are defined in ITU-T Recommendation G.873.1 for the ODUk level. 1+1 and 1:N linear protection are supported. Further mechanisms include trail (OCh, OMS) 1+1 protection as defined in ITU-T Recommendation G.872. Shared-ring protection for the ODUk level is defined in Recommendation G.873.2. OTN restoration is standardized in ITU-T ASON.

In Figure 5.34, three cascaded carrier and two nested vendor domains are shown. Since one TCM layer can be reused for the metro carrier domains X and Y and the vendor domain B, three TCM layers are required in total.

10.6.1 Capacitance measurement

When the center conductor of a cable is not exposed to seawater (open fault), a capacitance measurement may be used for the fault localization. The capacitance between the center conductor (copper tube) and the outside conductor (seawater) is measured, and the fault location is estimated from the test results. The cable and/or repeater parameters, which were obtained during the factory tests or commissioning and acceptance tests, are used to calculate the distance of the fault from the shore station.

6 Handling Failures

Although testing of modern web applications has received increasing attention in the recent past, there has been limited work on what happens after a test reveals an error. After a test fails, the fault localization process much be undertaken by developers in order to identify the fault responsible for the failure. However, when a web application test assertion fails, determining the faulty program code responsible for the failure can be a challenging endeavor.

AutoFlox [62] is an automated technique for localizing code-terminating DOM-related JavaScript errors—a DOM access function returns a null, undefined, or incorrect value, which then propagates into several variables and eventually causes an exception in JavaScript code execution. AutoFlox takes a code-terminating line of JavaScript code as input and performs dynamic analysis and backward slicing of the web application to localize the cause of these JavaScript faults.

When a fault is localized, the next natural step would be to repair the fault. Vejovis [64] is a technique that tries to automatically find a fix for a JavaScript fault. First, the authors try to understand common fixes applied by programmers to JavaScript faults. Based on these findings, they propose an automated technique for providing repair suggestions for DOM-related JavaScript faults.

Related to program repair are prevention techniques. For instance, Jensen et al. [65] and Meawad et al. [66] introduce techniques that transform unsafe eval calls in JavaScript code to functionally equivalent without the use of eval.

MPLS-TP OAM Procedures

MPLS-TP provides mechanisms to support in-band OAM functions such as continuity check, connectivity verification, loss measurement, delay measurement, remote defect indication, and alarm indication signal. Like legacy transport networks, these mechanisms allow for fault localization, performance monitoring, remote indications, and alarm suppression. Rather than define new OAM protocols, the MPLS-TP IETF drafts specify mechanisms (via G-Al/G-Ach) to reuse traditional MPLS and carrier Ethernet OAM procedures such as BFD and Y.1731.

The BFD and Y.1731 procedures can be used to monitor LSPs, sections, or PWs. In addition, recent IETF drafts also define Fault OAMs (AIS, RDI, and LKR) for signal failure detection, for propagation of the signal fail condition across layers, and for alarm suppression. MPLS-TP provides mechanisms to support in-band OAM functions such as continuity check, connectivity verification, loss measurement, delay measurement, remote defect indication, and alarm indication signal.