The MPLS WG Archive

["Ashwin C. Prabhu" <Ashwinp@in.huawei.com>]

Title: RE: non-RSVP routers.

Hi

 

   The next node need not be RSVP capable so as i said earlier it is detected by the next rsvp capable

   router. ( Need not be the subsequent router but any next rsvp capable router. )

  When it finds there is some difference in the Send_TTL and the ip TTL the router node knows that

  it has traversed the non-rsvp capable router and hence sends back the Path Error with non rsvp capable

  router in between ( I don't know exactly what error code it is ). Thus the router comes to know that

  there is non rsvp capable router. The decision to setup the path or not left to the implementation since

 it definatly afftect the quality of service because of non rsvp capable router.

 The timer may not expire, since its not necessary that the next router should be rsvp capable, if it is

 then the qos will get affected.

 

 

Ashwin

 

-----Original Message-----
From: Kiran G. R. [mailto:Kiran_GR@in.huawei.com]
Sent: Monday, February 04, 2002 11:05 AM
To: Eric Osborne; Sean Crocker
Cc: Subhakar K S; Ajay Simha; mpls@UU.NET
Subject: RE: non-RSVP routers.

Hi Eric,
        with reference to the explaination given below I have a doubt.
The extract given about "4.2.5. Non-support of the Label Request Object" speaks only about a TE implementation wherein the LABEL_REQUEST object is bound to be recognized and irregularities are only in terms of faulty CLASS NUMs etc. But as such this  does not take into consideration the plain RSVP implementation which would be unable to identify the LABEL_REQUEST object. 

        Firstly I wish to know if the transit router just before the Non-RSVP router has to rely only on the expiry of timers to begin propogation of a PATHERR or can this information be relayed by some other means. Secondly even if the timers expire, how exactly will this transit router realize that it has to formulate the PATHERR message with the value "code 24 (Routing Problem)subcode 8 (non-RSVP-capable router stands in the path) " , as the case would be the same even if the next router is down (and HELLO has been enabled). This is one issue which has crept up in our implementation also and would appreciate any further light in this regard.

Thank U for UR time,
Regards,

G.R.Kiran
Software Engineer
HUAWEI Technologies India Pvt. Ltd.
Leela Galleria, Airport Road,
Bangalore                                                                               
e-mail : kiran_gr@in.huawei.com  

The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands at times of challenge and controversy.

-Martin Luther King, Jr.

-----Original Message-----
From: Eric Osborne [mailto:eosborne@cisco.com]
Sent: Monday, February 04, 2002 11:10 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.

--------------------------------------------------------------------------------------------------------------------
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.