The MPLS WG Archive

["Philip Matthews" <philipma@nortelnetworks.com>]

George:

Thanks for your reply.
I think I understand the refresh mechanism in your draft now.

I had mistakenly thought that a node implementing RSVP-TE
needed to check that the PHOP and NHOP were directly adjacent
(in order to ensure the LSP was not set up through a non-RSVP-TE
node). However, from your reply, and a re-read of RFC2205,
I now understand that the correct test is for the node receiving
the Path message to check that the TTL field in the IP header
against the Send_TTL in the common header. No check is necessary
on received Resv messages.

When refreshing over a bypass tunnel, the TTL will not be
decremented inside the tunnel, so the Path message will still
pass the TTL check at the merge node.

As for the Resv message, it will be sent back over whatever
path still exists between the merge node and the PLR. Its
destination address is the PLR node, so the intervening
nodes will forward it with any further processing.
(While IGP routing is reconverging, the Resv messages may be
lost, but assuming a generous refresh interval, the IGP should
reconverge before the Path and Resv state times out).

Thanks again.

- Philip


George Swallow wrote:
> 
> > Isn't this non-standard behavior? As I understand things, basic RSVP-TE (without
> > any hierarchy extensions), requires neighbors to be adjacent.
> 
> RSVP-TE builds on RFC2205.  The assumption there was that a network
> may have a mix of RSVP capable and non-RSVP capable nodes.  If a Path
> message is sent to a non-RSVP node, it simply passes through to the
> next node.  If that node (or some subsequent node) is RSVP capable,
> then it does normal processing.  When a Resv message comes, it will be
> forwarded back according to the PHOP.
> 
> > Path and Resv messages
> > are addressed to the head end and tail end of the tunnel respectively,
> 
> Path messages are addressed to the tail of the tunnel.  Resv messages
> are address to the PHOP of the corresponding Path message.
> 
> > and are processed hop-by-hop as they proceed through the network.
> 
> They may or may not be processed hop-by-hop.
> 
> > George claimed at the WG meeting in Minneapolis that no protocol
> > extensions were required to implement this draft. The above seems to
> > be in conflict with that claim.
> >
> > George: Any comments?
> 
> I stand by my claim.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824