Head Node Protection Extensions to RSVP-TE for LSP Tunnels
draft-cao-mpls-te-p2mp-head-protection-01
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Wei Cao , Mach Chen | ||
Last updated | 2007-11-17 | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Protection methods for RSVP-TE P2MP LSP have been described in [TE- FRR]([RFC4090]) and [P2MP-TE-Bypass], but there are no solutions to protect an RSVP-TE P2MP head node. This document discusses the scenario for RSVP-TE P2MP LSP head node failure protection and describes the protection procedures. RSVP-TE extensions for such protection are also described. To protect the head node, a backup head node is appointed which forwards traffic to downstream LSRs of the LSP when the protected head node fails. The backup head node is not on the path of protected LSP. Similar to [TE-FRR] there are two methods that can apply: one- to-one backup and facility backup. Only one-to-one backup is described in detail here, facility backup will be discussed in a future version of this draft. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)