The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Jul> msg00371



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

RFC3209 Section 4.1.2

  • From: David Charlap <david.charlap@marconi.com>
  • Date: Thu, 25 Jul 2002 11:41:30 -0400
  • User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719

Hong Liao wrote:
> 
> In RFC3209 Section 4.21.2 non-support of the label object.
> 
> 4.1.2. Non-support of the Label Object
> 
>    Under normal circumstances, a node should never receive a LABEL
>    object in a Resv message unless it had included a LABEL_REQUEST
>    object in the corresponding Path message.  However, an RSVP router
>    that does not recognize the LABEL object sends a ResvErr with the
>    error code "Unknown object class" toward the receiver.  This causes
>    the reservation to fail.
> 
> For example,
> 
> A  -------LSR--------B
> 
> If the A sent out a Path msg without the LRO, LSR will forward this path
> msg to B, then if B sent a Resv msg with a Label object, will the LSR send
> the Resverr msg with the error code "Unknown object class" toward B?

If A didn't send a LABEL_REQUEST, and B sent back a LABEL anyway, then B 
is broken.

No LSP can possibly come up, because A wasn't trying to establish one in 
the first place.  It is absolutely correct for A to generate a ResvErr.

> I do think so unless LSR is non-support the LABEL object.

If A generated a Path without a LABEL_REQUEST, then either it is not 
running RSVP-TE (meaning the LABEL object definitely isn't supported), 
or it is a hybrid router, running both classical RSVP and RSVP-TE at once.

If it is such a hybrid, then the decision of what to do with an 
unexpected LABEL object is not specified.  Personally, I think the 
ResvErr should still be generated, since that's what a non-TE router 
would do for the exact same session.

-- David