The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

Gopalkrishna Panicker wrote:
> 
> 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.

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.

> 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.

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.

> 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 ? 

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.

> 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.

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