 that make up the LSP. Chapter 8 Reporting Multiple Failed LSPs As described previously, one of the principle concerns with using PathErr to report LSP failures is that a sin- gle link failure may impact many LSPs, causing the need to send one PathErr message for each LSP. This could cause a data spike on the con- trol channel and might cause temporary resource shortages in the LSRs that process the messages. For this reason, the Notify message is defined SO that it can report mul- tiple LSPs at once. The only constraints are as follows: All failed LSPs on a single Notify message must have failed with the same reason code. Only one error spec is present and refers to all the reported LSPs. All failed LSPs on a single Notify must have the same Notify recipient (repair point). State Removal on PathErr RSVP specifies that errors are notified to upstream nodes using PathErr messages and to downstream nodes using ResvErr messages. When the ingress receives a PathErr, it may Ignore the error, enabling state refresh to repair any damage. Reissue a Path message with different parameters that have a better chance of success. Tear the reservation by sending PathTear. This approach is somewhat inefficient after a serious failure because two message flows are needed: the PathErr flow and the PathTear flow. GMPLS introduces an option on a PathErr message to report that state has been removed at the sending node. That is, the flag indicates that the LSR that sent the PathErr has deprogrammed the switch for the LSP and has released all control blocks for the LSP. The State Removed flag is applied on a hop-by-hop basis. When an LSR receives a PathErr with the flag set, it must send a PathErr upstream. It may choose whether to set the flag on the PathErr that it sends. If it does not set the flag on the PathErr it sends, it may also choose to store the fact that it received the flag from the downstream LSR. Figure 8-5 shows the flow of messages for a failed LSP. In the example, the node that detects the error sends a Notify messa