Fast Reroute Extensions to RSVP-TE for LSP Tunnels
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, mpls mailing list <firstname.lastname@example.org>, mpls chair <email@example.com> Subject: Protocol Action: 'Fast Reroute Extensions to RSVP-TE for LSP Tunnels' to Proposed Standard The IESG has approved the following document: - 'Fast Reroute Extensions to RSVP-TE for LSP Tunnels ' <draft-ietf-mpls-rsvp-lsp-fastreroute-08.txt> as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-08.txt
Technical Summary This document defines extensions to and describes the use of RSVP to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds in the event of a failure. Two methods are defined. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of protected LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either or both methods and to interoperate in a mixed network. Working Group Summary Several years before work began on this draft, operational networks had deployed two independent methods of doing fast reroute, called herein one-to-one backup and facility backup. Vendors trying to support both methods were experiencing incompatiblity problems in attempting to produce a single implementation capable of interoperating with both. There are technical tradeoffs between the methods. However these tradeoffs are so topologically dependent, that the community has not converged on a single approach. Both methods are considered necessary to cover different topological scenarios. Protocol Quality The specification has been reviewed for the IESG by Alex Zinin.