The Resource Reservation Protocol (RSVP) is a soft-state protocol. RSVP-TE periodically updates RSVP messages to maintain the resource reservation states on nodes.
Resource reservation states include the path state and the reservation state. RSVP nodes along an established CR-LSP periodically send Path and Resv messages (collectively called RSVP Refresh messages) to maintain the path and reservation states. RSVP Refresh messages are used to synchronize path state block (PSB) and reservation state block (RSB) between RSVP nodes. If an RSVP node does not receive any Refresh message within a specified period, it deletes the path or reservation state.
RSVP Refresh
RSVP sends its messages as IP datagrams, which cannot ensure a reliable delivery. After a CR-LSP is set up, the soft state mechanism synchronizes the PSB and RSB between RSVP neighbors. Each node periodically sends RSVP Refresh messages to its upstream and downstream nodes.
Refresh messages carry information that has already been advertised. The Time Value field in Refresh messages specifies the refresh interval.
If a node does not receive any Refresh message about a certain state block after the specified refreshing intervals elapses, it deletes the state.
A node can send Path and Resv messages to its neighbors in any sequence.
RSVP Srefresh
In addition to state synchronization, RSVP Refresh messages can also be used to detect reachability between RSVP neighbors and maintain RSVP neighbor relationships. Because Path and Resv messages are large, sending many RSVP Refresh messages to establish a large number of CR-LSPs consumes excess network resources. RSVP Summary Refresh (Srefresh) can address this problem.
Message_ID extension and retransmission
The Message_ID extension extends objects carried in RSVP messages. Among the objects, the Message_ID and Message_ID_ACK objects acknowledge received RSVP messages to ensure reliable RSVP message delivery.
The Message_ID object can also provide the RSVP retransmission mechanism. A node resets the retransmission timer (Rf seconds) after sending an RSVP message carrying the Message_ID object. If the node receives no ACK message within Rf seconds, the node retransmits an RSVP message after (1 + Delta) x Rf seconds. The Delta value depends on rate at which the sender increases the retransmission interval. The node keeps retransmitting the message until it receives an ACK message or the retransmission count reaches the threshold (retransmission multiplier).
Srefresh messages transmission
Srefresh messages can be sent instead of standard Path or Resv messages to update RSVP states. These messages reduce the amount of information that must be transmitted and processed for maintaining RSVP states. When Srefresh messages are sent to update the RSVP states, standard Refresh messages are suppressed.
Each Srefresh message carries a Message_ID object, which contains multiple message IDs to identify the Path and Resv states to update. Srefresh implementation depends on the Message_ID extension. Srefresh messages can only update the states that have been advertised in Path and Resv messages containing Message_ID objects.
When a node receives a Srefresh message, the node compares the Message_ID in the message with that saved in the local PSB or RSB. If the two Message_IDs match, the node updates the local state block, just like it receives a standard Path or Resv message. If they do not match, the node sends a Srefresh NACK message to the sender. Later, the node updates the Message_ID and the state block based on the received Path or Resv message.
A Message_ID object contains a message identifier. When a CR-LSP changes, the message identifier increases. A node compares the message identifier in the received Path message with the message identifier saved in the local state block. If they are the same, the node does not update the state block. If the received message identifier is larger than the local message identifier, the node updates the state block.
PathErr message: is sent by an RSVP node to its upstream node if an error occurs while this node is processing a Path message. The message is forwarded upstream by intermediate nodes and finally reaches the ingress node.
ResvErr message: is sent by an RSVP node to its downstream node if an error occurs while this node is processing a Resv message. The message is forwarded downstream by intermediate nodes and finally reaches the egress node.
After the ingress node receives a PathErr message or an instruction to delete a CR-LSP, it immediately sends a PathTear message downstream. After receiving this message, the downstream nodes tear down the CR-LSP and reply with a ResvTear message.
PathTear message: is sent to delete path information and functions in the opposite way to a Path message.
ResvTear message: is sent to delete the resource reservation state and functions in the opposite way to a Resv message.