Network Working Group Wei.Cao
Internet Draft Mach. Chen
Expires: May 2008 Huawei Co,.LTD
Category: Standards Track November 17, 2007
Head Node Protection Extensions to RSVP-TE for LSP Tunnels
draft-cao-mpls-te-p2mp-head-protection-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 17, 2008.
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-
<Cao, et al.> Expires May 17, 2008 [Page 1]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
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.
Table of Contents
1. Terminology.................................................3
2. Introduction................................................3
2.1. Motivation.............................................3
2.2. Head Node Protection Scenario...........................4
2.2.1. Solution Overview..................................5
2.3. Applicability Statement and Implementation Considerations7
2.3.1. Topology Limitation................................7
2.3.2. Implementation Consideration.......................8
3. Extensions to RSVP-TE........................................8
3.1. HEAD_PROTECTION Object..................................8
3.1.1. HEAD_PROTECTION for IPv4 address...................8
3.1.2. HEAD_PROTECTION for IPv6 address...................9
3.1.3. SESSION_ATTRIBUTE Flags...........................11
4. Behavior of MHN and BHN.....................................11
4.1. Behavior of MHN........................................11
4.1.1. Signaling BHN for Head Protection.................11
4.1.2. Revert back to MHN from BHN Behavior..............12
4.2. Behavior of BHN........................................13
4.2.1. Signaling BHN-Detour and Protection Procedures.....13
4.2.2. Revertive Procedures for BHN......................14
4.3. Protection Teardown....................................14
4.3.1. Protection Teardown...............................14
5. Behavior of Merge Nodes.....................................15
6. Behavior of All Other LSRs..................................15
7. Security Considerations.....................................15
8. IANA Considerations........................................15
9. Conclusions................................................15
10. Acknowledgments...........................................15
11. References................................................16
11.1. Normative References..................................16
Author's Addresses............................................16
Intellectual Property Statement................................16
Disclaimer of Validity........................................17
Copyright Statement...........................................17
Cao, et al. Expires May 17, 2008 [Page 2]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
1. Terminology
LSR: Label-Switch Router. In this document all LSRs should support
RSVP-TE extensions for P2MP LSP.
LSP: An MPLS Label-Switched Path. In this document, an LSP will
always be an explicitly routed LSP.
MHN: Major Head Node. MHN is the head node of the protected RSVP-TE
P2MP LSP .
BHN: Backup Head Node. BHN is the head-end of the backup LSP. When
there is a node failure in MHN, BHN will take the charge of
forwarding packets on the backup up LSP protecting the traffic.
MP: Merge Point. In this document a MP is generally the one hop
downstream neighbour to the MHN.
PLR: Point of local repair
2. Introduction
RSVP-TE P2MP LSP has been deployed and many real-time applications
are running over such LSPs, so there is motivation to improve their
reliability. Much work has already been done to provide protection in
RSVP-TE P2MP. Fast Reroute [FRR] has been an important mechanism to
improve network resiliency. But the methods proposed in [TE-FRR] and
[P2MP-TE-Bypass] do not provide a mechanism for protecting an LSP's
head node which is a key element for high availability. This document
discusses the scenario for RSVP-TE P2MP LSP head node failure
protection and describes procedures and RSVP-TE extensions for such
protection. This work requires that the procedures defined in
[RSVP](RFC2205), [RSVP-TE](RFC3209),[TE-FRR]and [RSVP-P2MP](RFC4985)
MUST be followed.
2.1. Motivation
Traditional protection methods use a backup LSP or bypass tunnel to
forward the traffic. In the event of protected LSP failure, including
link or node failure, PLR will take action to detour the packets from
PLR to MP through a backup LSP or bypass tunnel. This requires PLR
must be a node on the path of the protected LSP and must be upstream
of the failure point. Such mechanisms work well for protecting
transit links and transit LSRs but have no ability to protect the
head node of the LSP because it has no upstream node. In real
applications, head node failure will cause serious outages and
consequently there is a strong motivation for reducing and providing
Cao, et al. Expires May 17, 2008 [Page 3]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
protection from that risk. One possible solution today is 1+1
protection: deploying another P2MP tree from a different LSR to all
receivers. Obviously this is not an efficient method; it will double
bandwidth usage and require maintaining twice the forwarding states
in the devices. So it is highly desirable to find another solution to
this problem.
2.2. Head Node Protection Scenario
When real-time applications are deployed, service providers (SP)
always try to avoid service interruption. Failures are not
predictable so backup is a necessary and effective solution. It is
common for SP to deploy multiple servers (traffic sources) and/or
multi-home the application servers to multiple edge routers. Below is
a typical topology for such applications:
+---[R1]--[R2]--[R3]---[L1]----[ReceiverA]
[S1]-| \/ | \/
| /\ | /\
+---[R4]--[R5]--[R6]---[L2]----[ReceiverB]
Figure 1. Source Multi-homing
In Figure 1, [S1] is an application server; [Rx] and [Lx] are RSVP-TE
P2MP LSP capable devices. [S1] is multi-homed to LSR [R1] and [R4].
If multicast packets are sent by [S1]they need to be transmitted to
[L1] and [L2], a P2MP LSP (LSP1)starting at [R1] can be created with
two sub-LSPs: [R1]->[R2]->[R3]-[L1] and [R1]->[R5]->[R6]->[L2]. Thus
packets from [S1] can be received by [ReceiverA] and [ReceiverB]. If
the SP wants to improve robustness, another P2MP LSP (LSP2) starting
from [R4] can be created with two sub-LSPs: [R4]->[R5]->[R6]->[L2]
and [R4]->[R2]->[R3]-[L1]. Packets from [S1] can reach [R1] and [R4]
at the same time and be forwarded to L1 and L2 separately through
LSP1 and LSP2. [L1] and [L2] may choose one LSP (Suppose it is LSP1)
as the major path and the other one (LSP2) as a backup one. Only
traffic from LSP1 will be forwarded to receivers and traffic from
LSP2 will be dropped. In case of [R1] failure, [L1] and [L2] detect
the failure of LSP1 and then begin to accept packets received from
LSP2.
There may be some variations from Figure 1. The SP may want to
protect against LSR and application server failure. A common solution
is to deploy two application servers separately connected to two LSRs.
This is shown in Figure 2 below:
Cao, et al. Expires May 17, 2008 [Page 4]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
[S1]-|---[R1]--[R2]--[R3]---[L1]----[ReceiverA]
\/ | \/
/\ | /\
[S2]-|---[R4]--[R5]--[R6]---[L2]----[ReceiverB]
Figure 2. Separate Sources
[S1] and [S2] are connected to [R1] and [R2] respectively, and both
application servers generate the same traffic stream to receivers.
Packets from [S1] will go through LSP1 and packets from [S2] will go
through LSP2. [L1] and [L2] may accept the packets from LSP1 and drop
the packets from LSP2. The protection procedure is similar to the
case depicted in Figure 1.
The above methods work but are inefficient. The protection bandwidth
is wasted most of time. LSRs have to maintain as much as twice amount
of P2MP LSP state. In addition all leaves have to deal with
duplicated traffic and monitor the LSP state to determine which LSP
is the active one. Comparing the two P2MP LSPs in above cases, it is
easy to be noticed that the only differences between them are the
head nodes; LSP1 starts from [R1] and LSP2 starts from [R4], the
transit nodes and leaves are same. So in such a topology if [R1] and
[R4] cooperate together with one acting as a backup node for the
other, then it is possible to build only one P2MP LSP while gaining
head node protection.
2.2.1. Solution Overview
Similar to FRR defined in [TE-FRR], the head node protection method
described in this document also relies on backup LSPs. Since there is
no "upstream neighbour" of the head node to detour the traffic around
it, an LSR has to be assigned as a backup head node in the event of
head node failure. We call the head node of protected LSP as MHN
(major head node) and the backup one BHN (backup head node). A backup
LSP or bypass tunnel to protect MHN will be built from BHN to all
NHOP LSRs of MHN. These NHOP LSRs are merge points (MP) for the LSPs.
To ensure all branches receive the traffic the MP set SHOULD include
ALL NHOP LSRs of MHN.
Multicast packets from the source arrive at both MHN and BHN. Under
normal operating conditions MHN forwards this traffic while BHN drops
it; there is no traffic on backup LSP or bypass tunnels to MPs. When
BHN detects there is a failure of MHN it will begin to forward
packets to the MPs. The MPs will recognize which LSP the packets
belong to and forward the packets along the rest of the protected LSP.
Cao, et al. Expires May 17, 2008 [Page 5]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
The precise mechanism used to discover the node failure of MHN is
outside the scope of this document. One possible method is to use
multiple, diversely routed, BFD connections between MHN and BHN. If
all these BFD sessions are lost, BHN can reasonably infer that MHN
has failed.
A LSR eligible to be a BHN MUST satisy the follow conditions:
- Traffic to be protected can be received by it from the source
without transiting MHN;
- BHN can build traffic tunnels to all MPs. That means BHN must on
the "upstream side" of all MPs. Ideally BHN should have direct
connection links to all MPs.
- BHN should have the ability to discover MHN's node failure and
discover the recovery of MHN from node failure. (How to detect the
node failure is outside the scope of this document)
- BHN SHOULD NOT be on the path of protected LSP.
In Figure1, if the head node of LSP1 is to be protected, [R1] is the
MHN and [R4] can be assigned as BHN. The MP set includes LSR [R2] and
[R5].
The backup LSP against MHN failure starts from BHN to MPs.
Theoretically the backup LSP can use unicast LSPs or P2MP TE LSPs.
Consequently there are two options for building backup LSPs:
- Rely on one or multiple unicast LSPs from BHN to the set of merge
points.
- Rely on single P2MP TE LSP from BHN to the set of merge points.
There is a constraint on the routing of the backup LSP(s): the backup
LSP(s) MUST NOT transit the MHN.
Since the BHN has to send traffic to all downstream MPs, a P2MP TE
LSP is a natural choice and is the approach discussed in this
document. In figure 1 the backup P2MP TE LSP is composed of two sub-
LSPs: [R4]->[R2] and [R4]->[R5]. The backup P2MP TE LSP is referred
to as a LSP BHN-Detour.
When a failure occurs in the MHN ([R1]), the BHN ([R4]) detects the
failure and begins transmitting traffic on to the BHN detour along
links [R4]->[R2] and [R4]->[R5], using the label received from the
MPs ([R2] and [R5])when it created the BHN-Detour. While [R4] is
Cao, et al. Expires May 17, 2008 [Page 6]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
using the BHN-Detour it recognizes the multicast traffic and performs
the MPLS encapsulation. Merge points receive the detoured traffic
from BHN and merge them to the protected LSP. From the view of MPs,
the process is the same as for link failure protection.
Service interruption is not only caused by failure but may be caused
by regular operations, such as hardware upgrade or software patch
installation. Such operation is planned by the SP and the outage of
the node can be predicted. This kind of operation is referred to as
Planned-Maintenance (PM). The head protection method described in
this document can also be used in this scenario. For example, in
figure1, if [R1] has to stop forwarding due to some operational
reason, [R1] can assign [R4] as BHN and after [R4] has built the BHN-
Detour R1 can be removed from service and traffic transmitted through
the BHN-Detour. After the maintenance of [R1] has been performed it
can be returned to service. Head protection is a valuable protection
against failure and a useful tool for normal network operation.
Since head protection is performed by two LSRs, there are many
important differences between [TE-FRR] and head protection.
The fundamental difference between [TE-FRR] and head-node protection
is how the PLR/BHN is informed of the details of the protected LSP.
In [TE-FRR], PLR will receive PATH message sent by the head node and
PLR will get all information about the protected LSP and process the
relevant RSVP extensions. BHN is not on the path of the Protected LSP
and so extra messages must be sent by MHN to BHN to convey this
information.
One other difference is that all LSRs on the path of P2MP LSP must be
periodically refreshed by a PATH message, in the case of MHN failure,
BHN must generate and send PATH messages to all downstream LSPs as if
these messages were sent by the MHN.
2.3. Applicability Statement and Implementation Considerations
2.3.1. Topology Limitation
This document describes a mechanism that works only with the topology
constraint that a suitable backup head node exists. A suitable backup
head node must satisfy the requirements listed in section 2.2.1. It
is common to construct the topologies discussed in 2.2 in high
availability environments and these constraints are not a significant
additional burden in the deployment of head-node protection.
Cao, et al. Expires May 17, 2008 [Page 7]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
2.3.2. Implementation Consideration
Head node protection should be compatible with the existing protocols
in so far as is possible. Some considerations/requirements are listed
bellow:
- Inherit existing protocol extensions: the new method should reuse
existing protocol extensions defined in [TE-FRR] as much as
possible; the new method should be backward compatible with
current mechanisms. Ideally, only MHN and BHN should be upgraded
and MPs and others LSR SHOULD be kept unchanged.
- When a protection action is taken, as few nodes as possible should
be affected. There should be no need to affect any nodes
downstream of a MP.
- After a protection switch has occured the BHN operates in an
indentical manner to the old head node; it refreshes and processes
all feedback from downstream LSRs which, with the exception of the
MP, are unaware of the change from MHN to BHN.
3. Extensions to RSVP-TE
This document defines an additional object, which is referred to as a
HEAD_PROTECTION object. This new object is backward compatible with
LSRs that do not recognize it. The new object is carried in RSVP PATH
and RESV messages.
3.1. HEAD_PROTECTION Object
The HEAD_PROTECTION object is used to exchange information between
MHN and BHN. MHN uses this object to specify which LSR is BHN and
advertise essential information about a protected LSP. BHN and MHN
MUST NOT forward this object to their downstream LSRs.
Ideally MHN and BHN are directly connected. If MHN is not directly
connected with BHN, a tunnel should be created to transmit PATH/RESV
message with HEAD_PROTECTION object. If tunnel is used, the
HEAD_PROTECTION object will be invisible to transit LSRs. [RFC2746]
describes transmission of RSVP messages over tunnels.
3.1.1. HEAD_PROTECTION for IPv4 address
Class-Num: TBD
Cao, et al. Expires May 17, 2008 [Page 8]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
C-Type: TBD
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Protected_Head |
+-------------+-------------+-------------+-------------+
| Backup_Head |
+-------------+-------------+-------------+-------------+
| Flags |
+-------------+
Protected_Head
IPv4 address identifying the RSVP-TE LSP Head node. Any stable
local address of the MHN can be used.
Backup_Head
IPv4 address identifying the LSR selected as BHN. Any stable local
address of the BHN can be used.
Flags
0x01(bit0): Head protection desired
0x02(bit1): Head protection available
Bit0 is the lowest bit of the octet.
3.1.2. HEAD_PROTECTION for IPv6 address
Class-Num TBD
C-Type TBD
Cao, et al. Expires May 17, 2008 [Page 9]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Protected_Head |
+-------------+-------------+-------------+-------------+
| Protected_Head (continued) |
+-------------+-------------+-------------+-------------+
| Protected_Head (continued) |
+-------------+-------------+-------------+-------------+
| Protected_Head (continued) |
+-------------+-------------+-------------+-------------+
| Backup_Head |
+-------------+-------------+-------------+-------------+
| Backup_Head (continued) |
+-------------+-------------+-------------+-------------+
| Backup_Head (continued) |
+-------------+-------------+-------------+-------------+
| Backup_Head (continued) |
+-------------+-------------+-------------+-------------+
| Flags |
+-------------+
Protected_Head
An IPv6 128bits unicast address identifying the RSVP-TE LSP Head
node. Any stable local address of the MHN can be used.
Backup_Head
An IPv6 128bits unicast address identifying the LSR selected as BHN.
Any stable local address of the BHN can be used.
Flags
0x01(bit0): Head protection desired
0x02(bit1): Head protection available
Bit0 is the lowest bit of the octet.
Cao, et al. Expires May 17, 2008 [Page 10]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
3.1.3. SESSION_ATTRIBUTE Flags
The current SESSION_ATTRIBUTE object has several flags defined in it
[RSVP_TE] and [TE_FRR]. To request head node protection the local
protection desired, SE style desired and node protection desired
flags should be set.
4. Behavior of MHN and BHN
The head-end (MHN) of an RSVP-TE P2MP LSP determines whether head
node protection is required and which LSR will be designated as
backup head node (BHN). How MHN selects an LSR as BHN is out of the
scope of this document. Manual configuration is an effective and
obvious choice.
MHN and BHN cooperate to setup the backup LSPs. To reduce the effect
on other LSRs on the path of the P2MP tunnel, from the view of MP,
BHN builds the backup LSP as if a link protection LSP between MHN and
MP is being created.
4.1. Behavior of MHN
If MHN decides to deploy head protection, all flags required for link
protection should be set when MHN sends PATH messages. If one-to-one
protection is desired, then MHN should include a FAST_REROUTE object
and set "one-to-one backup desired" flag.
There are two different procedures for MHN in head protection:
- Signaling BHN and building BHN-Detour.
- Revertive operation. After recovery from node failure, MHN should
re-build RSVP-TE P2MP LSPs after which revertive switching MAY
occur allowing MHN to assume its original role, i.e traffic is
again sourced from MHN onto the first segment of the protected LSP
and the use of BHN-Detour is discontinued.
4.1.1. Signaling BHN for Head Protection
To build a BHN-Detour to protect the MHN the BHN must get information
about the protected LSP. This includes:
- Unambiguous and unique identification of the protected LSPs
- Unique identification of the protected node ( MHN )
- Whether bandwidth protection is desired
Cao, et al. Expires May 17, 2008 [Page 11]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
- Whether one-to-one protection or facility backup is desired.
- Knowledge of which LSRs are merge points (that is the second hop
LSRs of the P2MP LSP).
BHN obtains this information from MHN using a PATH message containing
the HEAD PROTECTION object defined in 3.1.
If MHN decides to deploy head protection and selects a LSR as BHN, it
MUST follow the behavior described bellow:
- MHN records each PATH message sent to its down stream LSRs. MHN
rebuilds PATH messages and inserts a HEAD PROTECTION object with
"head protection desired" flag set. MHN may merge several original
PATH messages into one PATH message to improve the efficiency, but
MHN must not the change the flags and objects in original PATH
messages.
- MHN should fill the "protected head" field in HEAD_PROTECTION
object with its own IP address, and fill "backup head" field with
BHN's IP address.
- MHN sends the PATH messages to BHN. If MHN and BHN are directly
connected, the PATH message can be directly, otherwise, it should
be sent through a tunnel.
- If a topology change changes the MP then MHN should send an update
PATH message to BHN immediately to indicate that fact.
MHN sends the PATH message containing HEAD_PROTECION object and
expects corresponding RESV message from BHN. After BHN has signaled
the backup path, a RESV message with HEAD_PROTECTION object will be
sent back to MHN by BHN as described in section 4.2.1.
4.1.2. Revert back to MHN from BHN Behavior
- With head protection, traffic sent from MHN will be replaced by
the traffic sent from BHN when MHN failure occurs. When MHN is
recovers from failure, MHN SHOULD be able take the charge of
sending traffic along the protected P2MP LSP again. The revertive
switch SHOULD occur after the RSVP-TE P2MP LSP has been re-
constructed. Some objectives are described here:
Objectives:
- All RSVP-TE P2MP LSPs being protected by BHN SHOULD be re-
constructed by MHN.
Cao, et al. Expires May 17, 2008 [Page 12]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
- LSPs reconstructed by MHN SHOULD have the same SESSION /
SESSION_TEMPLATE attributes as original LSPs.
- The revertive operation SHOULD be opaque to LSRs on the path of
RSVP-TE LSP except MHN, BHN and MPs.
- BHN SHOULD know the LSPs have been re-constructed and know when to
stop forwarding the traffic.
The detailed procedures will be defined in a later version of this
document.
4.2. Behavior of BHN
BHN is responsible for creating BHN-Detours to protect the head node
and play the role of head node during MHN failure. In addition the
BHN helps the MHN to re-construct protected LSPs after MHN recovers.
There are two different procedures for BHN:
- Signaling BHN-Detour and rerouting traffic for protection.
- Revertive Procedures.
4.2.1. Signaling BHN-Detour and Protection Procedures
As described in section 4.1.1, MHN periodically sends PATH messages
with HEAD_PROTECTION object to BHN. By processing the PATH messages
BHN identifies the protected P2MP LSP and calculates the backup LSP.
BHN must follow the behavior described bellow:
o Message handling:
- BHN MUST check the SESSION object in PATH message. If BHN receives
a PATH message with HEAD_PROTECTION Object from non-MHN LSR, it
indicates that the BHN is on the path of a protected tunnel. BHN
MUST discard this message and send a notification message (TBD) to
the sender.
- BHN MUST check the IP address in "backup head" in the
HEAD_PROTECION object. If the BHN does not have such an IP address,
BHN MUST send back notification to the BHN.
- After check the validity of PATH message, BHN processes the
objects in PATH message. BHN MUST record SESSION and
Cao, et al. Expires May 17, 2008 [Page 13]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
SESSION_TEMPLATE objects to identify protected LSP tunnels. BHN
also records all ERO/SERO and recognizes all MPs.
o Signaling BHN-Detour
- BHN can signal BHN-Detour in the way defined in [TE-FRR]. BHN can
use one-to-on backup or facility backup method. From the viewpoint
of the MPs, the backup LSP is used for link failure (MHN->MP)
protection.
- After the BHN-Detour is created, BHN send RESV message with "Head
protection available" flag set to MHN, which informs MHN that BHN-
Detour is ready.
o Protection action
- When BHN detects the MHN's node failure, BHN immediately forwards
packet through backup LSP to MPs.
- BHN MUST keep all attributes of the protected P2MP LSP. The
SESSION and SESSION_ATTRIBUTE objects MUST remain unchanged.
- BHN periodically sends PATH messages to all MPs to refresh the
state of protected LSP. The downstream LSRs are unaware of the
change.
4.2.2. Revertive Procedures for BHN
As described in 4.1.2 it SHOULD be possible for a MHN to resume its
normal role after recovery. Revertive switching from BHN to MHN will
be described in a future version of this document.
4.3. Protection Teardown
MHN can teardown head protection when necessary.
4.3.1. Protection Teardown
The teardown procedure must be initiated by MHN.
To initiate immediate explicit teardown MHN sends BHN a PATH Tear
message containing a HEAD_PROTECTION object. This PATH message may
contain SESSION and SESSION_TEMPLATE but no ERO/SERO objects. This
informs BHN that all related states of the protected LSP should be
removed.
Cao, et al. Expires May 17, 2008 [Page 14]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
5. Behavior of Merge Nodes
This document places no new requirements on MPs. MPs have the same
behaviors described in [TE-FRR] and [P2MP-TE].
It should be noted that MPs may receive duplicate traffic during the
switching period from MHN to BHN (PM scenario), and vice versa. MP's
need to have the ability to robustly handle duplicate traffic; how
they do so is out of the scope of this document and is vendor
specific.
6. Behavior of All Other LSRs
Behavior of other LSRs should be unchanged.
7. Security Considerations
This document does not introduce new security issues. The security
considerations pertaining to the original [RSVP-TE-FRR] remain
relevant.
Note that the head protection method requires that MHN and selected
BHN trust RSVP messages received from each other.
8. IANA Considerations
TBD
9. Conclusions
Head node protection works not only for failure protection, but also
helps the SP with planned maintenance. Service interruption is caused
not only by network device failure but by administrative operation,
such as line card upgrade or software patch installation. With the
mechanisms described above, the SP can take LSP head end devices
offline for maintenance and provide uninterrupted service by
initiating a (manual) protection switch from MHN to BHN (and vice
versa).
10. Acknowledgments
We would like to thank Paul Doolan for his review and comments which
have helped to clarify this draft.
Cao, et al. Expires May 17, 2008 [Page 15]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RSVP-TE] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209.
[RFC4461] S. Yasukawa et al., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC4461.
[TE-FRR] Pan, Swallow, Atlas, et al., "Fast Reroute Extensions to
RSVP-TE for LSP Tunnels", RFC4090.
[RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, "Extensions to RSVP-TE
for Point to Multipoint TE LSPs", RFC4985.
Author's Addresses
Wei Cao
Huawei Technologies
Room 201R, Kuike building, Shangdi,
Haidian District of Beijing, P.R. China
Email: caowayne@huawei.com
Mach Chen
Huawei Technologies
Room 201R, Kuike building, Shangdi,
Haidian District of Beijing, P.R. China
Email: mach@huawei.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Cao, et al. Expires May 17, 2008 [Page 16]
Internet-Draft <RSVP-TE P2MP Head Protection> November 2007
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Cao, et al. Expires May 17, 2008 [Page 17]