Brocade Multi-Service IronWare Multiprotocol Label Switch (MPLS) Configuration Guide (Supporting R05.6.00) - Manual (Page 402)

378 Multi-Service IronWare Multiprotocol Label Switch (MPLS) Configuration Guide
53-1003031-02
RSVP-TE Hello
2
14. 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_Instance value 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.
15. 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.
16. 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. Range for hello-tolerance is 1 to
255.
17. When communication is lost or presumed to be lost, a node may re-initiate HELLOs. If a node
does re-initiate, it must use a Src_Instance value 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_Instance value field.
For those sessions going over the interface on which a neighbor down is detected, the following
actions are taken on the basis of the nature of the LSP:
• For RSVP sessions with no backup available, these sessions are brought down.
• For RSVP sessions with available backups, FRR switchover is performed.
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.
Risk assessment
Configuring hello-interval on both ends of a link
The hello-interval command at an mpls-interface level is used to configure the interval time for
sending RSVP-TE Hello Request messages. Configuring the Hello-interval allows the interface to
initiate Hello Request messages. When both ends of the link are configured to respond to RSVP-TE
Hello messages, the neighbor on receiving the Request message generates a ACK message.
Configuring hello-interval only on one end of a link
The hello-interval command at an mpls-interface level is used to configure the interval time for
sending RSVP-TE Hello Request messages. If the neighbor does not wish to participate in RSVP-TE
Hello message communication, it can ignore the Hello Request messages. The neighbor may send
out the ACKs only if it chooses to participate in the RSVP-TE Hello messages. If a particular peer
never responds to Hello messages, do not assume that the peer is dead, but simply assume that it
does not support Hello messages.