RSVP-TE Hello Process

When both sides of a link support wish to participate in Hello message processing, the RSVP-TE Hello process follows this procedure.

  1. A node periodically generates a Hello message containing a HELLO REQUEST object for each neighbor whose status is being tracked. The hello-interval governs this periodicity. There is support for each interface configuration of RSVP-TE HELLO to be flexible. This value may be configured on a per-interface basis. The default value is nine seconds, and the configurable range of hello-interval is 1 to 60 seconds.
  2. When generating a message containing a HELLO REQUEST object, the sender fills in the Src_Instance field with a value representing its per neighbor instance. This value does not change while the agent is exchanging Hellos with the corresponding neighbor. The sender also fills in the Dst_Instance field with the Src_Instance value most recently received from the neighbor. For reference, refer to this variable as the Neighbor_Src_Instance. If no value has ever been received from the neighbor or this node considers communication to the neighbor to have been lost, the Neighbor_Src_Instance is set to zero (0). The generation of a message must be suppressed when a HELLO REQUEST object is received from the destination node within the prior hello-interval interval.

  3. On receipt of a message containing a HELLO REQUEST object, the receiver generates a Hello message containing a HELLO ACK object. The receiver also verifies that the neighbor has not reset. This is done by comparing the sender's Src_Instance field value with the previously received value. If the Neighbor_Src_Instancevalue is zero, and the Src_Instance field is non-zero, the Neighbor_Src_Instance is updated with the new value. If the value differs, then the node treats the neighbor as if communication has been lost.

  4. The receiver of a HELLO REQUEST object also verifies that the neighbor is reflecting back the receiver's Instance value. This is done by comparing the received Dst_Instance field with the Src_Instance field value most recently transmitted to that neighbor. If the neighbor continues to advertise a wrong non-zero value after a configured number of intervals (hello-tolerance), then the node must treat the neighbor as if communication has been lost.

  5. On receipt of a message containing a HELLO ACK object, the receiver must verify that the neighbor has not reset. This is done by comparing the sender's Src_Instance field value with the previously received value. If the Neighbor_Src_Instancevalue is zero, and the Src_Instance field is non-zero, the Neighbor_Src_Instance is updated with the new value. If the value differs or the Src_Instance field is zero, then the node must treat the neighbor as if communication has been lost.

  6. The receiver of a HELLO ACK object must also verify that the neighbor is reflecting back the receiver's Instance value. If the neighbor advertises a wrong value in the Dst_Instance field, then a node must treat the neighbor as if communication has been lost.
  7. If no Instance values are received, through either REQUEST or ACK objects, from a neighbor within a configured number of hello-intervals (hello-tolerance), then a node must presume that it cannot communicate with the neighbor. The default for this number is three (3). So, the time-out is equal to three times the retransmission period. The range for hello-tolerance is 1 to 255.

  8. When communication is lost or presumed to be lost, a node may re-initiate HELLOs. If a node does re-initiate, t must use a Src_Instancevalue different than the one advertised in the previous HELLO message. This new value must continue to be advertised to the corresponding neighbor until a reset or reboot occurs, or until another communication failure is detected. If a new instance value has not been received from the neighbor, then the node must advertise zero in the Dst_Instancevalue field.
For those sessions going over the interface on which a neighbor down is detected, the following actions are taken by the nature of the LSP:

The HELLO mechanism is intended for use between immediate neighbors. So, when the HELLO messages are being exchanged between immediate neighbors, the IP TTL field of all outgoing HELLO messages is set to 1.