Network Working Group Wei Cao
Internet Draft Mach Chen
Expires: January 2008 Huawei Technologies Co.,Ltd
Category: Standards Track July 2, 2007
Head Node Protection Extensions to RSVP-TE for LSP Tunnels
draft-cao-mpls-te-p2mp-head-protection-00.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 January 2, 2008.
Abstract
Protection methods for RSVP-TE P2MP LSP have been discussed by [TE-
FRR]([RFC4090]) and [P2MP-TE-Bypass], but there are no solutions to
protect 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 extension for such protection is also
described.
To protect the head node, a backup head node must be appointed and
take the responsibility to forward the traffic to downstream LSRs of
the protected head node. Generally, the backup head node is not on
the path of protected LSP. Similar to [TE-FRR] there are two methods
<Cao, et al.> Expires January 2, 2008 [Page 1]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
can apply: one-to-one backup and facility backup and facility backup.
Only one-to-one backup is described in details, facility backup will
be discussed in 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.................................................4
2. Introduction................................................4
2.1. Motivation.............................................4
2.2. Head Node Protection Scenario...........................5
2.2.1. Solution Overview..................................6
2.3. Applicability Statement and Implementation Considerations8
2.3.1. Topology Limitation................................8
2.3.2. Implementation Consideration.......................9
3. Extensions to RSVP-TE........................................9
3.1. HEAD_PROTECION Object...................................9
3.1.1. HEAD_PROTECTION for IPv4 address..................10
3.1.2. HEAD_PROTECTION for IPv6 address..................11
3.1.3. SESSION_ATTRIBUTE Flags...........................12
4. Behavior of MHN and BHN.....................................12
4.1. Behavior of MHN........................................12
4.1.1. Signaling BHN for Head Protection.................13
4.1.2. Revert back to MHN from BHN Behavior..............14
4.2. Behavior of BHN........................................16
4.2.1. Signaling BHN-Detour and Protection Procedures.....17
4.2.2. Revertive Procedures for BHN......................18
4.3. Protection Teardown....................................18
4.3.1. Protection Teardown...............................19
5. Behavior of Merge Nodes.....................................19
6. Behavior of All Other LSRs..................................19
7. Security Considerations.....................................20
8. IANA Considerations........................................20
8.1. HEAD_PROTECION Object..................................20
8.2. Error Code............................................20
9. Conclusions................................................20
10. Acknowledgments...........................................20
11. References................................................20
11.1. Normative References..................................20
11.2. Informative References................................21
Author's Addresses............................................21
Cao, et al. Expires January 2, 2008 [Page 2]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
Intellectual Property Statement................................22
Disclaimer of Validity........................................22
Copyright Statement...........................................22
Cao, et al. Expires January 2, 2008 [Page 3]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
1. Terminology
LSR: Label-Switch Router. In this document all LSR should support
RSVP-TE extensions for P2MP LSP.
LSP: An MPLS Label-Switched Path. In this document, an LSP will
always be 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 backup up LSP for protecting the traffic.
MP: Merge Point. In this document MP generally is one hop downstream
neighbour to the MHN.
2. Introduction
RSVP-TE P2MP LSP has been deployed and many real-time applications
are running with such LSPs, so there is a strong requirement to
improve the robustness of the transmission. Before this document,
there are a lot of work have been done in RSVP-TE P2MP protection.
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 give solution for the LSP head node protection, which is a key
element for network 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.
Procedures defined in [RSVP](RFC2205), [RSVP-TE](RFC3209),[TE-FRR]and
[RSVP-P2MP](RFC4985)MUST be followed.
2.1. Motivation
Traditional protection methods use backup LSP or bypass tunnel to
forward the traffic. In the event of protected LSP failure, include
link failure or node failure, PLR will take the action to detour the
packets from PLR to MP through backup LSP or bypass tunnel. This
requires PLR must be a node of protected LSP and must be upstream to
the failure point. Such mechanism works well for protecting transit
links and transit LSRs. But it has no ability to protect the head
node of the LSP because there is no "upstream neighbour" to the head
node. In the real application, head node failure will cause more
serious side effect than transit link or nodes. So there is strong
requirement for reducing head node failure risk. One possible
Cao, et al. Expires January 2, 2008 [Page 4]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
solution today is 1+1 protection: deploying another P2MP tree from a
different LSR to all receivers. Obvious this is not a good method: it
will cost double bandwidth and require maintaining double forwarding
states in the devices. So it is highly desirable to find a method to
resolve this problem.
2.2. Head Node Protection Scenario
When real-time application is deployed, service providers (SP) always
try their best to avoid service interruption. Since failures are not
predictable so backup is always an effective and necessary solution.
It is common for SP to deploy double Source Server or make the
application server multi-homing to multiple edge routers. It can be a
typical environment for such applications:
[S1]-|---[R1]--[R2]--[R3]---[L1]----[ReceiverA]
| \/ | \/
| /\ | /\
|---[R4]--[R5]--[R6]---[L2]----[ReceiverB]
Figure 1. Source Multi-homing
In the simple topology shown in Figure 1, [S1] is an application
server; [Rx] and [Lx] are RSVP-TE P2MP LSP capable devices. [S1] is
multi-homing to LSR [R1] and [R4]. If multicast packets sent by [S1]
need to be transmitted to [L1] and [L2], a P2MP LSP (LSP1)start with
[R1] can be created with two sub-LSPs: [R1]->[R2]->[R3]-[L1] and
[R1]->[R5]->[R6]->[L2]. Packets from [S1] can be received by [R1] and
[R4]. If SP want to improve the robustness, another P2MP LSP (LSP2)
start 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 major path and the other one (LSP2) as 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 then begin to accept packets received from LSP2.
There may have some variations from Figure 1. The SP may want to
protect not only LSR failure but also application server failure. So
it is frequently found that two applications servers are deployed and
connected to two LSRs separately. It is shown in Figure 2 below:
Cao, et al. Expires January 2, 2008 [Page 5]
Internet-Draft <RSVP-TE P2MP Head Protection> July 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 generates 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 above
case depicted with Figure 1.
The above methods can work well but not in an effective way. Half of
the bandwidth is wasted during the most of time. LSRs have to
maintain as much as twice amount of P2MP LSP states. Also all leaves
have to deal with duplication traffic and monitor the LSP state to
determine which LSP is the major one. Comparing the two LSPs in above
cases, it is easy to be noticed that the only difference of the two
LSPs are the head nodes: LSP1 starts from [R1] and LSP2 starts from
[R4]. The transit nodes and leaves are same. So in such topology if
[R1] and [R4] cooperate together and act as backup node for each
other, then it is possible to build only one P2MP LSP and gains head
node protection ability as well.
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" to head node to detour the traffic, a LSR
have 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). Backup LSP or bypass
tunnel to protect MHN will be built from BHN to all NHOP LSRs of MHN.
In such case, those NHOP LSRs are the merge point (MP) LSPs. To
ensure all branches receive the traffic the MP set should include all
NHOP LSRs of MHN.
In normal operation source packets will arrive at MHN and BHN. BHN
drops the packets and there is no traffic on backup LSP or bypass
tunnels. When BHN detects there is a failure on MHN (There are
different mechanism to discover the node failure of MHN. The special
Cao, et al. Expires January 2, 2008 [Page 6]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
methods for discovering the failure are outside the scope of this
document), BHN will forward these packets to MPs and MPs will
recognize which LSP the packets belong to and forward the packets
along with rest of the protected LSP.
A LSR is eligible to be a BHN MUST satisfies the follow conditions:
- Traffic to be protected can be received from BHN without 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 is not 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. MP set includes LSR [R2] and
[R5].
Backup LSP against MHN failure starts from BHN to MPs. Theoretically
backup LSP can use unicast LSPs or P2MP TE LSPs. Consequently there
are two options for building backup LSP:
- 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 limitation to the backup LSP(s): the backup LSP(s) MUST
not transit MHN.
Since BHN, instead of MHN, has to send traffic to all downstream MPs,
BHN has to bind all the correlative backup LSPs info of a protected
P2MP LSP to one specific traffic source and MHN, a P2MP TE LSP is
more convenient to protect a P2MP LSP. And it is suitable for
facility backup. So P2MP LSP is chosen and discussed in this document.
In figure1 the backup P2MP TE LSP is composed with two sub-LSP: [R4]-
>[R2] and [R4]->[R5], which is referred to as a LSP BHN-Detour.
When a failure occurs in the MHN ([R1]), the BHN ([R4]) detects the
failure and redirects traffic on to the BHN detour along links [R4]-
>[R2] and [R4]->[R5], using the label received from the MPs ([R2] and
[R5])when [R4] created the BHN-Detour. While [R4] is using the BHN-
Cao, et al. Expires January 2, 2008 [Page 7]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
Detour, [R4] will recognize the traffic and should perform the MPLS
encapsulation. Merge points receive the detoured traffic from BHN and
merge them to protected LSP. From the view of MPs, the process is the
same to link failure protection.
Service interruption is not only caused by failure but may be caused
by regular operations, such as hardware upgrading or software patch
installation. Such operation is planned by SP and the un-availability
of the device can be predicted. This kind of operation is referred to
as Plan-Maintenance (PM). The head protection method described in
this document can also be used in PM scenario. For example, in
figure1, if [R1] has to stop forwarding due to some operation reason,
[R1] can assign [R4] as BHN and after [R4] build up BHN-Detour,
traffic can be transmitted through BHN-Detour. After the operation of
[R1] has been performed, [R1] can take over the traffic stream. So by
head-protection, side affection caused by [R1] operation can be
minimized.
Since head protection is performed by two LSRs, there are many
important differences between [TE-FRR] and head protection.
One big difference between [TE-FRR] and head-node protection is how
to tell PLR and BHN the information of 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 relative RSVP
Extensions. But BHN is not on the path of Protected LSP, so extra
messages will be sent by MHN to BHN to indicate BHN how to act.
Another difference is all LSRs on the path of P2MP LSP must be
refreshed by PATH message periodically. So in the case of MHN failure,
BHN must generate and send PATH messages to all downstream LSPs as if
these messages are sent by MHN.
The third difference is after the failure is repaired, how to revert
traffic from BHN back to original LSP. After MHN recovering from node
failure, MHN may lose all the RSVP TE P2MP states. So the before the
MHN takes the role of ingress node, MHN MUST synchronize the P2MP LSP
states between MHN and BHN. All the procedures will be described in
later of this draft.
2.3. Applicability Statement and Implementation Considerations
2.3.1. Topology Limitation
This document describes a mechanism that works only with the topology
that a suitable backup head node exists. A suitable backup head node
must satisfy the requirement listed in section 2.2.1. It is common to
Cao, et al. Expires January 2, 2008 [Page 8]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
construct such a network to get high availability, so it is not too
strict limitation for deploying head node protection.
2.3.2. Implementation Consideration
Head node protection should be compatible with existing protocols as
much as possible. Some consideration/requirement is listed bellow:
- Inherit existing protocol extensions. The new method should reuse
existing protocol extensions defined in [TE-FRR] as much as
possible. And the new method should be back compatible with
current mechanisms. Ideally, only MHN and BHN should be upgraded
and MPs and other LSR can be kept unchanged.
- When protection action is taken, the influence scope should be
limited. There should be no need to affect any MPs' downstream
nodes.
- After protection action is taken, BHN should works as the real
head node and can process all feedback from downstream LSRs.
3. Extensions to RSVP-TE
This document defines an additional object, which is referred to as
HEAD_PROTECTION object. This new object is backward compatible with
LSRs that do not recognize them. The new object is carried in RSVP
PATH message and RESV message.
3.1. HEAD_PROTECION Object
The HEAD_PROTECTION object is used to facilitate exchanging
information between MHN and BHN. MHN uses this object to specify
which LSR is BHN and advertise essential information of a protected
LSP. BHN also uses this object to facilitate synchronizing the
relevant information of the protected RSVP-TE P2MP LSP to MHN after
MHN is recovered from its node failure. BHN or MHN MUST not forward
this object to its 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. Mechanism
of transmit RSVP message over tunnel is described in [RFC2746].
Cao, et al. Expires January 2, 2008 [Page 9]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
Details of transmission through tunnel will be discussed in later
version of this document.
3.1.1. HEAD_PROTECTION for IPv4 address
Class-Num: TBD
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 local
address of the MHN can be used.
Backup_Head
IPv4 address identifying the LSR selected as BHN. Any local address
of the BHN can be used.
Flags
0x01(bit0): Head protection desired
0x02(bit1): Head protection available
0x04(bit2): Synchronization desired
0x08(bit3): Synchronization end
0x16(bit4): Synchronization end ack
0x32(bit5): Revertive indication
Bit0 is the lowest bit of the octet.
Cao, et al. Expires January 2, 2008 [Page 10]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
3.1.2. HEAD_PROTECTION for IPv6 address
Class-Num TBD
C-Type TBD
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 local address of the MHN can be used.
Backup_Head
An IPv6 128bits unicast address identifying the LSR selected as BHN.
Any local address of the BHN can be used.
Flags
0x01(bit0): Head protection desired
0x02(bit1): Head protection available
0x04(bit2): Synchronization desired
Cao, et al. Expires January 2, 2008 [Page 11]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
0x08(bit3): Synchronization end
0x16(bit4): Synchronization end ack
0x32(bit5): Revertive indication
Bit0 is the lowest bit of the octet.
3.1.3. SESSION_ATTRIBUTE Flags
Current SESSION_ATTRIBULTE object has defined several flags in
[RSVP_TE] and [TE_FRR]. To request head node protection, 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 should be requested and which LSR will be assigned as
backup head node (BHN). How to find a suitable LSR as BHN is out of
the scope of this document. Manual configuration is an effective and
easy choice.
MHN and BHN cooperate to setup backup LSPs. To reduce the affection
to other LSR on the path of P2MP tunnel, from the view of MP, BHN
builds the backup LSP as if a link protection LSP between MHN and MP
is created.
4.1. Behavior of MHN
If MHN decides to deploy head protection, MHN should act as link
protection is being deployed. That is, all flags required by link
protection should be set and necessary object required by link
protection should be carried in the PATH message. 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 and the traffic should be reverted to
protected LSP from BHN-Detour.
Cao, et al. Expires January 2, 2008 [Page 12]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
4.1.1. Signaling BHN for Head Protection
To build a BHN-Detour to protect the MHN, BHN must get enough
information about the protected LSP. A number of objectives must be
met:
- Unambiguously and uniquely identifying protected LSPs.
- Uniquely identifying the protected node.
- Clearly describing if bandwidth protection is desired
- Clear describing if one-to-one protection or facility backup is
desired.
- BHN should unambiguously know which LSRs are merge points (that is
the second hop LSRs of the P2MP LSP).
Fortunately most of the information is already included in PATH
message and this make the signaling easy. If MHN decides to deploy
head protection and selects a LSR as BHN, it MUST follow the behavior
described bellow:
- MHN record each PATH message sent to its down stream LSRs. MHN
rebuilds PATH messages according to the records 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. The object content should not
be changed during the same session.
- MHN sends the re-built PATH messages to BHN. If MHN and BHN are
directly connected, PATH message can be sent directly. Otherwise,
PATH message should be sent through a tunnel.
- If there is a topology change and there is a MP is newly desired
or newly grafted, MHN should send relevant PATH message to BHN
immediately to reflect the topology change.
MHN sends the PATH message containing HEAD_PROTECION object and
expects corresponding RESV message from BHN. After BHN has signaling
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.
Cao, et al. Expires January 2, 2008 [Page 13]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
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 occur node failure. When MHN is
recovered from a node failure, MHN should take the charge of sending
traffic along the protected P2MP LSP again. The revertive procedure
must be taken after RSVP-TE P2MP LSP has been re-constructed. One big
difficulty here is, after the node failure, MHN lost all states about
original LSPs. So fully retrieving the LSP states is the premise of
the revertive behavior. Since BHN receives all PATH messages from MHN
to build BHN-Detour, it is feasible for MHN to retrieve the lost
states and correlative information about the protected P2MP LSP from
BHN.
A number of assumptions must be satisfied and a number of objectives
must be met.
Assumption:
- After node failure, MHN should recognize which LSR is BHN that
will help it to recover.
- BHN has the ability to detect the recovering of a specific MHN.
Objectives:
- All RSVP-TE P2MP LSPs being protected by BHN SHOULD be re-
constructed by MHN.
- 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.
- The re-constructed LSP should have the same topology as before the
node failure.
- BHN should know the LSPs have been re-constructed and know when to
stop forwarding the traffic.
- BHN should know all essential information has already been sent to
MHN successfully.
After recovering from the node failure, MHN retrieves the RSVP-TE
P2MP LSPs' states by receiving PATH messages from BHN. BHN detects
the recovery and sends the PATH messages it receives from MHN before
Cao, et al. Expires January 2, 2008 [Page 14]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
the failure back to MHN. All PATH messages sent to MHN should contain
HEAD_PROTECTION object with "Synchronization desired" or
"synchronization end" flag set. A PATH message containing a HEAD
PROTECTION object with "synchronization end" flag set means the end
of synchronization. After synchronization, MHN has the ability to re-
construct the protected P2MP LSP again. The process has three phases
as below:
o State Synchronization
By receiving PATH message sent by BHN, MHN retrieves lost states of
the protected RSVP-TE P2MP LSP. Since each LSP contains one or more
sub-LSP, so there will one or multiple PATH messages to be received.
One PATH message carries one or more sub-LSP information, and each
sub-LSP should be explicitly described by ERO/Sub-ERO object. MHN
should response BHN by sending corresponding RESV messages to BHN.
RESV message should contain RRO/Sub-RRO corresponding to those PATH
messages.
During synchronization phase, all PATH and RESV messages MUST contain
HEAD_PROTECTION object. "Synchronization desired" or "Synchronization
end" flag should be set by BHN in PATH messages. If MHN receives a
PATH message with "Synchronization end" flag set in HEAD_PROTECION
object, which means all the states corresponding to a specific
protected P2MP LSP have been exchanged. The PATH message with
"Synchronization end" flag set can be referred to as a SYN-END PATH
message.
MHN would respond SYN-END PATH message in two different ways:
a) RESV message with "Synchronization end ack" flag set in
HEAD_PROTECTION object. This message is referred to as SYN-END-
ACK RESV message. SYN-END-ACK RESV message is used to inform BHN
that all states have been retrieved successfully but the original
protected P2MP LSP has not been re-constructed, BHN should
continue to take the charge of sending traffic along the backup
LSP(s) and hence to the rest of the protected P2MP LSP.
b) RESV message with "Revertive indication" flag set in
HEAD_PROTECTION object. Such RESV message is referred to as SYN-
REVERT RESV message. SYN-REVERT RESV message is used to inform
BHN MHN has already prepared for sending traffic again. When
received such message BHN should stop sending traffic on to the
backup LSP.
Before MHN finishes re-constructing LSP, MHN send SYN-END-ACK RESV
message to BHN to keep BHN maintaining the synchronization session
Cao, et al. Expires January 2, 2008 [Page 15]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
and continue forwarding traffic on to the protected P2MP LSP. SYN-
REVERT RESV message will be sent after protected LSP re-construction
has been completed.
o LSP Re-Construction
Have retrieving the states of the protected P2MP LSPs, MHN can re-
construct the LSP segments from MHN to MPs. LSP tunnels are
identified by SESSION and SESSION TEMPLATE objects. MHN must keep the
relevant fields (Tunnel end point address, Tunnel ID, Extended tunnel
ID, Tunnel sender address and LSP ID) value be same as those before
the node failure.
MHN should use the global revertive mode for link failure described
in [RSVP-TE-FRR].
o Traffic revert back to MHN
After MHN re-constructing the protected P2MP LSP, MHN sends SYN-
REVERT RESV message to BHN. Then MHN begins to sending traffic ont to
the protected P2MP LSP.
To reduce the side effect of SYN-REVERT RESV message loss, MHN may
send multiple (default value is 2) messages to BHN continuously.
After sending SYN-END-REVERT message to BHN, MHN must not respond any
PATH messages sent by BHN for the same session.
After the traffic is reverted, MHN takes the role as a normal head-
end of a P2MP LSP. MHN begins to send PATH message to all egress
leaves and process RESV messages received. Also MHN sends PATH
message to BHN as described in section 4.1.1 to deploy head node
protection.
MHN MUST NOT send PATH message contain HEAD_PROTECTION object to BHN
before traffic is reverted back because this will cause BHN stop
forwarding packets through BHN-Detour.
4.2. Behavior of BHN
BHN is responsible to create BHN-Detours to protect the head node and
play the role as a head node during the MHN failure. Also BHN helps
MHN to re-construct protected LSP after the recovery of the node
failure.
There are two different procedures for BHN:
- Signaling BHN-Detour and rerouting traffic for protection.
Cao, et al. Expires January 2, 2008 [Page 16]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
- 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 has
received PATH message from other LSR of the same SESSION, that
means BHN is on the path of protected tunnel, BHN MUST send RESV
message with HEAD_PROTECTION_ERROR notification to MHN.
- BHN MUST check the IP address in "backup head" in HEAD_PROTECION
object. If the BHN dose not have such IP address, BHN must send
back ERROR notification to MHN.
- After check the validity of PATH message, BHN processes the
objects in PATH message. BHN MUST record SESSION and
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. In the view of MPs,
the backup LSP is used for link failure (MHN->MP) protection.
- After BHN-Detour is created, BHN send RESV message with "Head
protection available" flag set. This informs MHN that BHN-Detour
is ready. This is important for PM scenario.
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 be unchanged.
- BHN periodically sends PATH messages to all MPs to refresh the
state of protected LSP. In the view of downstream LSRs, the PATH
messages are generated by MHN but not BHN.
Cao, et al. Expires January 2, 2008 [Page 17]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
4.2.2. Revertive Procedures for BHN
During the protection period, BHN should take some action to detect
if MHN is recovered. The detection methods are out of the scope of
this document.
Once BHN detects MHN is recovered, follow action should be taken to
coordinate MHN complete revertive procedures:
The process has two phases:
o State Synchronization
Before protection, BHN records all states of protected P2MP LSPs. BHN
build PATH messages according to the records as the messages received
from MHN. Each PATH message contains ERO/SERO of sub-LSPs and
HEAD_PROTECTION object. The PATH message MUST have HEAD_PROTECION
object with "Synchronization desired" flag set.
BHN periodically sends PATH messages to MHN and expects RESV message
corresponding to PATH message. If BHN receives acknowledgement from
MHN with RESV message, BHN checks the RRO/SRRO and identify which
sub-LSP information has been synchronized.
If all sub-LSP information has been synchronized by PATH message, BHN
sends SYN-END PATH message to MHN and wait SYN-END-ACK or REVERTIVE-
INDICATION RESV message. Before REVERTIVE-INDICATION PATH message is
received, BHN keep forwarding the traffic through BHN-Detour. If
REVERTIVE-INDICATION PATH message is received, BHN stops forwarding
and come into BHN-Detour refresh phases as described bellow.
o BHN-Detour Refresh
Receiving REVERTIVE-INDICATION RESV message indicates MHN has
completed all revertive procedures and take the role as a normal head
end. BHN expects the PATH message with HEAD_PROTECTION object from
MHN. If BHN dose not receive such PATH message, BHN should regard
BHN-Detour is not needed by MHN and all states should be timed out
and records should be removed, backup LSP should be tore down.
4.3. Protection Teardown
MHN can teardown head protection when necessary.
Cao, et al. Expires January 2, 2008 [Page 18]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
4.3.1. Protection Teardown
MHN may decide to destroy the head protection. There are two ways to
indicate BHN: implicit and explicit.
o Implicit teardown
If MHN decides use implicit teardown method, it just stops sending
PATH message to BHN. States of protected tunnels in BHN will be
expired because of less of refreshment. BHN then teardown BHN-Detour
and clear all states and records expired. BHN has to distinguish
state expiration because of implicit teardown and because of MHN
failure. If BHN find MHN is in error, implicit teardown can not be
taken.
o Explicit teardown
If MHN decides use explicit teardown to inform BHN teardown
immediately, BHN sends PATH Tear message with HEAD_PROTECTION. This
PATH message may contain SESSION and SESSION_TEMPLATE and without any
ERO/SERO objects, which is used to inform BHN all related states of
the protected LSP should be removed.
5. Behavior of Merge Nodes
As stated before in this document, in order to reduce the compact to
MPs, this document does not try to add new functionalities to MPs.
From the aspect of MPs, they still have the same behaviors as
described in [TE-FRR] and [P2MP-TE]. It means that MPs do not need to
be aware of such head node protection, they just consider themselves
as the MPs of normal link protection.
One thing needs to be noted that MPs would receive duplicated traffic
for the same data, it may happens during the switching period from
MHN to BHN (PM scenario), and vice versa. Currently, from the control
plane, there is no good method to resolve this issue. So MPs should
better have the ability to handle such situation, especially for the
data plane of MPs, how to handle the duplicated traffic is out of
scope this document.
6. Behavior of All Other LSRs
To deploy head protection, only MHN and BHN should upgrade to support
new extensions and execute new procedures. Other LSRs' behavior is
not changed.
Cao, et al. Expires January 2, 2008 [Page 19]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
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
The new number of Class-Num and C-Type for the new defined RSVP-TE
objects should be assigned by IANA.
8.1. HEAD_PROTECION Object
TBD
8.2. Error Code
TDB
9. Conclusions
Head node protection can not only work for failure protection, but
also can help for SP planned maintenance. Service interruption is
caused by not only network device failure but also some inevitable
administrative operation, such as line card upgrade or software patch
installation. With mechanisms described above, SP can provide service
without interruption by switching the two LSP as active at
appropriate time.
10. Acknowledgments
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.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
Cao, et al. Expires January 2, 2008 [Page 20]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS Architecture",
RFC 3031.
[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.
11.2. Informative References
[Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in
TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp.
1573-1583.
[MPLS-UPSTREAM] Aggarwal, Rekhter, Rosen, "MPLS Upstream Label
Assignment and Context Specific Label Space", draft-ietf-
mpls-upstream-label, work in progress.
[RSVP-UP] Aggarwal, Le Roux, " MPLS Upstream Label Assignment for
RSVP-TE", draft-ietf-mpls-rsvp-upstream, work in progress
[P2MP-TE-Bypass] Le Roux, Aggarwal, R., Vasseur, J.P., and Vigoureux,
M., "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels",
draft-ietf-mpls-p2mp-te-bypass-00.txt, work in progress.
Author's Addresses
Wei Cao
Huawei Technologies
Room 201R, Kuike building, Shangdi,
Haidian District of Beijing, P.R. China
Email: caowayne@huawei.com
Cao, et al. Expires January 2, 2008 [Page 21]
Internet-Draft <RSVP-TE P2MP Head Protection> July 2007
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.
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).
Cao, et al. Expires January 2, 2008 [Page 22]
Internet-Draft <RSVP-TE P2MP Head Protection> July 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 January 2, 2008 [Page 23]