Subject: RE: non-RSVP routers.

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Mon, 4 Feb 2002 11:25:14 +0530

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:[email-masked]]
Sent: Monday, February 04, 2002 10:40 AM
To: Sean Crocker
Cc: Subhakar K S; Ajay Simha; [email-masked]
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.

---

From: "Kiran G. R." <[email-masked]>
Date: Mon, 4 Feb 2002 11:35:24 +0530

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 : [email-masked]   

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:[email-masked]]
Sent: Monday, February 04, 2002 11:10 AM
To: Sean Crocker
Cc: Subhakar K S; Ajay Simha; [email-masked]
Subject: Re: non-RSVP routers.

LSA/LSPs

---------------

eric

---

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Mon, 4 Feb 2002 11:45:59 +0530

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:[email-masked]]
Sent: Monday, February 04, 2002 11:05 AM
To: Eric Osborne; Sean Crocker
Cc: Subhakar K S; Ajay Simha; [email-masked]
Subject: RE: non-RSVP routers.

Hi Eric, 

Thank U for UR time, 
Regards, 

G.R.Kiran 
Software Engineer 

-Martin Luther King, Jr. 

-----Original Message----- 
From: Eric Osborne [ mailto:[email-masked] <mailto:[email-masked]> ]

LSA/LSPs 

--------------- 

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.

---

From: "Sean Crocker" <[email-masked]>
Date: Mon, 4 Feb 2002 00:17:38 -0600

>be explicitly spelled out for this particular object.

That covers the case of a "classic" RSVP node that doesn't do RSVP-TE,
whereas this discussion so far is of non-RSVP nodes.  Two different
situations.  A non-RSVP node isn't going to know what a c_type is.

Sean

---

From: "Sean Crocker" <[email-masked]>
Date: Mon, 4 Feb 2002 00:36:27 -0600

>implementation also and would appreciate any further light in this regard. 

I don't think there's a way for the transit node to detect a downstream
non-rsvp node unless it were downstream for a previous unsuccessful
PATH in the opposite direction, and you can't depend on that.

It'll just have to depend on the next RSVP-TE node to detect the non-
RSVP node(s) and send back PATHERR 24/8.  If that doesn't happen (which
is true for some implementations), then the transit node will just sit
there with a PSB that keeps getting refreshed by the sender... until
-as Ajay said- someone comes along and figures out why.

Sean

---

From: "Gopinath G - CTD, Chennai." <[email-masked]>
Date: Tue, 5 Feb 2002 11:10:17 +0530

Hello,

    I hope LSA's of IGP may help to find the next hop is RSVP capable or
not... 

pls corect me  if I am wrong

gopinathg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, February 02, 2002 11:53 PM
To: Subhakar K S
Cc: [email-masked]
Subject: Re: non-RSVP routers.

Hello,

Please see the last paragraph in RFC 2205, section 3.8:

"With normal IP forwarding, RSVP can detect a non-RSVP hop by comparing
the IP TTL with which a Path message is sent to the TTL with which it is
received; for this purpose, the transmission TTL is placed in the common
header.  However, the TTL is not always a reliable indicator of non-RSVP
hops, and other means must sometimes be used.  For example, if the routing
protocol uses IP encapsulating tunnels, then the routing protocol must
inform RSVP when non-RSVP hops are included.  If no automatic mechanism
will work, manual configuration will be required."

However, RSVP-TE will not work with non-RSVP routers.  Please see section
4.2.5 of RFC 3209.

Thanks,
-Ben

On Fri, 1 Feb 2002, Subhakar K S wrote:

>
> How does an intermediate router finds if its
> downstream router is RSVP aware or not.
>
>
> thanks,
> S.
>
> __________________________________________________
> Do You Yahoo!?
> Great stuff seeking new owners in Yahoo! Auctions!
> http://auctions.yahoo.com
>

---

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Tue, 5 Feb 2002 11:36:12 +0530

Hi 

 I don't think IGP LSA's have any such field which 
 tells signalling protocol is enabled or not. 
 ( Note that it can even be LDP not necessarly RSVPTE )

Ashwin

-----Original Message-----
From: Gopinath G - CTD, Chennai. [mailto:[email-masked]]
Sent: Tuesday, February 05, 2002 10:40 AM
To: [email-masked]
Subject: RE: non-RSVP routers.

Hello,

gopinathg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, February 02, 2002 11:53 PM
To: Subhakar K S
Cc: [email-masked]
Subject: Re: non-RSVP routers.

Hello,

Thanks,
-Ben

---

From: "Gopinath G - CTD, Chennai." <[email-masked]>
Date: Tue, 5 Feb 2002 12:25:28 +0530

Hello 
   
  Section 3.7 (Link Capability/Resources)  of
www.ietf.org/internet-drafts/draft-bitar-rao-ospf-diffserv-mpls-01.txt
<http://www.ietf.org/internet-drafts/draft-bitar-rao-ospf-diffserv-mpls-01.t
xt> 
specifies bits for cr-ldp,rsvp-te etc .. signifies the protocol is
enable/disable for that link.   
 
Does OSPF will advertise the same if the Diffserv through MPLS is disable
and rsvp-te/cr-ldp is enabled ?

gopinathg

-----Original Message-----
From: Ashwin C. Prabhu [mailto:[email-masked]]
Sent: Tuesday, February 05, 2002 11:36 AM
To: Gopinath G - CTD, Chennai.; [email-masked]
Subject: RE: non-RSVP routers.

Hi 

Ashwin 

-----Original Message----- 
From: Gopinath G - CTD, Chennai. [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, February 05, 2002 10:40 AM 
To: [email-masked] 
Subject: RE: non-RSVP routers. 

Hello, 

gopinathg 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Saturday, February 02, 2002 11:53 PM 
To: Subhakar K S 
Cc: [email-masked] 
Subject: Re: non-RSVP routers. 

Hello, 

Thanks, 
-Ben 

On Fri, 1 Feb 2002, Subhakar K S wrote: 

> http://auctions.yahoo.com <http://auctions.yahoo.com>  
>