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

Multi-Service IronWare Multiprotocol Label Switch (MPLS) Configuration Guide 377
53-1003031-02
RSVP-TE Hello
2
Vital Fractions for RSVP-TE Hello
The Hello extension is composed of three parts:
• Hello Message
• Hello REQUEST object
• Hello ACK object
Each neighbor can individually issue Hello REQUEST objects. Each request may be answered by an
Hello ACK object. The Hello extension is designed so that one side can use the mechanism while
the other side does not. All messages may be ignored by nodes which do not wish to participate in
Hello message processing. If a particular peer never responds to Hello messages, Brocade routers
do not assume that the peer is dead, but simply assume that it does not support Hello messages.
The Hello message has a Msg Type of 20 with a message format as follows:
Hello Message : := Common Header [ INTEGRITY ]
Hello
Working of RSVP-TE Hello feature
Considering both sides of a link support and wish to participate in Hello message processing, the
following is the processing of the feature.
10. A node periodically generates a Hello message containing a HELLO REQUEST object for each
neighbor whose status is being tracked. The periodicity is governed by the hello-interval. 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.
11. 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.
12. 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_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, then
the node treats the neighbor as if communication has been lost.
13. 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.