Subject: Efficient teardown on error/preemption

From: "Reeve, Andrew" <[email-masked]>
Date: Thu, 3 May 2001 17:43:49 +0100

Please could somebody clarify the operation of GMPLS-RSVP wrt the following.

draft-ietf-mpls-generalized-rsvp-te-02.txt supports "Removing State with a PathErr message" (section 4.4). This is aimed at speeding up the removal of state. As I understand it, it works as follows. When an error occurs (including preemption I assume), the node detecting the error will send a PathErr to the initiator and a PathTear to the responder. The PathErr will have a flag ("Path State Remove") set which indicates that state has been removed, and all nodes receiving the PathErr will co-operate by removing state and keeping the flag set.

Is it the intention that, for TE tunnels and lightpaths, the PathTear and PathError will remove ALL state, or do we also have to follow up with a ResvTear?

Also, is behavior consistent for both preemption and network errors?

For reasons of signaling efficiency and responsiveness to errors, we would like it to be possible to destroy all state for a LSP, whether it be a TE tunnel or bi-directional using 1 of the following:

a) PathTear from the initiator.
b) PathError and PathTear from an intermediate node (directed at the initiator and responder respectively)
c) ResvTear from the responder.

Is that how it works?

Your help appreciated,
Andy
> __________________________
> Andy Reeve,
> Senior Consultant,
> Internet Technology and Networks.
__________________________

> Roke Manor Research Ltd,
> A SIEMENS Company.
> 
> Roke Manor, 
> Romsey. SO51 OZN.
> 
> Tel: +44 1794 833580
> Fax: +44 1794 833616
> 
> mailto:[email-masked]
> 
> http://www.roke.co.uk
> http://www.roke-manor.com
> __________________________
The information contained in this e-mail is confidential to Roke Manor and must not be passed to any third party without permission.  This communication is for information only and shall not create or change any contractual relationship.