The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Feb> msg00009



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

non-RSVP routers.

  • From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
  • Date: Mon, 4 Feb 2002 11:25:14 +0530
  • Cc: Subhakar K S <subhakar_ks@yahoo.com>, Ajay Simha <asimha@cisco.com>, mpls@UU.NET

Title: RE: non-RSVP routers.


Hello

  There is Send_TTL in the Common Header field of RSVP
  Packet forwarding is done through ip, so if the
  downstream node is non rsvp the packet is forwarded to the
  next node. Suppose the next to next node is rsvp capable then
  that node can detect that the message has traveresed the non rsvp
  capable router by looking at the differance of IP TTL and the
  Send_TTL in the RSVP message.
  Hope i am right and this helps you.


Ashwin


 
-----Original Message-----
From: Eric Osborne [mailto:eosborne@cisco.com]
Sent: Monday, February 04, 2002 10:40 AM
To: Sean Crocker
Cc: Subhakar K S; Ajay Simha; mpls@UU.NET
Subject: Re: non-RSVP routers.


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

--------------------------------------------------------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please notify the
originator of the message.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Huawei Technologies India Pvt. Ltd.