draft-ietf-teas-gmpls-lsp-fastreroute-09.txt   draft-ietf-teas-gmpls-lsp-fastreroute-10.txt 
TEAS Working Group M. Taillon TEAS Working Group M. Taillon
Internet-Draft T. Saad, Ed. Internet-Draft T. Saad, Ed.
Intended Status: Standards Track R. Gandhi, Ed. Updates: 4090 R. Gandhi, Ed.
Expires: November 16, 2017 Z. Ali Intended Status: Standards Track Z. Ali
Cisco Systems, Inc. Expires: January 19, 2018 Cisco Systems, Inc.
M. Bhatia M. Bhatia
Nokia Nokia
May 15, 2017 July 18, 2017
Extensions 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-09 draft-ietf-teas-gmpls-lsp-fastreroute-10
Abstract Abstract
This document defines Resource Reservation Protocol - Traffic This document updates the Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) signaling extensions to support Fast Reroute Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC
(FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol 4090 to support Packet Switched Capable (PSC) Generalized Multi-
Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These
extensions 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
extensions enable the re-direction of bidirectional traffic onto updates enable the re-direction of bidirectional traffic onto bypass
bypass tunnels that ensure co-routedness of data paths in the forward tunnels that ensure co-routedness of data paths in the forward and
and reverse directions after FRR and avoid RSVP soft-state timeout in reverse directions after FRR and avoid RSVP soft-state timeout in
control-plane. control-plane.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
skipping to change at page 2, line 23 skipping to change at page 2, line 23
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 5 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Acronyms and 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 . . 9
skipping to change at page 4, line 7 skipping to change at page 4, line 7
10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 19 10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels can be Packet Switched Capable (PSC) Traffic Engineering (TE) Label Switched
setup using Generalized Multi-Protocol Label Switching (GMPLS) Paths (LSPs) can be setup using Generalized Multi-Protocol Label
signaling procedures specified in [RFC3473] for both unidirectional Switching (GMPLS) signaling procedures specified in [RFC3473] for
and bidirectional LSPs. The GMPLS signaling allows sending and both unidirectional and bidirectional tunnels. The GMPLS signaling
receiving the RSVP messages in-band with the data traffic or allows sending and receiving the RSVP messages in-band with the data
out-of-band over a separate control-channel. Fast Reroute (FRR) traffic or out-of-band over a separate control-channel. Fast Reroute
[RFC4090] has been widely deployed in the packet TE networks today (FRR) [RFC4090] has been widely deployed in the packet TE networks
and is desirable for TE GMPLS LSPs. Using FRR methods also allows today and is desirable for TE GMPLS LSPs. Using FRR methods also
the leveraging of the existing mechanisms for failure detection and allows the leveraging of the existing mechanisms for failure
restoration in deployed networks. detection and restoration in deployed networks.
The FRR procedures defined in [RFC4090] describe the behavior of the The FRR procedures defined in [RFC4090] describe the behavior of the
Point of Local Repair (PLR) to reroute traffic and signaling onto the Point of Local Repair (PLR) to reroute traffic and signaling onto the
bypass tunnel in the event of a failure for protected LSPs. Those bypass tunnel in the event of a failure for protected LSPs. Those
procedures are applicable to the unidirectional protected LSPs procedures are applicable to the unidirectional protected LSPs
signaled using either RSVP-TE [RFC3209] or GMPLS procedures signaled using either RSVP-TE [RFC3209] or GMPLS procedures
[RFC3473]. When using the FRR procedures defined in [RFC4090] with [RFC3473]. When using the FRR procedures defined in [RFC4090] with
co-routed bidirectional GMPLS LSPs, it is desired that same PLR and co-routed bidirectional GMPLS LSPs, it is desired that same PLR and
Merge Point (MP) pairs are selected in each direction and both PLR Merge Point (MP) pairs are selected in each direction and both PLR
and MP assign the same bidirectional bypass tunnel. This document and MP assign the same bidirectional bypass tunnel. This document
extends the FRR procedures defined in [RFC4090] to coordinate the updates the FRR procedures defined in [RFC4090] to coordinate the
bidirectional bypass tunnel assignment and to exchange MP labels bidirectional bypass tunnel assignment and to exchange MP labels
between upstream and downstream PLRs of the protected co-routed between upstream and downstream PLRs of the protected co-routed
bidirectional LSP. bidirectional LSP.
When using FRR procedures with co-routed bidirectional GMPLS LSPs, it When using FRR procedures with co-routed bidirectional GMPLS LSPs, it
is possible in some cases for the RSVP signaling refreshes to stop is possible in some cases for the RSVP signaling refreshes to stop
reaching certain nodes along the protected LSP path after the PLRs reaching certain nodes along the protected LSP path after the PLRs
finish rerouting of the signaling messages. This can occur after a finish rerouting of the signaling messages. This can occur after a
failure event when using node protection bypass tunnels. As shown in failure event when using node protection bypass tunnels. As shown in
Figure 2, this is possible even with selecting the same bidirectional Figure 2, this is possible even with selecting the same bidirectional
skipping to change at page 5, line 40 skipping to change at page 5, line 40
[RFC2205], [RFC3209], [RFC3471], [RFC3473], and [RFC4090]. [RFC2205], [RFC3209], [RFC3471], [RFC3473], and [RFC4090].
Downstream PLR: Downstream Point of Local Repair. The PLR that Downstream PLR: Downstream Point of Local Repair. The PLR that
locally detects a failure in the downstream direction of the locally detects a failure in the downstream direction of the
traffic flow and reroutes traffic in the same direction of the traffic flow and reroutes traffic in the same direction of the
protected bidirectional LSP RSVP Path signaling. A downstream PLR protected bidirectional LSP RSVP Path signaling. A downstream PLR
has a corresponding downstream MP. has a corresponding downstream MP.
Downstream MP: Downstream Merge Point. The LSR where one or more Downstream MP: Downstream Merge Point. The LSR where one or more
backup tunnels rejoin the path of the protected LSP in the backup tunnels rejoin the path of the protected LSP in the
downstream direction of the traffic flow. The same LSR may be downstream direction of the traffic flow. The same LSR can be
both a downstream MP and an upstream PLR simultaneously. both a downstream MP and an upstream PLR simultaneously.
Upstream PLR: Upstream Point of Local Repair. The PLR that locally Upstream PLR: Upstream Point of Local Repair. The PLR that locally
detects a failure in the upstream direction of the traffic flow detects a failure in the upstream direction of the traffic flow
and reroutes traffic in the opposite direction of the protected and reroutes traffic in the opposite direction of the protected
bidirectional LSP RSVP Path signaling. An upstream PLR has a bidirectional LSP RSVP Path signaling. An upstream PLR has a
corresponding upstream MP. corresponding upstream MP.
Upstream MP: Upstream Merge Point. The LSR where one or more backup Upstream MP: Upstream Merge Point. The LSR where one or more backup
tunnels rejoin the path of the protected LSP in the upstream tunnels rejoin the path of the protected LSP in the upstream
direction of the traffic flow. The same LSR may be both an direction of the traffic flow. The same LSR can be both an
upstream MP and a downstream PLR simultaneously. upstream MP and a downstream PLR simultaneously.
Point of Remote Repair (PRR): A downstream MP that assumes the role Point of Remote Repair (PRR): A downstream MP that assumes the role
of upstream PLR upon receiving protected LSP's rerouted Path of upstream PLR upon receiving protected LSP's rerouted Path
message and triggers reroute of traffic and signaling in the message and triggers reroute of traffic and signaling in the
upstream direction of the traffic flow using the procedures upstream direction of the traffic flow using the procedures
described in this document. described in this document.
2.3. Acronyms and Abbreviations 2.3. Abbreviations
GMPLS: Generalized Multi-Protocol Label Switching GMPLS: Generalized Multi-Protocol Label Switching
LSP: Label Switched Path LSP: Label Switched Path
LSR: Label Switching Router LSR: Label Switching Router
MP: Merge Point MP: Merge Point
MPLS: Multi-Protocol Label Switching MPLS: Multi-Protocol Label Switching
skipping to change at page 6, line 37 skipping to change at page 6, line 37
PSC: Packet Switched Capable PSC: Packet Switched Capable
RSVP: Resource ReSerVation Protocol RSVP: Resource ReSerVation Protocol
TE: Traffic Engineering TE: Traffic Engineering
3. Fast Reroute For Unidirectional GMPLS LSPs 3. Fast Reroute For Unidirectional GMPLS LSPs
The FRR procedures defined in [RFC4090] for RSVP-TE signaling The FRR procedures defined in [RFC4090] for RSVP-TE signaling
[RFC3209] are equally applicable to the unidirectional protected LSPs [RFC3209] are equally applicable to the unidirectional protected LSPs
signaled using GMPLS [RFC3473] and are not modified by the extensions signaled using GMPLS [RFC3473] and are not modified by the updates
defined in this document except the following. defined in this document except the following.
When using the GMPLS out-of-band signaling [RFC3473], after a link When using the GMPLS out-of-band signaling [RFC3473], after a link
failure event, the RSVP messages are not rerouted over the bypass failure event, the RSVP messages are not rerouted over the bypass
tunnel by the downstream PLR but instead rerouted over a tunnel by the downstream PLR but instead rerouted over a
control-channel to the downstream MP. control-channel to the downstream MP.
4. Bypass Tunnel Assignment For Bidirectional GMPLS LSPs 4. Bypass Tunnel Assignment For Bidirectional GMPLS LSPs
This section describes signaling procedures for FRR bidirectional This section describes signaling procedures for FRR bidirectional
skipping to change at page 9, line 6 skipping to change at page 9, line 6
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 RRO means that the relevant node or
interface is not protected by a bidirectional bypass tunnel. Hence, interface is not protected by a bidirectional bypass tunnel. Hence,
the upstream PLR need not assign a bypass tunnel in the reverse the upstream PLR need not assign a bypass tunnel in the reverse
direction. direction.
When the BYPASS_ASSIGNMENT subobject is added in the RRO: When the BYPASS_ASSIGNMENT subobject is added in the 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 in order to assign a reverse bypass
tunnel. The upstream PLR that detects a BYPASS_ASSIGNMENT subobject, tunnel. The upstream PLR that detects a BYPASS_ASSIGNMENT subobject,
selects a reverse bypass tunnel that terminates locally with the selects a reverse bypass tunnel that terminates locally with the
destination address and tunnel-ID from the subobject, and has a destination address and tunnel-ID from the subobject, and has a
source address matching the Node-ID address. The RRO may contain source address matching the Node-ID address. The RRO can contain
multiple addresses to identify a node, however, the upstream PLR multiple addresses to identify a node, however, the upstream PLR
relies on the Node-ID address preceding the BYPASS_ASSIGNMENT relies on the Node-ID address preceding the BYPASS_ASSIGNMENT
subobject for identifying the bypass tunnel. If the bypass tunnel is subobject for identifying the bypass tunnel. If the bypass tunnel is
not found, the upstream PLR SHOULD send a Notify message [RFC3473] not found, the upstream PLR SHOULD send a Notify message [RFC3473]
with Error-code - FRR Bypass Assignment Error (value: TBA1) and Sub- with Error-code - FRR Bypass Assignment Error (value: TBA1) and Sub-
code - Bypass Tunnel Not Found (value: TBA3) to the downstream PLR. code - Bypass Tunnel Not Found (value: TBA3) to the downstream PLR.
Upon receiving this error, the downstream PLR SHOULD remove the Upon receiving this error, the downstream PLR SHOULD remove the
bypass tunnel assignment and select an alternate bypass tunnel if one bypass tunnel assignment and select an alternate bypass tunnel if one
available. The RRO containing BYPASS_ASSIGNMENT subobject(s) is then available. The RRO containing BYPASS_ASSIGNMENT subobject(s) is then
simply forwarded downstream in the RSVP Path message. simply forwarded downstream in the RSVP Path message.
skipping to change at page 11, line 50 skipping to change at page 11, line 50
T3 T3
PATH -> PATH ->
<- RESV <- RESV
Protected LSP: {R1-R2-R3-R4-R5-R6} Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T3: {R3-R4} R3's Bypass T3: {R3-R4}
Figure 1: Flow of RSVP signaling after link failure and FRR Figure 1: Flow of RSVP signaling after link failure and FRR
Consider the TE network shown in Figure 1. Assume every link in the Consider the TE network shown in Figure 1. Assume every link in the
network is protected with a link protection bypass tunnel (e.g. network is protected with a link protection bypass tunnel (e.g.,
bypass tunnel T3). For the protected co-routed bidirectional LSP bypass tunnel T3). For the protected co-routed bidirectional LSP
whose head-end is on node R1 and tail-end is on node R6, each whose head-end is on node R1 and tail-end is on node R6, each
traversed node (a potential PLR) assigns a link protection co-routed traversed node (a potential PLR) assigns a link protection co-routed
bidirectional bypass tunnel. bidirectional bypass tunnel.
5.1.1. Behavior After Link Failure 5.1.1. Behavior After Link Failure
Consider the link R3-R4 on the protected LSP path fails. The Consider the link R3-R4 on the protected LSP path fails. The
downstream PLR R3 and upstream PLR R4 independently trigger fast downstream PLR R3 and upstream PLR R4 independently trigger fast
reroute to redirect traffic onto bypass tunnel T3 in the forward and reroute to redirect traffic onto bypass tunnel T3 in the forward and
skipping to change at page 14, line 34 skipping to change at page 14, line 34
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
reverse paths described above. Node R4 will stop receiving the Path reverse paths described above. Node R4 will stop receiving the Path
and Resv messages and it will timeout the RSVP soft-state, however, and Resv messages and it will timeout the RSVP soft-state, however,
this will not cause the LSP to be torn down. RSVP signaling at node this will not cause the LSP to be torn down. RSVP signaling at node
R2 is not affected by the FRR and re-corouting. R2 is not affected by the FRR and re-corouting.
If downstream MP R5 receives multiple RSVP Path messages through If downstream MP R5 receives multiple RSVP Path messages through
multiple bypass tunnels (e.g. as a result of multiple failures), the multiple bypass tunnels (e.g., as a result of multiple failures), the
PRR SHOULD identify a bypass tunnel that terminates on the farthest PRR SHOULD identify a bypass tunnel that terminates on the farthest
downstream PLR along the protected LSP path (closest to the protected downstream PLR along the protected LSP path (closest to the protected
bidirectional LSP head-end) and activate the reroute procedures bidirectional LSP head-end) and activate the reroute procedures
mentioned above. mentioned above.
5.2.2.1. Re-coroute in Data-plane After Link Failure 5.2.2.1. Re-coroute in Data-plane After Link Failure
The downstream MP (upstream PLR) MAY optionally support re-corouting The downstream MP (upstream PLR) MAY optionally support re-corouting
in data-plane as follows. If the downstream MP has assigned a in data-plane as follows. If the downstream MP has assigned a
bidirectional bypass tunnel, as soon as the downstream MP receives bidirectional bypass tunnel, as soon as the downstream MP receives
skipping to change at page 15, line 35 skipping to change at page 15, line 35
downstream PLR R3 and forwarding the Path messages towards PRR R5 downstream PLR R3 and forwarding the Path messages towards PRR R5
and stops sending them over the bypass tunnel. 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.3. Unidirectional Link Failures 5.3. Unidirectional Link Failures
Unidirectional link failures may 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 may 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
on the downstream PLR (node R3). on the downstream PLR (node R3).
A unidirectional link failure in the downstream direction (from R3 to A unidirectional link failure in the downstream direction (from R3 to
R4 in Figures 1 and 2), does not cause RSVP soft-state timeout when R4 in Figures 1 and 2), does not cause RSVP soft-state timeout when
using the FRR procedures defined in this document, since the upstream using the FRR procedures defined in this document, since the upstream
skipping to change at page 16, line 15 skipping to change at page 16, line 15
6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band Signaling 6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band Signaling
When using the GMPLS out-of-band signaling [RFC3473], after a link When using the GMPLS out-of-band signaling [RFC3473], after a link
failure event, the RSVP messages are not rerouted over the failure event, the RSVP messages are not rerouted over the
bidirectional bypass tunnel by the downstream and upstream PLRs but bidirectional bypass tunnel by the downstream and upstream PLRs but
instead rerouted over the control-channels to the downstream and instead rerouted over the control-channels to the downstream and
upstream MPs, respectively. upstream MPs, respectively.
The RSVP soft-state timeout after FRR as described in Section 5.2 of The RSVP soft-state timeout after FRR as described in Section 5.2 of
this document is equally applicable to the GMPLS out-of-band this document is equally applicable to the GMPLS out-of-band
signaling as the RSVP signaling refreshes may stop reaching certain signaling as the RSVP signaling refreshes can stop reaching certain
nodes along the protected LSP path after the downstream and upstream nodes along the protected LSP path after the downstream and upstream
PLRs finish rerouting of the signaling messages. However, unlike PLRs finish rerouting of the signaling messages. However, unlike
with the in-band signaling, unidirectional link failures as described with the in-band signaling, unidirectional link failures as described
in Section 5.3 of this document do not result in soft-state timeout in Section 5.3 of this document do not result in soft-state timeout
with GMPLS out-of-band signaling. Apart from this, the FRR procedure with GMPLS out-of-band signaling. Apart from this, the FRR procedure
described in Section 5 of this document is equally applicable to the described in Section 5 of this document is equally applicable to the
GMPLS out-of-band signaling. GMPLS out-of-band signaling.
7. Message and Object Definitions 7. Message and Object Definitions
skipping to change at page 21, line 18 skipping to change at page 21, line 18
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 and Mach Chen for reviewing this
document and providing valuable comments. A special thanks to Adrian document and providing valuable comments. A special thanks to Adrian
Farrel for his thorough review of this document. Farrel for his thorough review of this document.
Contributors Contributors
Frederic Jounay Frederic Jounay
Orange CH Orange
CH
EMail: frederic.jounay@salt.ch EMail: frederic.jounay@salt.ch
Lizhong Jin Lizhong Jin
Shanghai, China Shanghai
CN
EMail: lizho.jin@gmail.com EMail: lizho.jin@gmail.com
Authors' Addresses Authors' Addresses
Mike Taillon Mike Taillon
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: mtaillon@cisco.com EMail: mtaillon@cisco.com
 End of changes. 22 change blocks. 
40 lines changed or deleted 41 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/