failed (or not sent any message at all). This could introduce extremely large delays into the propagation of the error to a repair point. GMPLS introduces a new message to RSVP-TE only to enhance this notification process. The Notify message is sent directly from the point of failure detection to the point of repair. In Figure 8-4, when the black LSP fails, a Notify message is sent direct to the initiator. This message is sent directly to the initiator and does not have the IP Router Alert flag set, so it is not intercepted by transit nodes that are MPLS capable. It may option- ally use IP double encapsulation. It uses regular IP routing to take the best route to the initiator. If the LSP is bidirectional, a Notify message is also sent to the termina- tor to enable it to switch its data flow to the backup path. This message is sent by the node that detects the error on the terminator side of the failed link. In fact, there is no reason why the repair points should be limited to the initiator and terminator LSRs. In Figure 8-4, the gray LSP is protected by a shorter backup segment shown by a dashed line. An LSR that wants to be told about LSP failure adds an object containing its own address to the Path or Resv message as it passes through. This object specifically requests the use of Notify messages and identifies the recipient of the message. The Path message identifies the Notify recipient on the initiator side, and the Resv indicates the Notify recipient on the terminator side. As the Path or Resv flows through the network, the LSRs may change the Notify recipient and may even change whether or not a Notify is requested. This enables multiple repair points to be defined for an LSP. Finally, it is possible that the most efficient use of Notify is to send it to a network device that can recalculate a path for the LSP and communicate it to the initiator using a management protocol (such as the Simple Net- work Management Protocol [SNMP]). In this case, the Notify recipient might be entirely distinct from the LSRs