Subject: Resource reservation during RSVP Path message forwarding?

From: [email-masked]
Date: Thu, 19 Apr 2001 13:05:35 -0400

Hi all,

I have a question regarding when the proper time is to start resource
reservation on a transit LSR (not LER).

Assume we have R1(LER) --> R2 (LSR) --> R3(LSR) --> R4(LER).  R1 gets a
signal from, say, user configuration that there is a need to set up a LSP.
R1 sends a RSVP Path message to R2.  Would you think R2 should try to
reserve resource at this time and send another RSVP Path message down to
R3, or you think R2 should not reserve any resource until R2 gets a RSVP
Resv message from R3?

Thanks,
Jane D. Jiang

---

From: David Charlap <[email-masked]>
Date: Thu, 19 Apr 2001 14:20:46 -0400

[email-masked] wrote:
> Assume we have R1(LER) --> R2 (LSR) --> R3(LSR) --> R4(LER).  R1
> gets a signal from, say, user configuration that there is a need to
> set up a LSP.  R1 sends a RSVP Path message to R2.  Would you think
> R2 should try to reserve resource at this time and send another RSVP
> Path message down to R3, or you think R2 should not reserve any
> resource until R2 gets a RSVP Resv message from R3?

This is an implementation detail.  There are advantages to both ways.

REASONS FOR RESERVING RESOURCES DURING PATH PROCESSING

1: There's no need to propagate a Path message all the way to an
   egress router if you know that you're not going to be able to
   satisfy the reservation when the Resv returns.  Depending on the
   number of hops to the egress, this might be significant overhead.

2: Actually making reservations on the backplane and involved
   line-cards may be time-consuming.  If the setup can take place in
   the background, and complete before the Resv arrives, significantly
   faster LSP setup times may be achieved.

REASONS FOR NOT RESERVING RESOURCES UNTIL RESV PROCESSING

1: There will be no data flow along the LSP until the Resv message
   arrives, but the resources will be reserved.  These resources won't
   be available for other purposes (perhaps other LSPs or non-MPLS
   circuits.)

2: If a downstream router can't make its reservation, you will have
   to tear your reservation.  During the time between creating and
   tearing the reservation, the resources were unavailable for other
   LSPs, and may have caused the other LSP's setup to fail.

3: RSVP doesn't require the resources requested in the Resv message's
   FLOWSPEC to match the resources specified in the Path message's
   TSPEC.  RSVP will allow any reservation that is less than or
   equal to the requested reservation.  Policy, local configuration,
   or some kind of application-awareness may allow an egress router
   to reduce a reservation prior to generating a Resv message.

   If the Resv QoS doesn't match the Path QoS, then the router will
   have to reduce its already-reserved reservation when the Resv
   arrives, or else resources will be wasted.  The act of reducing a
   reservation may be just as time-consuming (perhaps even more so)
   than simply waiting for the Resv before making any reservations.

Which mechanism makes more sense for your code will be a function of
your hardware and software architecture.

-- David

---

From: "Gautam Khera" <[email-masked]>
Date: Thu, 19 Apr 2001 15:16:16 -0400

Jane,

The PATH message should be forwarded all the way to R4(assuming that is the
destination) by the intermediate routers(R2 & R3). A Path State Block will
be created on the intermediate routers, but, resources need not be reserved
at this point. The actual reservation is done when R4 sends a RESV message
back to R1 which passes thru the same route.

-gautam.