imum, even with a relatively short interval for the retry timer. This mechanism gives the benefit of much improved reliability of message Chapter 8 transmission, without significantly increasing the overhead of running RSVP. Figure 8-3 illustrates the use of message IDs and ACKs. Reduced Refresh Processing An important consequence of the mes- sage ID mechanism is that a given message ID can be used as a handle to the contents of the message: If a Path or Resv message is being sent to refresh state in a neighboring node, then the same message ID is used again. When an LSR receives a Path or Resv with the same message ID as before, it indicates that the message is a simple refresh message, and the LSR can avoid processing the remaining message contents. As the payload of RSVP messages increases, it becomes increasingly important to avoid the full processing of refresh messages. Message IDs are 32-bit quantities. They are allocated by the sender in ascending order from some starting point (except in the case of refresh mes- sages, as noted previously). This enables the receiver to detect and ignore messages that have arrived out of sequence. This mechanism also copes with nodes failing and potentially resetting the sequence numbers by including a randomly chosen epoch value on each message. If this value changes, peer nodes can interpret the message IDs appropriately. Refresh Reduction Message IDs provide a simple way to reduce the processing load on the receiver by identifying refresh messages, but this still requires the sender to generate and send a complete RSVP message. Summary refresh (Srefresh) messages build on message IDs and provide a way to reduce the load on the sender and network as well. The sender batches up previously sent message IDs for state that it wants to refresh in a neighboring node, which could be Path state, Resv state, or a mixture Path A1 Figure 8-3 Message IDs in use. Path A1 (resent) Resv B1 [Ack A1] Ack B1 GMPLS in Optical Networks of the two. The message IDs are then sent as a simple 