Subject: RSVP-TE: Bandwidth decrease modify

From: "Paola Iovanna (ERI)" <[email-masked]>
Date: Fri, 17 May 2002 17:26:23 +0200

Hi All!
I'd like to know more information about how RSVP-TE  performs bandwith decrease modify in a MPLS scenario.  It is clear the procedure followed in order to perform bandwidth increase while it is not clear how it is released the bandwidth in case of bandwidth decrease.
Thank you!

Paola

---

From: "Sean Crocker" <[email-masked]>
Date: Mon, 20 May 2002 15:12:59 -0500

Paola,

>I'd like to know more information about how RSVP-TE  performs bandwith decrease modify in a MPLS scenario.  It is clear the procedure followed in order to perform bandwidth increase while it is not…

It should be the same as bandwidth increase as defined in RFC3209
section 4.6.4, except it's asking for less bandwidth in the PATH with the new LSPIP.

If the ingress implementation is done right, it should wait either x
seconds after the new tunnel is fully established, or x number of RESVs
come back for the new tunnel.  Then it could either stop sending PATH
for the old tunnel, or even better send a PATHTEAR for it.  Either way,
all nodes from ingress to egress will then have the smaller bandwidth
in their state blocks for the session.

Sean

---

From: David Charlap <[email-masked]>
Date: Mon, 20 May 2002 16:27:33 -0400

"Paola Iovanna (ERI)" wrote:
> 
> I'd like to know more information about how RSVP-TE  performs
> bandwith decrease modify in a MPLS scenario.  It is clear the
> procedure followed in order to perform bandwidth increase while it
> is not clear how it is released the bandwidth in case of bandwidth
> decrease.

Same way as an increase.  One of two mechanisms:

1: Have the ingress change the TSPEC it sends.  This should propagate
through the network and result in an updated FLOWSPEC propagating back
in Resv messages.

When the bandwidth is decreasing, you'll probably see a quicker
response, since RSVP implementations usually clip the FLOWSPEC to the
level of the TSPEC.  It should work fine, assuming the router allows LSP
modification in the first place.

2: Make-before-break.  Signal a new LSP with a different LSP ID.  Use SE
style to share resources with the old one.  Once you get the Resv back
for the new LSP, cut your traffic over to the new one and tear the old
one.

-- David