The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Nov> msg00153



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Hello Extension - destination IP address

  • From: Ping Pan <pingpan@juniper.net>
  • Date: Thu, 15 Nov 2001 09:30:05 -0800
  • CC: MPLS Mailing List <mpls@UU.NET>
  • User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2

David,

David Charlap wrote:

> 
> No.  The purpose is exactly opposite.  The purpose of RSVP Hello is to
> terminate connections earlier than they would otherwise be terminated
> (via soft-state timeouts.)
> 


Agree. In addition, for interfaces where the hardware cannot generate 
interface up/down signal (such as Ethernet), Hello is used for the LSR 
to detect the status of the RSVP logic connection with a "neighbor". If 
the connection is down, RSVP needs to reroute the traffic for all 
effected sessions....


> The only way to keep a connection alive is to refresh it (using the
> features of RFC 2961, if available.)

> 


Yes. And RSVP refresh intervals can be different at every link, and can 

be dynamically adjusted when using refresh reduction.


> 
> I've always pictures RSVP Hello as something that can run independantly
> of the rest of RSVP, issuing "tear all state of this interface" commands
> to RSVP when Hello detects a neighbor failure.
> 


Exactly.


> In this sense, if non-Hello packets have an affect of Hello processing
> it can be thought of as snooping.  But you're right that this sense is
> not necessarily applicable, depending on how you visualize the protocol
> and/or implement it.
> 


In this regard, RSVP Hello works similar to that of BGP. RSVP neighbors 
(peers) aliveness can be maintained via RSVP messages other than Hello. 
But if there is no other RSVP messages on the wire, Hello is the one to use.


> -- David
> 


Take care!

- Ping