Subject: LSP Preemption

From: Gopalkrishna Panicker <[email-masked]>
Date: Wed, 9 Oct 2002 11:27:31 -0700 (PDT)

Hi,

As a part of path admission control a router upon
receipt of a path message decides if it has 
sufficient resources to accommodate this session. 
This decision may involve bumping other low priority
sessions.

>From reading the archives I gather this bumping is
actually done when the corresponding Resv message
arrives. I assume this is when the appropriate
PathErr/ResvErr is sent. 

My question is, in a intermediate or transit router
do we delete the old reservation (of the bumped lsp)
at the time we send the error message. How does one
recover should this error message be lost ? 

Another related question, are reservations torn down
when we recv a Resv Err/Path error message or should  

we wait for the path/resv tear to do this. RFC 2209
suggests the later.

Cheers,
Gopal

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

---

From: David Charlap <[email-masked]>
Date: Thu, 10 Oct 2002 11:14:18 -0400

> This decision may involve bumping other low priority

This should only be done during Path processing if the Path processing 
is going to allocate resources for the connection.  Otherwise, you may 
block legitimate traffic.

There is noting in any RSVP spec which requires the size of the 
reservation in the Resv's FLOWSPEC to match the size requested in the 
Path's TSPEC.  The FLOWSPEC may be smaller than requested.  And in the 
case of multicast or multiple LSPs sharing resources with SE style, 
various merging rules may make the actual reservation larger or smaller 
than requested.

Furthermore, there's a time delay between receiving Path and Resv 
messages.  Your local state (including resource availability) can change 
during that time.

> arrives. I assume this is when the appropriate

That would be correct.  You do admission control when you actually try 
to create your forwarding-plane connections, and not before.  If your 
implementation creates its connections during Path processing, then you 
do admission control during Path processing.  If you create your 
connections during Resv processing, then you do your admission control 
during Resv processing.

> recover should this error message be lost ? 

The RFC is very clear about this.

When a connection is preempted, you tear down its resources (the 
definition of preemption).  PathErr and ResvErr messages should be sent. 
  If this results in tearing Resv state (which is almost certainly 
will), then you should also send out a ResvTear.  If it results in 
tearing Path state (which I don't think is reasonable, but is a 
possibility), then you should send out a PathTear as well.

The reasons are simple.  The PathErr and ResvErr inform the edge routers 
that the connection has been preempted.  This will let them choose a 
different size reservation or choose a different route to run the LSP 
through.

The ResvTear is sent out to inform the upstream nodes that the 
reservation is no longer present.  There's no point to them reserving 
resources if the traffic will get dropped further downstream anyway. 
Additionally, that Resv state will time out anyway, since a node won't 
ever refresh deleted state.  The tear message speeds up the inevitable here.

Similar for the PathTear.  If your Path state is no longer present, then 
the downstream nodes will stop receiving their refreshes.  The state 
will time out eventually.  The PathTear message speeds up the process so 
they don't waste resources on useless state.

> we wait for the path/resv tear to do this. RFC 2209

Error messages should never cause state to be torn.  They serve only to 
inform the edges of an error condition.  It is up to the edge to decide 
what to do about the error (which may well be to tear the LSP and try to 
reestablish with different parameters.)

The only real exception here is an admission control ResvErr in a 
multicast scenario.  In that case, the FLOWSPEC in an outbound Resv 
message may be produced from the FLOWSPECs of several inbound Resv 
messages - a ResvErr indicating admission control in this case is 
handled by blockading the largest reservations and re-merging the 
remaining ones, according to the (rather complex) rules of RFC 2205 and 
2209.

But this is really not applicable to RSVP-TE, since admission control 
causes PathErr generation instead of ResvErr.  (See section 4.7.3 of RFC 
3209)

-- David