The MPLS WG Archive

[Eric Osborne <eosborne@cisco.com>]

On Sun, Feb 03, 2002 at 11:25:38AM -0600, Sean Crocker wrote:
> >On Fri, 1 Feb 2002, Subhakar K S wrote:
> >
> >SKS>
> >SKS>How does an intermediate router finds if its
> >SKS>downstream router is RSVP aware or not.
> >
> >In the context of MPLS-TE if we configure TE we should enable RSVP at the
> >seme time.  If we go with this assumption, then if we receive IGP LSA/LSPs
> >describing a link then we can assume it has RSVP turned on.
> >
> >Of course if this is not the case we'll know when we don't receive RESV
> >messages after we send PATH messages :-)
> 
> If for some reason the sender didn't do CSPF (and use the IGP-TE info)
> before sending PATH, hopefully the node that's downstream to the non-
> RSVP node will send back PATHERR with an error code 24 (Routing Problem)
> subcode 8 (non-RSVP-capable router stands in the path).


I don't think so....see rfc3209.  An mpls-te Path message isn't going
to be of much use without a LABEL_REQUEST object, and the unrecognized
object should be rejected.  This implies that the Class-Num for
label_request is of the form 0bbbbbbb, although that doesn't seem to
be explicitly spelled out for this particular object.

---------------
4.2.5. Non-support of the Label Request Object

   An RSVP router that does not recognize the LABEL_REQUEST object sends
   a PathErr with the error code "Unknown object class" toward the
   sender.  An RSVP router that recognizes the LABEL_REQUEST object but
   does not recognize the C_Type sends a PathErr with the error code
   "Unknown object C_Type" toward the sender.  This causes the path
   setup to fail.  The sender should notify management that a LSP cannot
   be established and possibly take action to continue the reservation
   without the LABEL_REQUEST.
----------------




eric