te following a link failure. This just leaves the issue of how to ensure the delivery of RSVP-TE sig- naling messages to the next hop. (There is no corresponding issue for CR- LDP because CR-LDP uses TCP to send signaling messages.) Nothing is yet standardized for this question, but most current reports seem to favor the encapsulation approach, either IP in IP, as described previously, or Generic Routing Encapsulation (GRE), as described in RFC 2784. 8.4 Reducing Signaling Latency and Overhead The performance characteristics of optical networks are often quite differ- ent from the electronically switched packet networks for which MPLS was originally developed: The time needed to set up an optical LSP may be longer than for a corresponding packet-switched LSP because of the mechanics of optical switch hardware. On the other hand, optical networks are particularly stable-once an LSP through an optical network has been established, it is likely to stay established for a long time. If an optical link fails, the discrepancy between the speed of the data path and the speed of signaling messages means that the standard MPLS error messages are not efficient tools for reporting and recovering from the failure. The following subsections explore how GMPLS has evolved to take these performance characteristics into account and work well with them. 8.4.1 Switch Programming Latency The normal procedure for MPLS has the switch programmed when the sig- naling response is received. That is, the signaling request progresses through the network hop by hop from ingress to egress and then the sig- GMPLS in Optical Networks naling response travels from egress to ingress, causing the switch to be pro- grammed as it goes. When the response reaches the ingress, the whole LSP is programmed and data may start to flow immediately. Part of the reason for doing this is that labels are allocated by the down- stream node on each hop, easing contention issues. Hence, on each hop, the label is not known by that hop's upstream LSR until the respons