draft-ietf-teas-gmpls-lsp-fastreroute-06.txt   draft-ietf-teas-gmpls-lsp-fastreroute-07.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. Intended Status: Standards Track R. Gandhi, Ed.
Expires: April 4, 2017 Z. Ali Expires: June 22, 2017 Z. Ali
Cisco Systems Cisco Systems
October 1, 2016 M. Bhatia
Nokia
December 19, 2016
Extensions to Resource Reservation Protocol For Fast Reroute of Extensions to Resource Reservation Protocol For Fast Reroute of
Traffic Engineering GMPLS LSPs Traffic Engineering GMPLS LSPs
draft-ietf-teas-gmpls-lsp-fastreroute-06 draft-ietf-teas-gmpls-lsp-fastreroute-07
Abstract Abstract
This document defines Resource Reservation Protocol - Traffic This document defines Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) signaling extensions to support Fast Reroute Engineering (RSVP-TE) signaling extensions to support Fast Reroute
(FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol
Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling
extensions allow the coordination of a bidirectional bypass tunnel extensions 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 and extensions enable the re-direction of bidirectional traffic onto
signaling onto bypass tunnels that ensure co-routedness of data and bypass tunnels that ensure co-routedness of data paths in the forward
signaling paths in the forward and reverse directions after FRR to and reverse directions after FRR and avoid RSVP soft-state timeout in
avoid RSVP soft-state timeout. 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-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 14 skipping to change at page 2, line 19
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 5 2.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 6
3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 5 3. Fast Reroute For Unidirectional GMPLS LSPs . . . . . . . . . . 6
4. Fast Reroute for Bidirectional GMPLS LSPs . . . . . . . . . . 5 4. Bypass Tunnel Assignment For Bidirectional GMPLS LSPs . . . . 6
4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 5 4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 7
4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 6 4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . . 7
4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 6 4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 7
4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 6 4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 8
4.5. Bidirectional Bypass Tunnel Assignment Co-ordination . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . 7 Procedure . . . . . . . . . . . . . . . . . . . . . . 8
4.5.2. Multiple Bidirectional Bypass Tunnel Assignments . . . 8 4.5.2. One-to-one Bidirectional Bypass Tunnel Assignment . . 9
4.6. Fast Reroute Procedure After Link Failure . . . . . . . . 9 4.5.3. Multiple Bidirectional Bypass Tunnel Assignments . . . 10
5. Link Protection for Bidirectional GMPLS LSPs . . . . . . . . . 10 5. Fast Reroute For Bidirectional GMPLS LSPs with In-band
5.1. Behavior After Link Failure . . . . . . . . . . . . . . . 10 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Revertive Behavior After Fast Reroute . . . . . . . . . . 11 5.1. Link Protection for Bidirectional GMPLS LSPs . . . . . . . 11
6. Node Protection for Bidirectional GMPLS LSPs . . . . . . . . . 11 5.1.1. Behavior After Link Failure . . . . . . . . . . . . . 12
6.1. Behavior After Link Failure . . . . . . . . . . . . . . . 12 5.1.2. Revertive Behavior After Fast Reroute . . . . . . . . 12
6.2. Behavior After Link Failure To Re-coroute . . . . . . . . 12 5.2. Node Protection for Bidirectional GMPLS LSPs . . . . . . . 12
6.3. Revertive Behavior After Fast Reroute . . . . . . . . . . 13 5.2.1. Behavior After Link Failure . . . . . . . . . . . . . 13
7. Unidirectional Link Failures . . . . . . . . . . . . . . . . . 14 5.2.2. Behavior After Link Failure To Re-coroute . . . . . . 13
8. Message and Object Definitions . . . . . . . . . . . . . . . . 14 5.2.2.1. Re-coroute in Data-plane After Link Failure . . . 14
8.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 14 5.2.3. Revertive Behavior After Fast Reroute . . . . . . . . 15
8.2. FRR Bypass Assignment Error Notify Message . . . . . . . . 16 5.3. Unidirectional Link Failures . . . . . . . . . . . . . . . 15
9. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Message and Object Definitions . . . . . . . . . . . . . . . . 16
11.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 17 7.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 16
11.2. FRR Bypass Assignment Error Notify Message . . . . . . . 17 7.2. FRR Bypass Assignment Error Notify Message . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels can be Packet Switched Capable (PSC) Traffic Engineering (TE) tunnels can be
setup using Generalized Multi-Protocol Label Switching (GMPLS) setup using Generalized Multi-Protocol Label Switching (GMPLS)
signaling procedures specified in [RFC3473] for both unidirectional signaling procedures specified in [RFC3473] for both unidirectional
and bidirectional LSPs. Fast Reroute (FRR) [RFC4090] has been widely and bidirectional LSPs. The GMPLS signaling allows sending and
deployed in the packet TE networks today and is desirable for TE receiving the RSVP messages in-band with the data traffic or
GMPLS LSPs. Using FRR methods also allows the leveraging of the out-of-band over a separate control-channel. Fast Reroute (FRR)
existing mechanisms for failure detection and restoration in deployed [RFC4090] has been widely deployed in the packet TE networks today
networks. and is desirable for TE GMPLS LSPs. Using FRR methods also allows
the leveraging of the existing mechanisms for failure 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 extends 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 signaling onto the bypass tunnels. This can occur finish rerouting of the signaling messages. This can occur after a
after a failure event when using node protection bypass tunnels and failure event when using node protection bypass tunnels. As shown in
when RSVP signaling is sent in-band with data. As shown in Figure 2, Figure 2, this is possible even with selecting the same bidirectional
this is possible even with selecting the same bidirectional bypass bypass tunnels in both directions and the same PLR and MP pairs.
tunnels in both directions and the same PLR and MP pairs. This is This is caused by the asymmetry of paths that may be taken by the
caused by the asymmetry of paths that may be taken by the
bidirectional LSP's signaling in the forward and reverse directions bidirectional LSP's signaling in the forward and reverse directions
due to upstream and downstream PLRs independently triggering FRR. In due to upstream and downstream PLRs independently triggering FRR. In
such cases, after FRR, the RSVP soft-state timeout causes the such cases, after FRR, the RSVP soft-state timeout causes the
protected bidirectional LSP to be torn down, with subsequent traffic protected bidirectional LSP to be torn down, with subsequent traffic
loss. loss.
Protection State Coordination Protocol [RFC6378] is applicable to FRR Protection State Coordination Protocol [RFC6378] is applicable to FRR
[RFC4090] for local protection of co-routed bidirectional LSPs in [RFC4090] for local protection of co-routed bidirectional LSPs in
order to minimize traffic disruptions in both directions. However, order to minimize traffic disruptions in both directions. However,
this does not address the above mentioned problem of RSVP soft-state this does not address the above mentioned problem of RSVP soft-state
timeout in control plane. timeout that can occur in the control-plane.
This document proposes a solution to the RSVP soft-state timeout This document defines a solution to the RSVP soft-state timeout issue
issue by providing mechanisms in the control plane to complement the by providing mechanisms in the control-plane to complement the FRR
FRR procedures of [RFC4090]. The proposal allows to maintain the procedures of [RFC4090]. The solution allows to maintain the RSVP
RSVP soft-state for co-routed bidirectional protected GMPLS LSPs and soft-state for co-routed bidirectional protected GMPLS LSPs in the
achieve co-routedness of the paths followed by the traffic and control-plane and achieve co-routedness of the paths followed by the
signaling in the forward and reverse directions after FRR. traffic in the forward and reverse directions after FRR.
Procedures defined in this document apply to GMPLS signaled PSC TE The procedures defined in this document apply to GMPLS signaled PSC
co-routed bidirectional protected LSPs and FRR co-routed TE co-routed bidirectional protected LSPs and co-routed bidirectional
bidirectional bypass tunnels. Unless otherwise specified in this FRR bypass tunnels. Unless otherwise specified in this document, the
document, the FRR procedures defined in [RFC4090] are not modified by FRR procedures defined in [RFC4090] are not modified by this
this document. FRR mechanism for associated bidirectional GMPLS LSPs document. The FRR mechanism for associated bidirectional GMPLS LSPs
where two unidirectional GMPLS LSPs are bound together by using where two unidirectional GMPLS LSPs are bound together by using the
association signaling [RFC7551] is outside the scope of this association signaling [RFC7551] is outside the scope of this
document. document.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Key Word Definitions 2.1. Key Word Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 5, line 7 skipping to change at page 6, line 8
reroutes traffic in the opposite direction of the protected 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 upstream direction of the traffic flow. The same LSR may be both an upstream
MP and a downstream PLR simultaneously. 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 Path message over the of upstream PLR upon receiving protected LSP's rerouted Path message
bypass tunnel and triggers reroute of traffic and signaling in the and triggers reroute of traffic and signaling in the upstream
upstream direction of the traffic flow using the procedures described direction of the traffic flow using the procedures described in this
in this document. document.
2.3. Acronyms and Abbreviations 2.3. Acronyms and Abbreviations
GMPLS: Generalized Multi-Protocol Label Switching GMPLS: Generalized Multi-Protocol Label Switching
LSP: An MPLS Label Switched Path LSP: An MPLS Label Switched Path
LSR: An MPLS Label Switching Router LSR: An MPLS Label Switching Router
MP: Merge Point MP: Merge Point
skipping to change at page 5, line 34 skipping to change at page 6, line 35
PLR: Point of Local Repair PLR: Point of Local Repair
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] are applicable to The FRR procedures defined in [RFC4090] for RSVP-TE signaling
unidirectional protected LSPs signaled using either RSVP-TE or GMPLS [RFC3209] are equally applicable to the unidirectional protected LSPs
procedures and are not modified by the extensions defined in this signaled using GMPLS [RFC3473] and are not modified by the extensions
document. defined in this document except the following.
4. Fast Reroute for Bidirectional GMPLS LSPs When using the GMPLS out-of-band signaling [RFC3473], after a link
failure event, the RSVP messages are not rerouted over the bypass
tunnel by the downstream PLR but instead rerouted over a
control-channel to the downstream MP.
4. Bypass Tunnel Assignment For Bidirectional GMPLS LSPs
This section describes signaling procedures for FRR bidirectional This section describes signaling procedures for FRR bidirectional
bypass tunnel assignment for GMPLS signaled PSC co-routed bypass tunnel assignment for GMPLS signaled PSC co-routed
bidirectional TE LSPs. bidirectional TE LSPs for both in-band and out-of-band signaling.
4.1. Bidirectional GMPLS Bypass Tunnel Direction 4.1. Bidirectional GMPLS Bypass Tunnel Direction
This document defines procedures where bidirectional GMPLS bypass This document defines procedures where bidirectional GMPLS bypass
tunnels are signaled in the same direction as the protected GMPLS tunnels are signaled in the same direction as the protected GMPLS
LSPs. In other words, the bidirectional GMPLS bypass tunnels LSPs. In other words, the bidirectional GMPLS bypass tunnels
originate on the downstream PLR and terminate on the downstream MP. originate on the downstream PLRs and terminate on the corresponding
As the originating downstream PLR has the policy information about downstream MPs. As the originating downstream PLR has the policy
the locally provisioned bypass tunnels, it always initiates the information about the locally provisioned bypass tunnels, it always
bypass tunnel assignment. The bidirectional GMPLS bypass tunnels initiates the bypass tunnel assignment. The bidirectional GMPLS
originating from the upstream PLR and terminating on the upstream MP bypass tunnels originating from the upstream PLRs and terminating on
are outside the scope of this document. the corresponding upstream MPs are outside the scope of this
document.
4.2. Merge Point Labels 4.2. Merge Point Labels
To correctly reroute data traffic over a node protection bypass To correctly reroute data traffic over a node protection bypass
tunnel, the downstream and upstream PLRs have to know, in advance, tunnel, the downstream and upstream PLRs have to know, in advance,
the downstream and upstream MP labels of the protected LSP so that the downstream and upstream MP labels of the protected LSP so that
data in the forward and reverse directions can be redirected through data in the forward and reverse directions can be redirected through
the bypass tunnel after FRR respectively. the bypass tunnel after FRR respectively.
[RFC4090] defines procedures for the downstream PLR to obtain the [RFC4090] defines procedures for the downstream PLR to obtain the
skipping to change at page 6, line 49 skipping to change at page 8, line 8
To obtain the upstream MP address, the procedures specified in To obtain the upstream MP address, the procedures specified in
[RFC4561] are used to record upstream MP Node-ID in the RRO of the [RFC4561] are used to record upstream MP Node-ID in the RRO of the
RSVP Path message of the protected LSP. The upstream PLR obtains the RSVP Path message of the protected LSP. The upstream PLR obtains the
upstream MP address from the recorded Node-IDs in the RRO of the upstream MP address from the recorded Node-IDs in the RRO of the
received RSVP Path message. received RSVP Path message.
4.4. RRO IPv4/IPv6 Subobject Flags 4.4. RRO IPv4/IPv6 Subobject Flags
RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4 RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4
and are equally applicable to the FRR procedure for bidirectional and are equally applicable to the FRR procedure for the protected
GMPLS LSPs. bidirectional GMPLS LSPs.
The procedures defined in [RFC4090] are used by the downstream PLR to The procedures defined in [RFC4090] are used by the downstream PLR to
signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP
Resv message of the protected LSP. Similarly, those procedures are Resv message of the protected LSP. Similarly, those procedures are
used by the downstream PLR to signal the IPv4/IPv6 subobject flags used by the downstream PLR to signal the IPv4/IPv6 subobject flags
downstream in the RRO of the RSVP Path message of the protected LSP. downstream in the RRO of the RSVP Path message of the protected LSP.
4.5. Bidirectional Bypass Tunnel Assignment Co-ordination 4.5. Bidirectional Bypass Tunnel Assignment Co-ordination
This document defines signaling procedures and a new This document defines signaling procedures and a new
BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object (RRO) BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object (RRO)
used to co-ordinate the bidirectional bypass tunnel assignment used to co-ordinate the bidirectional bypass tunnel assignment
between the downstream and upstream PLRs. between the downstream and upstream PLRs.
4.5.1. Bidirectional Bypass Tunnel Assignment Signaling Procedure 4.5.1. Bidirectional Bypass Tunnel Assignment Signaling Procedure
It is desirable to coordinate the bidirectional bypass tunnel It is desirable to coordinate the bidirectional bypass tunnel
selected at the downstream and upstream PLRs so that rerouted traffic selected at the downstream and upstream PLRs so that the rerouted
and signaling flow on co-routed paths after FRR. To achieve this, a traffic flows on co-routed paths after FRR. To achieve this, a new
new RSVP subobject is defined for RRO that identifies a bidirectional RSVP subobject is defined for RRO that identifies a bidirectional
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
skipping to change at page 8, line 27 skipping to change at page 9, line 33
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 may 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.
The RRO containing BYPASS_ASSIGNMENT subobject(s) is then simply Upon receiving this error, the downstream PLR SHOULD remove the
forwarded downstream in the RSVP Path message. bypass tunnel assignment and select an alternate bypass tunnel if one
available. The RRO containing BYPASS_ASSIGNMENT subobject(s) is then
simply forwarded downstream in the RSVP Path message.
The bypass assignment co-ordination procedure described in this 4.5.2. One-to-one Bidirectional Bypass Tunnel Assignment
Section can be used for both facility backup 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, the DETOUR_OBJECT
can be used in one-to-one backup method to identify 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 message [RFC3473] with
Error-code - FRR Bypass Assignment Error (value: TBA1) and Sub-code -
One-to-one Bypass Already In-use (value: TBA4) to the downstream
PLR.
4.5.2. Multiple Bidirectional Bypass Tunnel Assignments The bidirectional bypass tunnel assignment co-ordination procedure
defined in this document can be used for both facility backup
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,
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
is already in-use at the upstream PLR, it SHOULD send a Notify
message [RFC3473] with Error-code - FRR Bypass Assignment Error
(value: TBA1) and Sub-code - One-to-one Bypass Already In-use (value:
TBA4) to the downstream PLR. Upon receiving this error, the
downstream PLR SHOULD remove the bypass tunnel assignment and select
an alternate bypass tunnel if one available.
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. The choice of a
reverse bypass tunnel is based on the local policy on the upstream reverse bypass tunnel is based on the local policy on the upstream
PLR. Examples of such a policy could be to prefer link protection PLR. Examples of such a policy could be to prefer link protection
over node protection, or to prefer the bypass tunnel to the furthest over node protection, or to prefer the bypass tunnel to the furthest
upstream node. 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
skipping to change at page 9, line 38 skipping to change at page 10, line 49
\ / \ /
\ / \ /
+-------<<--------+ +-------<<--------+
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 In both examples above, the upstream PLR SHOULD send a Notify message
[RFC3473] with Error-code - FRR Bypass Assignment Error (value: TBA1) [RFC3473] with Error-code - FRR Bypass Assignment Error (value: TBA1)
and Sub-code - Bypass Assignment Cannot Be Used (value: TBA2) to the and Sub-code - Bypass Assignment Cannot Be Used (value: TBA2) to the
downstream PLR to indicate that it cannot use the bypass tunnel downstream PLR to indicate that it cannot use the bypass tunnel
assignment. The upstream PLR can then remove the bypass assignment assignment in the reverse direction. Upon receiving this error, the
and select an alternate bypass tunnel. 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 6.2 using the re-coroute procedure after FRR as specified in Section
of this document. 5.2.2 of this document.
5. Fast Reroute For Bidirectional GMPLS LSPs with In-band Signaling
4.6. Fast Reroute Procedure After Link Failure
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: 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 traffic and RSVP Path signaling over
the bidirectional bypass tunnel using the procedures defined in the bidirectional bypass tunnel using the procedures defined in
[RFC4090]. [RFC4090].
o Upstream PLR reroutes traffic upon detecting the link failure or o Upstream PLR reroutes traffic upon detecting the link failure or
upon receiving RSVP Path message over the bidirectional bypass upon receiving RSVP Path message over the bidirectional bypass
tunnel. tunnel.
o Upstream PLR also reroutes RSVP Resv signaling after receiving o Upstream PLR also reroutes RSVP Resv signaling after receiving
RSVP Path message over the bidirectional bypass tunnel. RSVP Path message over the bidirectional bypass tunnel.
This 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. This is described in Section 5 for link bidirectional GMPLS LSP. The following sections describe the
protection bypass tunnels and Section 6 for node protection bypass handling for link protection and node protection bypass tunnels.
tunnels.
5. 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]
PATH -> \ / PATH -> \ /
\ / \ /
+<<----->>+ +<<----->>+
T3 T3
PATH -> PATH ->
<- RESV <- RESV
skipping to change at page 10, line 42 skipping to change at page 12, line 4
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. 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 tunnels T3 in the forward and reroute to redirect traffic onto bypass tunnels T3 in the forward and
reverse directions. The downstream PLR R3 also reroutes RSVP Path reverse directions. The downstream PLR R3 also reroutes RSVP Path
messages onto the bypass tunnel T3 using the procedures described in messages onto the bypass tunnel T3 using the procedures described in
[RFC4090]. The upstream PLR R4 reroutes RSVP Resv messages onto the [RFC4090]. The upstream PLR R4 reroutes RSVP Resv messages onto the
reverse bypass tunnel T3 upon receiving RSVP Path message over bypass reverse bypass tunnel T3 upon receiving RSVP Path message over bypass
tunnel T3. tunnel T3.
5.2. Revertive Behavior After Fast Reroute 5.1.2. Revertive Behavior After Fast Reroute
Revertive behavior as defined in [RFC4090], Section 6.5.2, is The revertive behavior defined in [RFC4090], Section 6.5.2, is
applicable to the link protection of bidirectional GMPLS LSPs. When applicable to the link protection of bidirectional GMPLS LSPs. When
using the local revertive mode, after the link R3-R4 is restored, using the local revertive mode, after the link R3-R4 (in Figure 1) is
following node behaviors apply: 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 Resv messages and traffic o The upstream PLR R4 starts sending the Resv 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 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, it starts sending Resv
messages and traffic flow of the protected LSP over the restored messages and traffic flow of the protected LSP over the restored
link and stops sending them over the bypass tunnel. link and stops sending them over the bypass tunnel.
6. Node Protection for Bidirectional GMPLS LSPs 5.2. Node Protection for Bidirectional GMPLS LSPs
T1 T1
+<<------->>+ +<<------->>+
/ \ / \
/ \ <- RESV / \ <- RESV
[R1]----[R2]----[R3]--x--[R4]----[R5]----[R6] [R1]----[R2]----[R3]--x--[R4]----[R5]----[R6]
PATH -> \ / PATH -> \ /
\ / \ /
+<<------->>+ +<<------->>+
T2 T2
skipping to change at page 12, line 11 skipping to change at page 13, line 17
R4's Bypass T1: {R4-R2} R4's Bypass T1: {R4-R2}
Figure 2: Flow of RSVP signaling after link failure and FRR Figure 2: Flow of RSVP signaling after link failure and FRR
Consider the TE network shown in Figure 2. Assume every link in the Consider the TE network shown in Figure 2. Assume every link in the
network is protected with a node protection bypass tunnel. For the network is protected with a node protection bypass tunnel. For the
protected co-routed bidirectional LSP whose head-end is on node R1 protected co-routed bidirectional LSP whose head-end is on node R1
and tail-end is on node R6, each traversed node (a potential PLR) and tail-end is on node R6, each traversed node (a potential PLR)
assigns a node protection co-routed bidirectional bypass tunnel. assigns a node protection co-routed bidirectional bypass tunnel.
The proposed solution introduces two phases to invoking FRR The solution introduces two phases to invoking FRR procedures by the
procedures by the PLR after the link failure. The first phase PLR after the link failure. The first phase comprises of FRR
comprises of FRR procedures to fast reroute data traffic onto bypass procedures to fast reroute data traffic onto bypass tunnels in the
tunnels in the forward and reverse directions. The second phase forward and reverse directions. The second phase re-coroutes the
re-coroutes the data and signaling in the forward and reverse data and signaling in the forward and reverse directions after the
directions after the first phase. first phase.
6.1. Behavior After Link Failure 5.2.1. Behavior After Link Failure
Consider a link R3-R4 on the protected LSP path fails. The Consider a link R3-R4 (in Figure 2) on the protected LSP path fails.
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 traffic onto respective bypass tunnels
T2 and T1 in the forward and reverse directions. The downstream PLR T2 and T1 in the forward and reverse directions. The downstream PLR
R3 also reroutes RSVP Path messages over the bypass tunnel T2 using R3 also reroutes RSVP Path messages over the bypass tunnel T2 using
the procedures described in [RFC4090]. Note, at this point, node R4 the procedures described in [RFC4090]. Note, at this point, node R4
stops receiving RSVP Path refreshes for the protected bidirectional stops receiving RSVP Path refreshes for the protected bidirectional
LSP while protected traffic continues to flow over bypass tunnels. LSP while protected traffic continues to flow over bypass tunnels.
As node R4 does not receive Path messages over the bypass tunnel, it As node R4 does not receive Path messages, it does not reroute RSVP
does not reroute RSVP Resv messages over the reverse bypass tunnel. Resv messages over the reverse bypass tunnel.
6.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:
o Finds the bypass tunnel in the reverse direction that terminates o Finds the bypass tunnel in the reverse direction that terminates
on the downstream PLR R3. Note: the downstream PLR R3's address on the downstream PLR R3. Note: the downstream PLR R3's address
skipping to change at page 13, line 5 skipping to change at page 14, line 10
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.
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}
skipping to change at page 13, line 35 skipping to change at page 14, line 40
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
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 is pre-configured in data-plane as follows. If the downstream MP has assigned a
with bidirectional bypass tunnel, as soon as the downstream MP bidirectional bypass tunnel, as soon as the downstream MP receives
receives the protected LSP packets on this bypass tunnel, it MAY the protected LSP packets on the bypass tunnel, it MAY switch the
switch the upstream traffic on to this bypass tunnel. In order to upstream traffic on to the bypass tunnel. In order to identify the
identify the protected LSP packets through this bypass tunnel, protected LSP packets through the bypass tunnel, Penultimate Hop
Penultimate Hop Popping (PHP) of the bypass tunnel MUST be disabled. Popping (PHP) of the bypass tunnel MUST be disabled. The downstream
The signaling procedure described above in this Section will still MP checks whether the protected LSP signaling is rerouted over the
apply, and downstream MP checks whether the protected LSP traffic and found bypass tunnel, and if not, it performs the signaling procedure
signaling is already rerouted over the found bypass tunnel, if not, described in Section 5.2.2 of this document.
perform the above signaling procedure.
6.3. Revertive Behavior After Fast Reroute 5.2.3. Revertive Behavior After Fast Reroute
Revertive behavior as 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 is restored, using the local revertive mode, after the link R3-R4 (in Figures 2
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 Resv messages and traffic o The upstream PLR R4 starts sending the Resv messages and traffic
flow of the protected LSP over the restored link towards flow of the protected LSP over the restored link towards
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.
skipping to change at page 14, line 27 skipping to change at page 15, line 33
the restored link, if not already done, it starts sending Resv the restored link, if not already done, it starts sending Resv
messages and traffic flow over the restored link towards messages and traffic flow over the restored link towards
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.
7. Unidirectional Link Failures 5.3. Unidirectional Link Failures
Unidirectional link failures may result in the traffic flowing on Unidirectional link failures may 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 may 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 Figure 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
PLR (node R4 in Figure 1 and node R5 in Figure 2) triggers the PLR (node R4 in Figure 1 and node R5 in Figure 2) triggers the
re-coroute procedure (defined in Section 6.2 of this document) after re-coroute procedure (defined in Section 5.2.2 of this document)
receiving RSVP Path messages of the protected LSP over the bypass after receiving RSVP Path messages of the protected LSP over the
tunnel from the downstream PLR (node R3 in Figures 1 and 2). bypass tunnel from the downstream PLR (node R3 in Figures 1 and 2).
8. Message and Object Definitions 6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band Signaling
When using the GMPLS out-of-band signaling [RFC3473], after a link
failure event, the RSVP messages are not rerouted over the
bidirectional bypass tunnel by the downstream and upstream PLRs but
instead rerouted over the control-channels to the downstream and
upstream MPs, respectively.
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
signaling as the RSVP signaling refreshes may stop reaching certain
nodes along the protected LSP path after the downstream and upstream
PLRs finish rerouting of the signaling messages. However, unlike
with the in-band signaling, unidirectional link failures as described
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
described in Section 5 of this document is equally applicable to the
GMPLS out-of-band signaling.
7. Message and Object Definitions
7.1. BYPASS_ASSIGNMENT Subobject
8.1. BYPASS_ASSIGNMENT Subobject
The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP The BYPASS_ASSIGNMENT subobject is used to inform the downstream MP
of the bypass tunnel being assigned by the PLR. This can be used to of the bypass tunnel being assigned by the PLR. This can be used to
coordinate the bypass tunnel assignment for the protected LSP by the coordinate the bypass tunnel assignment for the protected LSP by the
downstream and upstream PLRs in the forward and reverse directions downstream and upstream PLRs in the forward and reverse directions
respectively prior or after the failure occurrence. respectively prior or after the failure occurrence.
This subobject SHOULD be inserted into the Path RRO by the downstream This subobject SHOULD be inserted into the Path RRO by the downstream
PLR. It SHOULD NOT be inserted into an RRO by a node which is not a PLR. It SHOULD NOT be inserted into an RRO by a node which is not a
downstream PLR. It MUST NOT be changed by downstream LSRs and MUST downstream PLR. It MUST NOT be changed by downstream LSRs and MUST
NOT be added to a Resv RRO. NOT be added to a Resv RRO.
skipping to change at page 16, line 16 skipping to change at page 17, line 39
with IPv4 address and 20 bytes with IPv6 object. with IPv4 address and 20 bytes with IPv6 object.
Bypass Tunnel ID Bypass Tunnel ID
The bypass tunnel identifier (16 bits). The bypass tunnel identifier (16 bits).
Bypass Destination Address Bypass Destination Address
The bypass tunnel IPv4 or IPv6 destination address. The bypass tunnel IPv4 or IPv6 destination address.
8.2. FRR Bypass Assignment Error Notify Message 7.2. FRR Bypass Assignment Error Notify Message
New Error-code - FRR Bypass Assignment Error (value: TBA1) and its New Error-code - FRR Bypass Assignment Error (value: TBA1) and its
sub-codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205] sub-codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205]
in this document, that is carried by the Notify message (Type 21) in this document, that is carried by the Notify message (Type 21)
defined in [RFC3473] Section 4.3. This Error is sent by the upstream defined in [RFC3473] Section 4.3. This Error is sent by the upstream
PLR to the downstream PLR to notify a bypass assignment error. In PLR to the downstream PLR to notify a bypass assignment error. In
the Notify message, the IP destination address is set to the node the Notify message, the IP destination address is set to the node
address of the downstream PLR that had initiated the bypass address of the downstream PLR that had initiated the bypass
assignment. In the ERROR_SPEC Object, IP address is set to the node assignment. In the ERROR_SPEC Object, IP address is set to the node
address of the upstream PLR that detected the bypass assignment address of the upstream PLR that detected the bypass assignment
error. This Error MUST NOT be sent in a Path Error message. This error. This Error MUST NOT be sent in a Path Error message. This
Error does not cause protected LSP to be torn down. Error does not cause the protected LSP to be torn down.
9. Compatibility 8. Compatibility
New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE
Object in this document that is carried in the RSVP Path message. Object in this document that is carried in the RSVP Path message.
Per [RFC3209], nodes not supporting this subobject will ignore the Per [RFC3209], nodes not supporting this subobject will ignore the
subobject but forward it without modification. As described in subobject but forward it without modification. As described in
Section 8, this subobject is not carried in the RSVP Resv message. A Section 7 of this document, this subobject is not carried in the RSVP
new Notify message for FRR Bypass Assignment Error is defined in this Resv message. A new Notify message for FRR Bypass Assignment Error
document. Nodes not supporting this message will ignore it but is defined in this document. Nodes not supporting this message will
forward it without modification. ignore it but forward it without modification.
10. Security Considerations 9. Security Considerations
This document introduces a new BYPASS_ASSIGNMENT subobject for the This document introduces a new BYPASS_ASSIGNMENT subobject for the
RECORD_ROUTE Object that is carried in an RSVP signaling message. RECORD_ROUTE Object that is carried in an RSVP signaling message.
Thus in the event of the interception of a signaling message, more Thus in the event of the interception of a signaling message, more
information about LSP's fast reroute protection can be deduced than information about LSP's fast reroute protection can be deduced than
was previously the case. This is judged to be a very minor security was previously the case. This is judged to be a very minor security
risk as this information is already available by other means. risk as this information is already available by other means. The
Notify message for FRR Bypass Assignment Error defined in this
document does not result in tear-down of the protected LSP and is not
service affecting.
Otherwise, this document introduces no additional security Otherwise, this document introduces no additional security
considerations. For general discussion on MPLS and GMPLS related considerations. For general discussion on MPLS and GMPLS related
security issues, see the MPLS/GMPLS security framework [RFC5920]. security issues, see the MPLS/GMPLS security framework [RFC5920].
11. IANA Considerations 10. IANA Considerations
11.1. BYPASS_ASSIGNMENT Subobject 10.1. BYPASS_ASSIGNMENT Subobject
IANA manages the "RSVP PARAMETERS" registry located at IANA manages the "RSVP PARAMETERS" registry located at
<http://www.iana.org/assignments/rsvp-parameters>. IANA is requested <http://www.iana.org/assignments/rsvp-parameters>. IANA is requested
to assign a value for the new BYPASS_ASSIGNMENT subobject in the to assign a value for the new BYPASS_ASSIGNMENT subobject in the
"Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry. "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry.
This document introduces a new subobject for RECORD_ROUTE Object: This document introduces a new subobject for RECORD_ROUTE Object:
+--------+-------------------+---------+---------+---------------+ +--------+-------------------+---------+---------+---------------+
| Type | Description | Carried | Carried | Reference | | Type | Description | Carried | Carried | Reference |
| | | in Path | in Resv | | | | | in Path | in Resv | |
+--------+-------------------+---------+---------+---------------+ +--------+-------------------+---------+---------+---------------+
| TBA By | BYPASS_ASSIGNMENT | Yes | No | This document | | TBA By | BYPASS_ASSIGNMENT | Yes | No | This document |
| IANA | IPv4 subobject | | | | | IANA | IPv4 subobject | | | |
+--------+-------------------+---------+---------+---------------+ +--------+-------------------+---------+---------+---------------+
| TBA By | BYPASS_ASSIGNMENT | Yes | No | This document | | TBA By | BYPASS_ASSIGNMENT | Yes | No | This document |
| IANA | IPv6 subobject | | | | | IANA | IPv6 subobject | | | |
+--------+-------------------+---------+---------+---------------+ +--------+-------------------+---------+---------+---------------+
11.2. FRR Bypass Assignment Error Notify Message 10.2. FRR Bypass Assignment Error Notify Message
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" IANA maintains the "Resource Reservation Protocol (RSVP) Parameters"
registry (see <http://www.iana.org/assignments/rsvp-parameters>). registry (see <http://www.iana.org/assignments/rsvp-parameters>).
The "Error Codes and Globally-Defined Error Value Sub-Codes" The "Error Codes and Globally-Defined Error Value Sub-Codes"
subregistry is included in this registry. subregistry is included in this registry.
This registry has been extended for the new Error-code and Sub-codes This registry has been extended for the new Error-code and Sub-codes
defined in this document as follows: defined in this document as follows:
o Error-code TBA1: FRR Bypass Assignment Error o Error-code TBA1: FRR Bypass Assignment Error
o Sub-code TBA2: Bypass Assignment Cannot Be Used o Sub-code TBA2: Bypass Assignment Cannot Be Used
o Sub-code TBA3: Bypass Tunnel Not Found o Sub-code TBA3: Bypass Tunnel Not Found
o Sub-code TBA4: One-to-one Bypass Already In-use o Sub-code TBA4: One-to-one Bypass Already In-use
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
skipping to change at page 18, line 33 skipping to change at page 20, line 33
January 2003. January 2003.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
[RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition [RFC4561] Vasseur, J.P., Ed., Ali, Z., and S. Sivabalan, "Definition
of a Record Route Object (RRO) Node-Id Sub-Object", RFC of a Record Route Object (RRO) Node-Id Sub-Object", RFC
4561, June 2006. 4561, June 2006.
12.2. Informative References 11.2. Informative References
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003. 3471, January 2003.
[RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of
Addresses in Generalized Multiprotocol Label Switching Addresses in Generalized Multiprotocol Label Switching
(GMPLS) Networks", RFC 4990, September 2007. (GMPLS) Networks", RFC 4990, September 2007.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
skipping to change at page 19, line 7 skipping to change at page 21, line 7
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
Protection", RFC 6378, October 2011. Protection", RFC 6378, October 2011.
[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 his detailed and Authors would like to thank George Swallow for many useful comments
useful comments and suggestions. Authors would also like to thank and suggestions. Authors would like to thank Lou Berger for the
Nobo Akiya, Loa Andersson, Matt Hartley and Gregory Mirsky for guidance on this work. Authors would also like to thank Nobo Akiya,
reviewing this document. A special thanks to Adrian Farrel for his Loa Andersson, Matt Hartley, Himanshu Shah and Gregory Mirsky for
thorough review of this document. reviewing this document and providing valuable comments. A special
thanks to Adrian 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
Manav Bhatia
Nokia
Banglore, India
EMail: manav.bhatia@nokia.com
Lizhong Jin Lizhong Jin
Shanghai, China Shanghai, China
EMail: lizho.jin@gmail.com EMail: lizho.jin@gmail.com
Authors' Addresses Authors' Addresses
Mike Taillon Mike Taillon
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at line 886 skipping to change at page 22, line 26
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: rgandhi@cisco.com EMail: rgandhi@cisco.com
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: zali@cisco.com EMail: zali@cisco.com
Manav Bhatia
Nokia
Banglore, India
EMail: manav.bhatia@nokia.com
 End of changes. 65 change blocks. 
180 lines changed or deleted 221 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/