Subject: Question about Label allocation in RSVP-TE

From: "Quan Sun" <[email-masked]>
Date: Fri, 20 Apr 2001 11:53:33 -0400

A dumb question, but still a bit confusing for me when reading the RSVP TE 
draft: when you receive a Path message, (a) you immediately allocate a label 
for the upstream link and save it for later use (this label will be later 
put to the RESV message coming from the downstream node), or (b)the label is 
only allocated after a RESV message has come.

If you read RSVP draft Section 4.1.1 (Handling Label Objects in Resv 
Messages), you understand the above (b) is the case. When you read Section 
4.2.4 (Handling of LABEL_REQUEST), you have a feel that the label is 
attempted to be allocated when you receive the Path message (The draft says: 
"A node that recognizes a LABEL_REQUEST object, but that is unable to 
support it (possibly because of a failure to allocate labels) SHOULD send a 
PathErr...). At least, I know of a MPLS vendor who uses the above case (a).

Or, this is an implementation specific issue?

Quan

that later this label will be put to the LABEL object in the RESV message, 
for puting to the RESV message  Consider the following simple topology:

--- LER1 --- LSR --- LER2 ---

(1) LER1 first sends a Path message to LSR

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

---

From: David Charlap <[email-masked]>
Date: Fri, 20 Apr 2001 13:44:04 -0400

Quan Sun wrote:
> 
> A dumb question, but still a bit confusing for me when reading the
> RSVP TE draft: when you receive a Path message, (a) you immediately
> allocate a label for the upstream link and save it for later use
> (this label will be later put to the RESV message coming from the
> downstream node), or (b)the label is only allocated after a RESV
> message has come.

It doesn't matter.  You can't send the label to the upstream peer until
after the Resv arrives.  What you do inside your box is not something
that RFCs should be dictating.

As with pre-reserving resources, there are advantages to both
techniques.

If you reserve the label during Path processing....

1: You won't have to take the time to reserve it when the Resv
   arrives.  Depending on your architecture, this might improve LSP
   setup times.

2: After successfully reserving the label, you won't have to worry
   about some other LSP taking the last one before your Resv arrives.

3: You will have to deal with the possibility of not having any labels
   available during Path processing.  Do you send back an error?  Or
   do you wait for the Resv and then try again? (in case another LSP
   was torn during that time.)

4: If you successfully allocate the label, and then the Path is torn
   before the Resv arrives, the allocation was wasteful.  The label
   was never needed, because no data arrived.  In a heavily-loaded
   situation, this may have prevented another LSP from coming up.

> Messages), you understand the above (b) is the case. When you read
> Section 4.2.4 (Handling of LABEL_REQUEST), you have a feel that the
> label is attempted to be allocated when you receive the Path message
> (The draft says: "A node that recognizes a LABEL_REQUEST object, but
> that is unable to support it (possibly because of a failure to
> allocate labels) SHOULD send a PathErr...). At least, I know of a
> MPLS vendor who uses the above case (a).
> 

Implementation-specific would be my opinion.

IMO, any behavior which is invisible outside the box (such as described
above) should not be dictated by standards bodies.

-- David