draft-ietf-teas-gmpls-lsp-fastreroute-11.txt   draft-ietf-teas-gmpls-lsp-fastreroute-12.txt 
TEAS Working Group M. Taillon TEAS Working Group M. Taillon
Internet-Draft T. Saad, Ed. Internet-Draft T. Saad, Ed.
Updates: 4090 R. Gandhi, Ed. Updates: 4090 R. Gandhi, Ed.
Intended Status: Standards Track Z. Ali Intended Status: Standards Track Z. Ali
Expires: February 4, 2018 Cisco Systems, Inc. Expires: March 1, 2018 Cisco Systems, Inc.
M. Bhatia M. Bhatia
Nokia Nokia
August 3, 2017 August 28, 2017
Updates to Resource Reservation Protocol For Fast Reroute of Updates to Resource Reservation Protocol For Fast Reroute of
Traffic Engineering GMPLS LSPs Traffic Engineering GMPLS LSPs
draft-ietf-teas-gmpls-lsp-fastreroute-11 draft-ietf-teas-gmpls-lsp-fastreroute-12
Abstract Abstract
This document updates the Resource Reservation Protocol - Traffic This document updates the Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC
4090 to support Packet Switched Capable (PSC) Generalized Multi- 4090 to support Packet Switched Capable (PSC) Generalized Multi-
Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These
updates allow the coordination of a bidirectional bypass tunnel updates allow the coordination of a bidirectional bypass tunnel
assignment protecting a common facility in both forward and reverse assignment protecting a common facility in both forward and reverse
directions of a co-routed bidirectional LSP. In addition, these directions of a co-routed bidirectional LSP. In addition, these
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 6 3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 6
4. Bypass Tunnel Assignment For Bidirectional GMPLS LSPs . . . . 6 4. Bypass Tunnel Assignment For Bidirectional GMPLS LSPs . . . . 6
4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 7 4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 7
4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 7 4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 7
4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 7 4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 7
4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 8 4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 8
4.5. Bidirectional Bypass Tunnel Assignment Co-ordination . . . 8 4.5. Bidirectional Bypass Tunnel Assignment Co-ordination . . . 8
4.5.1. Bidirectional Bypass Tunnel Assignment Signaling 4.5.1. Bidirectional Bypass Tunnel Assignment Signaling
Procedure . . . . . . . . . . . . . . . . . . . . . . 8 Procedure . . . . . . . . . . . . . . . . . . . . . . 8
4.5.2. One-to-one Bidirectional Bypass Tunnel Assignment . . 9 4.5.2. One-to-one Bidirectional Bypass Tunnel Assignment . . 10
4.5.3. Multiple Bidirectional Bypass Tunnel Assignments . . . 10 4.5.3. Multiple Bidirectional Bypass Tunnel Assignments . . . 10
5. Fast Reroute For Bidirectional GMPLS LSPs with In-band 5. Fast Reroute For Bidirectional GMPLS LSPs with In-band
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Link Protection for Bidirectional GMPLS LSPs . . . . . . . 11 5.1. Link Protection for Bidirectional GMPLS LSPs . . . . . . . 12
5.1.1. Behavior After Link Failure . . . . . . . . . . . . . 12 5.1.1. Behavior After Link Failure . . . . . . . . . . . . . 12
5.1.2. Revertive Behavior After Fast Reroute . . . . . . . . 12 5.1.2. Revertive Behavior After Fast Reroute . . . . . . . . 12
5.2. Node Protection for Bidirectional GMPLS LSPs . . . . . . . 12 5.2. Node Protection for Bidirectional GMPLS LSPs . . . . . . . 13
5.2.1. Behavior After Link Failure . . . . . . . . . . . . . 13 5.2.1. Behavior After Link Failure . . . . . . . . . . . . . 14
5.2.2. Behavior After Link Failure To Re-coroute . . . . . . 13 5.2.2. Behavior After Link Failure To Re-coroute . . . . . . 14
5.2.2.1. Re-coroute in Data-plane After Link Failure . . . 14 5.2.2.1. Re-coroute in Data-plane After Link Failure . . . 15
5.2.3. Revertive Behavior After Fast Reroute . . . . . . . . 15 5.2.3. Revertive Behavior After Fast Reroute . . . . . . . . 15
5.3. Unidirectional Link Failures . . . . . . . . . . . . . . . 15 5.2.4. Behaviour After Node Failure . . . . . . . . . . . . . 16
5.3. Unidirectional Link Failures . . . . . . . . . . . . . . . 16
6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band 6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Message and Object Definitions . . . . . . . . . . . . . . . . 16
7.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 16 7. Message and Object Definitions . . . . . . . . . . . . . . . . 17
7.2. FRR Bypass Assignment Error Notify Message . . . . . . . . 18 7.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 17
8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. FRR Bypass Assignment Error Notify Message . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 19 10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 22
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Packet Switched Capable (PSC) Traffic Engineering (TE) Label Switched Packet Switched Capable (PSC) Traffic Engineering (TE) Label Switched
Paths (LSPs) can be setup using Generalized Multi-Protocol Label Paths (LSPs) can be setup using Generalized Multi-Protocol Label
Switching (GMPLS) signaling procedures specified in [RFC3473] for Switching (GMPLS) signaling procedures specified in [RFC3473] for
both unidirectional and bidirectional tunnels. The GMPLS signaling both unidirectional and bidirectional tunnels. The GMPLS signaling
allows sending and receiving the RSVP messages in-band with the data allows sending and receiving the RSVP messages in-band with the data
traffic or out-of-band over a separate control-channel. Fast Reroute traffic or out-of-band over a separate control-channel. Fast Reroute
(FRR) [RFC4090] has been widely deployed in the packet TE networks (FRR) [RFC4090] has been widely deployed in the packet TE networks
skipping to change at page 8, line 40 skipping to change at page 8, line 40
bypass tunnel that is assigned at a downstream PLR to protect a bypass tunnel that is assigned at a downstream PLR to protect a
bidirectional LSP. bidirectional LSP.
When the procedures defined in this document are in use, the When the procedures defined in this document are in use, the
BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in
the RSVP Path RRO message of the GMPLS signaled bidirectional the RSVP Path RRO message of the GMPLS signaled bidirectional
protected LSP to record the downstream bidirectional bypass tunnel protected LSP to record the downstream bidirectional bypass tunnel
assignment. This subobject is sent in the RSVP Path RRO message assignment. This subobject is sent in the RSVP Path RRO message
every time the downstream PLR assigns or updates the bypass tunnel every time the downstream PLR assigns or updates the bypass tunnel
assignment. The downstream PLR can assign a bypass tunnel when assignment. The downstream PLR can assign a bypass tunnel when
processing the first Path message of the protected LSP, however, it processing the first Path message of the protected LSP as long as it
can not update the forwarding plane until it receives the Resv has a topological view of the downstream MP and the traversed path
message containing the downstream MP label. information in ERO. For the protected LSP where the downstream MP
cannot be determined from the first Path message (e.g. when using
loose hops in ERO), the downstream PLR needs to wait for Resv message
with RRO in order to assign a bypass tunnel. However, in both cases,
the downstream PLR cannot update the data-plane until it receives
Resv messages containing the MP labels.
The upstream PLR (downstream MP) simply reflects the bypass tunnel The upstream PLR (downstream MP) simply reflects the bypass tunnel
assignment in the reverse direction. The absence of assignment in the reverse direction. The absence of
BYPASS_ASSIGNMENT subobject in RRO means that the relevant node or BYPASS_ASSIGNMENT subobject in Path RRO means that the relevant node
interface is not protected by a bidirectional bypass tunnel. Hence, or interface is not protected by a bidirectional bypass tunnel.
the upstream PLR need not assign a bypass tunnel in the reverse
direction.
When the BYPASS_ASSIGNMENT subobject is added in the RRO: Hence, the upstream PLR need not assign a bypass tunnel in the
reverse direction.
When the BYPASS_ASSIGNMENT subobject is added in the Path RRO:
o The IPv4 or IPv6 subobject containing Node-ID address MUST also be o The IPv4 or IPv6 subobject containing Node-ID address MUST also be
added [RFC4561]. The Node-ID address MUST match the source added [RFC4561]. The Node-ID address MUST match the source
address of the bypass tunnel selected for this protected LSP. address of the bypass tunnel selected for this protected LSP.
o The BYPASS_ASSIGNMENT subobject MUST be added immediately after o The BYPASS_ASSIGNMENT subobject MUST be added immediately after
the Node-ID address. the Node-ID address.
o The Label subobject MUST also be added [RFC3209]. o The Label subobject MUST also be added [RFC3209].
The rules for adding an IPv4 or IPv6 Interface address subobject and The rules for adding an IPv4 or IPv6 Interface address subobject and
Unnumbered Interface ID subobject as specified in [RFC3209] and Unnumbered Interface ID subobject as specified in [RFC3209] and
[RFC4090] are not modified by the above procedure. The options [RFC4090] are not modified by the above procedure. The options
specified in Section 6.1.3 in [RFC4990] are also applicable as long specified in Section 6.1.3 in [RFC4990] are also applicable as long
as above mentioned rules are followed when using the FRR procedures as above mentioned rules are followed when using the FRR procedures
defined in this document. defined in this document.
An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT
subobjects in the Path RRO in order to assign a reverse bypass subobjects in the Path RRO to see if the destination address in the
tunnel. The upstream PLR that detects a BYPASS_ASSIGNMENT subobject, BYPASS_ASSIGNMENT matches the address of the upstream PLR. For each
selects a reverse bypass tunnel that terminates locally with the BYPASS_ASSIGNMENT subobject that matches, the upstream PLR looks for
destination address and tunnel-ID from the subobject, and has a a tunnel that has a source address matching the downstream PLR that
source address matching the Node-ID address. The RRO can contain inserted the BYPASS_ASSIGNMENT, as indicated by the Node-ID address,
multiple addresses to identify a node, however, the upstream PLR and the same tunnel-ID as indicated in the BYPASS_ASSIGNMENT. The
relies on the Node-ID address preceding the BYPASS_ASSIGNMENT RRO can contain multiple addresses to identify a node, however, the
subobject for identifying the bypass tunnel. If the bypass tunnel is upstream PLR relies on the Node-ID address preceding the
not found, the upstream PLR SHOULD send a Notify message [RFC3473] BYPASS_ASSIGNMENT subobject for identifying the bypass tunnel. If
with Error-code - FRR Bypass Assignment Error (value: TBA1) and Sub- the bypass tunnel is not found, the upstream PLR SHOULD send a Notify
code - Bypass Tunnel Not Found (value: TBA3) to the downstream PLR. message [RFC3473] with Error-code - FRR Bypass Assignment Error
Upon receiving this error, the downstream PLR SHOULD remove the (value: TBA1) and Sub-code - Bypass Tunnel Not Found (value: TBA3) to
bypass tunnel assignment and select an alternate bypass tunnel if one the downstream PLR. Upon receiving this error, the downstream PLR
available. The RRO containing BYPASS_ASSIGNMENT subobject(s) is then SHOULD remove the bypass tunnel assignment and select an alternate
simply forwarded downstream in the RSVP Path message. bypass tunnel if one available. The RRO containing BYPASS_ASSIGNMENT
subobject(s) is then simply forwarded downstream in the RSVP Path
message.
A downstream PLR may add, remove or change bypass tunnel assignment
for a protected LSP resulting in addition, removal or modification of
BYPASS_ASSIGNMENT subobject in the Path RRO, respectively. In this
case, the downstream PLR SHOULD generate modified Path message and
forward it downstream. The downstream MP SHOULD check the RRO in the
received Path message and update the bypass tunnel assignment in the
reverse direction accordingly.
4.5.2. One-to-one Bidirectional Bypass Tunnel Assignment 4.5.2. One-to-one Bidirectional Bypass Tunnel Assignment
The bidirectional bypass tunnel assignment co-ordination procedure The bidirectional bypass tunnel assignment co-ordination procedure
defined in this document can be used for both facility backup defined in this document can be used for both facility backup
described in Section 3.2 of [RFC4090] and one-to-one backup described described in Section 3.2 of [RFC4090] and one-to-one backup described
in Section 3.1 of [RFC4090]. As specified in [RFC4090], Section 4.2, in Section 3.1 of [RFC4090]. As specified in [RFC4090], Section 4.2,
the DETOUR_OBJECT can be used in one-to-one backup method to identify the DETOUR_OBJECT can be used in one-to-one backup method to identify
the detour LSPs. In one-to-one backup method, if the bypass tunnel the detour LSPs. In one-to-one backup method, if the bypass tunnel
is already in-use at the upstream PLR, it SHOULD send a Notify is already in-use at the upstream PLR, it SHOULD send a Notify
message [RFC3473] with Error-code - FRR Bypass Assignment Error message [RFC3473] with Error-code - FRR Bypass Assignment Error
(value: TBA1) and Sub-code - One-to-one Bypass Already In-use (value: (value: TBA1) and Sub-code - One-to-one Bypass Already In-use (value:
TBA4) to the downstream PLR. Upon receiving this error, the TBA4) to the downstream PLR. Upon receiving this error, the
downstream PLR SHOULD remove the bypass tunnel assignment and select downstream PLR SHOULD remove the bypass tunnel assignment and select
an alternate bypass tunnel if one available. an alternate bypass tunnel if one available.
4.5.3. Multiple Bidirectional Bypass Tunnel Assignments 4.5.3. Multiple Bidirectional Bypass Tunnel Assignments
The upstream PLR may receive multiple bypass tunnel assignments for a The upstream PLR may receive multiple bypass tunnel assignments for a
protected LSP from different downstream PLRs. The choice of a protected LSP from different downstream PLRs leading to an asymmetric
reverse bypass tunnel is based on the local policy on the upstream bypass tunnel assignment as shown in the following two examples.
PLR. Examples of such a policy could be to prefer link protection
over node protection, or to prefer the bypass tunnel to the furthest
upstream node.
As shown in Example 1 and Example 2, for the protected bidirectional As shown in Example 1 and Example 2, for the protected bidirectional
GMPLS LSP R4-R5-R6, the upstream PLR R6 receives multiple bypass GMPLS LSP R4-R5-R6, the upstream PLR R6 receives multiple bypass
tunnel assignments, one from downstream PLR R4 for node protection tunnel assignments, one from downstream PLR R4 for node protection
and one from downstream PLR R5 for link protection. In Example 1, R6 and one from downstream PLR R5 for link protection. In Example 1, R6
prefers the link protection bypass tunnel from downstream PLR R5 prefers the link protection bypass tunnel from downstream PLR R5
whereas in Example 2, R6 prefers the node protection bypass tunnel whereas in Example 2, R6 prefers the node protection bypass tunnel
from downstream PLR R4. from downstream PLR R4.
+------->>-------+ +------->>-------+
skipping to change at page 10, line 45 skipping to change at page 11, line 11
/ / \ \ / / \ \
/ / \ \ / / \ \
[R4]--->>---[R5]--->>---[R6] [R4]--->>---[R5]--->>---[R6]
\ PATH -> / \ PATH -> /
\ / \ /
\ / \ /
+-------<<--------+ +-------<<--------+
Example 2: Node protection is preferred on downstream MP Example 2: Node protection is preferred on downstream MP
In both examples above, the upstream PLR SHOULD send a Notify message The asymmetry of bypass tunnel assignments can be avoided by using
[RFC3473] with Error-code - FRR Bypass Assignment Error (value: TBA1) the flags in the SESSION_ATTRIBUTES Object defined in Section 4.3 of
and Sub-code - Bypass Assignment Cannot Be Used (value: TBA2) to the [RFC4090]. In particular, the "node protection desired" flag is
downstream PLR to indicate that it cannot use the bypass tunnel signaled by the head-end node to request node protection bypass
assignment in the reverse direction. Upon receiving this error, the tunnels. When this flag is set, both downstream PLR and upstream PLR
downstream PLR MAY remove the bypass tunnel assignment and select an nodes assign node protection bypass tunnels as shown in Example 2.
alternate bypass tunnel if one available. In the absence of "node protection desired" flag set, the downstream
PLR nodes may only signal the link protection bypass tunnels avoiding
the asymmetry of bypass tunnel assignments shown in Example 1.
When multiple bypass tunnel assignments are received, the upstream
PLR SHOULD send a Notify message [RFC3473] with Error-code - FRR
Bypass Assignment Error (value: TBA1) and Sub-code - Bypass
Assignment Cannot Be Used (value: TBA2) to the downstream PLR to
indicate that it cannot use the bypass tunnel assignment in the
reverse direction. Upon receiving this error, the downstream PLR MAY
remove the bypass tunnel assignment and select an alternate bypass
tunnel if one available.
If multiple bypass tunnel assignments are present on the upstream PLR If multiple bypass tunnel assignments are present on the upstream PLR
R6 at the time of a failure, any resulted asymmetry gets corrected R6 at the time of a failure, any resulted asymmetry gets corrected
using the re-coroute procedure after FRR as specified in Section using the re-coroute procedure after FRR as specified in Section
5.2.2 of this document. 5.2.2 of this document.
5. Fast Reroute For Bidirectional GMPLS LSPs with In-band Signaling 5. Fast Reroute For Bidirectional GMPLS LSPs with In-band Signaling
When a bidirectional bypass tunnel is used, after a link failure, When a bidirectional bypass tunnel is used, after a link failure,
following procedure is followed when using the in-band signaling: following procedure is followed when using the in-band signaling:
o The downstream PLR reroutes traffic and RSVP Path signaling over o The downstream PLR reroutes protected LSP traffic and RSVP Path
the bidirectional bypass tunnel using the procedures defined in signaling over the bidirectional bypass tunnel using the
[RFC4090]. procedures defined in [RFC4090]. The RSVP Path messages are
modified as described in Section 6.4.3 of [RFC4090].
o Upstream PLR reroutes traffic upon detecting the link failure or o The upstream PLR reroutes protected LSP traffic upon detecting the
upon receiving RSVP Path message over the bidirectional bypass link failure or upon receiving RSVP Path message over the
tunnel. bidirectional bypass tunnel.
o Upstream PLR also reroutes RSVP Resv signaling after receiving o The upstream PLR also reroutes protected LSP RSVP Resv signaling
RSVP Path message over the bidirectional bypass tunnel. after receiving the modified RSVP Path message over the
bidirectional bypass tunnel. The upstream PLR uses the procedure
defined in Section 7 of [RFC4090] to detect that RSVP Path
messages have been rerouted over the bypass tunnel by the
downstream PLR. The upstream PLR does not modify the RSVP Resv
message before sending it over the bypass tunnel.
The above procedure allows both traffic and RSVP signaling to flow on The above procedure allows both traffic and RSVP signaling to flow on
symmetric paths in the forward and reverse directions of a protected symmetric paths in the forward and reverse directions of a protected
bidirectional GMPLS LSP. The following sections describe the bidirectional GMPLS LSP. The following sections describe the
handling for link protection and node protection bypass tunnels. handling for link protection and node protection bypass tunnels.
5.1. Link Protection for Bidirectional GMPLS LSPs 5.1. Link Protection for Bidirectional GMPLS LSPs
<- RESV <- RESV
[R1]----[R2]----[R3]-----x-----[R4]----[R5]----[R6] [R1]----[R2]----[R3]-----x-----[R4]----[R5]----[R6]
skipping to change at page 13, line 28 skipping to change at page 14, line 9
PLR after the link failure. The first phase comprises of FRR PLR after the link failure. The first phase comprises of FRR
procedures to fast reroute data traffic onto bypass tunnels in the procedures to fast reroute data traffic onto bypass tunnels in the
forward and reverse directions. The second phase re-coroutes the forward and reverse directions. The second phase re-coroutes the
data and signaling in the forward and reverse directions after the data and signaling in the forward and reverse directions after the
first phase. first phase.
5.2.1. Behavior After Link Failure 5.2.1. Behavior After Link Failure
Consider a link R3-R4 (in Figure 2) on the protected LSP path fails. Consider a link R3-R4 (in Figure 2) on the protected LSP path fails.
The downstream PLR R3 and upstream PLR R4 independently trigger fast The downstream PLR R3 and upstream PLR R4 independently trigger fast
reroute procedures to redirect traffic onto respective bypass tunnels reroute procedures to redirect the protected LSP traffic onto
T2 and T1 in the forward and reverse directions. The downstream PLR respective bypass tunnels T2 and T1 in the forward and reverse
R3 also reroutes RSVP Path messages over the bypass tunnel T2 using directions. The downstream PLR R3 also reroutes RSVP Path messages
the procedures described in [RFC4090]. Note, at this point, node R4 over the bypass tunnel T2 using the procedures described in
stops receiving RSVP Path refreshes for the protected bidirectional [RFC4090]. Note, at this point, node R4 stops receiving RSVP Path
LSP while protected traffic continues to flow over bypass tunnels. refreshes for the protected bidirectional LSP while protected traffic
As node R4 does not receive Path messages, it does not reroute RSVP continues to flow over bypass tunnels. As node R4 does not receive
Resv messages over the reverse bypass tunnel. Path messages over bypass tunnel T1, it does not reroute RSVP Resv
messages over the reverse bypass tunnel T1.
5.2.2. Behavior After Link Failure To Re-coroute 5.2.2. Behavior After Link Failure To Re-coroute
The downstream MP R5 that receives rerouted protected LSP RSVP Path The downstream MP R5 that receives rerouted protected LSP RSVP Path
message through the bypass tunnel, in addition to the regular MP message through the bypass tunnel, in addition to the regular MP
processing defined in [RFC4090], gets promoted to a Point of Remote processing defined in [RFC4090], gets promoted to a Point of Remote
Repair (PRR) role and performs the following actions to re-coroute Repair (PRR) role and performs the following actions to re-coroute
signaling and data traffic over the same path in the reverse signaling and data traffic over the same path in the reverse
direction: direction:
skipping to change at page 14, line 8 skipping to change at page 14, line 39
on the downstream PLR R3. Note: the downstream PLR R3's address on the downstream PLR R3. Note: the downstream PLR R3's address
can be extracted from the "IPV4 tunnel sender address" in the can be extracted from the "IPV4 tunnel sender address" in the
SENDER_TEMPLATE Object of the protected LSP (see [RFC4090], SENDER_TEMPLATE Object of the protected LSP (see [RFC4090],
Section 6.1.1). Section 6.1.1).
o If reverse bypass tunnel is found and the protected LSP traffic is o If reverse bypass tunnel is found and the protected LSP traffic is
not already rerouted over the found bypass tunnel T2, the PRR R5 not already rerouted over the found bypass tunnel T2, the PRR R5
activates FRR reroute procedures to direct traffic over the found activates FRR reroute procedures to direct traffic over the found
bypass tunnel T2 in the reverse direction. In addition, the PRR bypass tunnel T2 in the reverse direction. In addition, the PRR
R5 also reroutes RSVP Resv over the bypass tunnel T2 in the R5 also reroutes RSVP Resv over the bypass tunnel T2 in the
reverse direction. reverse direction. This can happen when the downstream PLR has
changed the bypass tunnel assignment but the upstream PLR has not
yet processed the updated Path RRO and programmed the data-plane
when link failure occurs.
o If reverse bypass tunnel is not found, the PRR R5 immediately o If reverse bypass tunnel is not found, the PRR R5 immediately
tears down the protected LSP. tears down the protected LSP.
<- RESV <- RESV
[R1]----[R2]----[R3]--X--[R4]----[R5]----[R6] [R1]----[R2]----[R3]--X--[R4]----[R5]----[R6]
PATH -> \ / PATH -> \ /
\ / \ /
+<<------->>+ +<<------->>+
Bypass Tunnel T2 Bypass Tunnel T2
traffic + signaling traffic + signaling
Protected LSP: {R1-R2-R3-R4-R5-R6} Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T2: {R3-R5} R3's Bypass T2: {R3-R5}
Figure 3: Flow of RSVP signaling after FRR and re-coroute Figure 3: Flow of RSVP signaling after FRR and re-coroute
Figure 3 describes the path taken by the traffic and signaling after Figure 3 describes the path taken by the traffic and signaling after
completing re-coroute of data and signaling in the forward and completing re-coroute of data and signaling in the forward and
skipping to change at page 15, line 17 skipping to change at page 15, line 51
The revertive behavior defined in [RFC4090], Section 6.5.2, is The revertive behavior defined in [RFC4090], Section 6.5.2, is
applicable to the node protection of bidirectional GMPLS LSPs. When applicable to the node protection of bidirectional GMPLS LSPs. When
using the local revertive mode, after the link R3-R4 (in Figures 2 using the local revertive mode, after the link R3-R4 (in Figures 2
and 3) is restored, following node behaviors apply: and 3) is restored, following node behaviors apply:
o The downstream PLR R3 starts sending the Path messages and traffic o The downstream PLR R3 starts sending the Path messages and traffic
flow of the protected LSP over the restored link and stops sending flow of the protected LSP over the restored link and stops sending
them over the bypass tunnel. them over the bypass tunnel.
o The upstream PLR R4 starts sending the traffic flow of the o The upstream PLR R4 (when the protected LSP is present) starts
protected LSP over the restored link towards downstream PLR R3 and sending the traffic flow of the protected LSP over the restored
forwarding the Path messages towards PRR R5 and stops sending the link towards downstream PLR R3 and forwarding the Path messages
traffic over the bypass tunnel. towards PRR R5 and stops sending the traffic over the bypass
tunnel.
o When upstream PLR R4 receives the protected LSP Path messages over o When upstream PLR R4 receives the protected LSP Path messages over
the restored link, if not already done, it starts sending Resv the restored link, if not already done, the node R4 (when the
messages and traffic flow over the restored link towards protected LSP is present) starts sending Resv messages and traffic
downstream PLR R3 and forwarding the Path messages towards PRR R5 flow over the restored link towards downstream PLR R3 and
and stops sending them over the bypass tunnel. forwarding the Path messages towards PRR R5 and stops sending them
over the bypass tunnel.
o When PRR R5 receives the protected LSP Path messages over the o When PRR R5 receives the protected LSP Path messages over the
restored path, it starts sending Resv messages and traffic flow restored path, it starts sending Resv messages and traffic flow
over the restored path and stops sending them over the bypass over the restored path and stops sending them over the bypass
tunnel. tunnel.
5.2.4. Behaviour After Node Failure
Consider the node R4 (in Figure 3) on the protected LSP path fails.
The downstream PLR R3 and upstream PLR R5 independently trigger fast
reroute procedures to redirect the protected LSP traffic onto bypass
tunnel T2 in forward and reverse directions. The downstream PLR R3
also reroutes RSVP Path messages over the bypass tunnel T2 using the
procedures described in [RFC4090]. The upstream PLR R5 reroutes RSVP
Resv signaling after receiving the modified RSVP Path message over
the bypass tunnel T2.
5.3. Unidirectional Link Failures 5.3. Unidirectional Link Failures
Unidirectional link failures can result in the traffic flowing on Unidirectional link failures can result in the traffic flowing on
asymmetric paths in the forward and reverse directions. In addition, asymmetric paths in the forward and reverse directions. In addition,
unidirectional link failures can cause RSVP soft-state timeout in the unidirectional link failures can cause RSVP soft-state timeout in the
control-plane in some cases. As an example, if the unidirectional control-plane in some cases. As an example, if the unidirectional
link failure is in the upstream direction (from R4 to R3 in Figures 1 link failure is in the upstream direction (from R4 to R3 in Figures 1
and 2), the downstream PLR (node R3) can stop receiving the Resv and 2), the downstream PLR (node R3) can stop receiving the Resv
messages of the protected LSP from the upstream PLR (node R4 in messages of the protected LSP from the upstream PLR (node R4 in
Figures 1 and 2) and this can cause RSVP soft-state timeout to occur Figures 1 and 2) and this can cause RSVP soft-state timeout to occur
skipping to change at page 22, line 11 skipping to change at page 23, line 11
[RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE
Extensions for Associated Bidirectional LSPs", RFC 7551, Extensions for Associated Bidirectional LSPs", RFC 7551,
May 2015. May 2015.
Acknowledgements Acknowledgements
Authors would like to thank George Swallow for many useful comments Authors would like to thank George Swallow for many useful comments
and suggestions. Authors would like to thank Lou Berger for the and suggestions. Authors would like to thank Lou Berger for the
guidance on this work and for providing review comments. Authors guidance on this work and for providing review comments. Authors
would also like to thank Nobo Akiya, Loa Andersson, Matt Hartley, would also like to thank Nobo Akiya, Loa Andersson, Matt Hartley,
Himanshu Shah, Gregory Mirsky and Mach Chen for reviewing this Himanshu Shah, Gregory Mirsky, Mach Chen, Vishnu Pavan Beeram and
document and providing valuable comments. A special thanks to Adrian Alia Atlas for reviewing this document and providing valuable
Farrel for his thorough review of this document. comments. A special thanks to Adrian Farrel for his thorough review
of this document.
Contributors Contributors
Frederic Jounay Frederic Jounay
Orange Orange
CH CH
EMail: frederic.jounay@salt.ch EMail: frederic.jounay@salt.ch
Lizhong Jin Lizhong Jin
 End of changes. 24 change blocks. 
88 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/