tion) along with information about the link type. The results of the link property correlation process are Confirmation that the mappings between local and remote interface IDs are consistent between the LMP nodes (which is particularly important where the mappings have been preconfigured rather than dynamically determined via link verification) Confirmation that the aggregation of data links into traffic-engineering links is consistent between the adjacent LMP nodes Agreement on the properties and capabilities of the data channels The aggregation of data links into traffic-engineering links is illustrated in Figure 8-9. GMPLS in Optical Networks Figure 8-9 Traffic-engineering link mappings. Node A Node B Local Remote Local Remote 8.6.5 Fault Detection Many photonic optical switches are transparent in the sense that they prop- agate the light signal without any interference. They can switch data by fiber, wavelength, or time slot without needing to examine the actual signal at all. Consequently, if the signal disappears because of a fault somewhere upstream, the switch may not even notice. In the typical worst case, the absence of the signal is only detected when it needs to be converted back to electronic form for forwarding over a packet-switched network. Then, the only information is that there is a fault on one of the optical links somewhere upstream from the LSP through which packets were expected to arrive. LMP fault detection is used in this scenario to localize the link on which the fault occurred. It proceeds as follows: 1. The process is initiated by the downstream node, which first notices failure on a data link. 2. This node sends a ChannelFailure message to its upstream neighbor for that link. 3. The upstream node determines which incoming/upstream data link(s) connects to the failed outgoing/downstream data link. 4. If the corresponding incoming data link has also failed, then the upstream node responds with a ChannelFailureAck and propagates the fault detection process by sending a new ChannelFailu