ed, as illustrated in the figure. Note that there is no mention of the upstream label on the Resv. 8.5.2 Confirming the Forward Path One concern with the process described previously is that the GMPLS spec- ifications state that when the LSP Setup Request (Path message) reaches the terminator, the reverse data path must be considered to have been established and data can immediately start to flow. Delay at the Terminator Node In order to guarantee this, each LSR the path might consider that it has to wait until its switch is fully pro- grammed before it forwards the LSP Setup Request toward the termina- tor. This would result in slow LSP setup as each switch may take a considerable amount of time to stabilize. This defeats the purpose of label suggestion. Alternatively, the LSRs on the path could simply forward the LSP Setup Request as soon as they have checked that programming the switch is likely to succeed and continue with the programming in the background. This relies on several procedures: Prior to sending data, the terminator LSR must leave a small amount of time for other LSRs to become successfully programmed. This time might be no longer than it takes to program its own switch, but it could be longer in a network made up of switches from different vendors. Programming errors at transit LSRs must be immediately reported as LSP failures, and the terminator LSR must be prepared to handle these error notifications even if they arrive ahead of the original programming request. This approach enables the LSP setup time to converge on the unidirec- tional LSP setup time described previously, but it requires shared knowl- edge and cooperation between the switch implementations at the transit LSRs. ResvConf A more secure solution is available in RSVP-TE and uses the ResvConf message. This message flows in the same direction as a Path mes- GMPLS in Optical Networks sage and confirms the receipt at the initiator of the Resv message. The ter- minator requests it by a flag on the Resv message. The terminator can use 