draft-ietf-teas-assoc-corouted-bidir-frr-01.txt   draft-ietf-teas-assoc-corouted-bidir-frr-02.txt 
TEAS Working Group R. Gandhi, Ed. TEAS Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track H. Shah Intended Status: Standards Track H. Shah
Expires: November 25, 2017 Ciena Expires: May 16, 2018 Ciena
J. Whittaker J. Whittaker
Verizon Verizon
May 24, 2017 November 12, 2017
Fast Reroute Procedures for Fast Reroute Procedures for
Associated Bidirectional Label Switched Paths (LSPs) Co-routed Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-teas-assoc-corouted-bidir-frr-01 draft-ietf-teas-assoc-corouted-bidir-frr-02
Abstract Abstract
Resource Reservation Protocol (RSVP) association signaling can be Resource Reservation Protocol (RSVP) association signaling can be
used to bind two unidirectional LSPs into an associated bidirectional used to bind two unidirectional LSPs into an associated bidirectional
LSP. When an associated bidirectional LSP is co-routed, the reverse LSP. When an associated bidirectional LSP is co-routed, the reverse
LSP follows the same path as its forward LSP. This document LSP follows the same path as its forward LSP. This document
describes Fast Reroute (FRR) procedures for both single-sided and describes Fast Reroute (FRR) procedures for both single-sided and
double-sided provisioned associated bidirectional LSPs. The FRR double-sided provisioned associated bidirectional LSPs. The FRR
procedures can ensure that for the co-routed LSPs, traffic flows on procedures can ensure that for the co-routed LSPs, traffic flows on
skipping to change at page 2, line 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Assumptions and Considerations . . . . . . . . . . . . . . 3 1.1. Assumptions and Considerations . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Forward Unidirectional LSPs . . . . . . . . . . . . . 4 2.2.1. Forward Unidirectional LSPs . . . . . . . . . . . . . 4
2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4 2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 5 3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 5
3.2. Node Protection Bypass Tunnels . . . . . . . . . . . . . . 6 3.2. Node Protection Bypass Tunnels . . . . . . . . . . . . . . 6
3.3. Bidirectional LSP Association At Mid-Points . . . . . . . 7 3.3. Bidirectional LSP Association At Mid-Points . . . . . . . 7
4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 8 4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 8
4.1. Bidirectional LSP Fast Reroute . . . . . . . . . . . . . . 8 4.1. Associated Bidirectional LSP Fast Reroute . . . . . . . . 8
4.1.1. Re-corouting with Node Protection Bypass Tunnels . . . 9 4.1.1. Restoring Co-routing with Node Protection Bypass
Tunnels . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Unidirectional Link Failures . . . . . . . . . . . . . 9 4.1.2. Unidirectional Link Failures . . . . . . . . . . . . . 9
4.1.3. Revertive Behavior After Fast Reroute . . . . . . . . 9 4.1.3. Revertive Behavior after Fast Reroute . . . . . . . . 10
4.1.4. Bypass Tunnel Provisioning . . . . . . . . . . . . . . 10 4.1.4. Bypass Tunnel Provisioning . . . . . . . . . . . . . . 10
4.2. Bidirectional LSP Association At Mid-points . . . . . . . 10 4.1.5. One-to-One Bypass Tunnel . . . . . . . . . . . . . . . 10
5. Message and Object Definitions . . . . . . . . . . . . . . . . 10 4.2. Bidirectional LSP Association At Mid-points . . . . . . . 11
5.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 10 5. Message and Object Definitions . . . . . . . . . . . . . . . . 11
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Extended ASSOCIATION ID . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION
Object is specified in [RFC6780] which can be used generically to Object is specified in [RFC6780] which can be used generically to
associate (G)Multi-Protocol Label Switching (MPLS) Traffic associate (G)Multiprotocol Label Switching (MPLS) Traffic Engineering
Engineering (TE) Label Switched Paths (LSPs). [RFC7551] defines (TE) Label Switched Paths (LSPs). [RFC7551] defines mechanisms for
mechanisms for binding two point-to-point unidirectional LSPs binding two point-to-point unidirectional LSPs [RFC3209] into an
[RFC3209] into an associated bidirectional LSP. There are two models associated bidirectional LSP. There are two models described in
described in [RFC7551] for provisioning an associated bidirectional [RFC7551] for provisioning an associated bidirectional LSP, single-
LSP, single-sided and double-sided. In both models, the reverse LSP sided and double-sided. In both models, the reverse LSP of the
of the bidirectional LSP may or may not be co-routed and follow the bidirectional LSP may or may not be co-routed and follow the same
same path as its forward LSP. path as its forward LSP.
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
The Stateful PCE allows stateful control of the MPLS TE LSPs which The Stateful PCE allows stateful control of the MPLS TE LSPs which
may be initiated by the PCE or a PCC. As defined in [PCE-ASSOC- may be initiated by the PCE or a PCC. As defined in [PCE-ASSOC-
BIDIR], a Stateful PCE can be employed to initiate single-sided and BIDIR], a Stateful PCE can be employed to initiate single-sided and
double-sided associated bidirectional LSPs on PCC(s). double-sided associated bidirectional LSPs on PCC(s).
In packet transport networks, there are requirements where the In packet transport networks, there are requirements where the
reverse LSP of a bidirectional LSP needs to follow the same path as reverse LSP of a bidirectional LSP needs to follow the same path as
its forward LSP [RFC6373]. The MPLS Transport Profile (TP) [RFC6370] its forward LSP [RFC6373]. The MPLS Transport Profile (TP) [RFC6370]
architecture facilitates the co-routed bidirectional LSP by using the architecture facilitates the co-routed bidirectional LSP by using the
GMPLS extensions [RFC3473] to achieve congruent paths. However, the GMPLS extensions [RFC3473] to achieve congruent paths. However, the
RSVP association signaling allows to enable co-routed bidirectional RSVP association signaling allows to enable co-routed bidirectional
LSPs without having to deploy GMPLS extensions in the existing LSPs without having to deploy GMPLS extensions in the existing
networks. The association signaling also allows to take advantage of networks. The association signaling also allows to take advantage of
the existing TE and Fast Reroute (FRR) mechanisms in the network. the existing TE and Fast Reroute (FRR) mechanisms in the network.
[RFC4090] defines FRR extensions for MPLS TE LSPs and those are also [RFC4090] defines FRR extensions for MPLS TE LSPs and those are also
applicable to the associated bidirectional LSPs. [GMPLS-FRR] defines applicable to the associated bidirectional LSPs. [RFC8271] defines
FRR procedure for GMPLS signaled bidirectional LSPs, such as, co- FRR procedure for GMPLS signaled bidirectional LSPs, such as,
ordinate bypass tunnel assignments in the forward and reverse coordinate bypass tunnel assignments in the forward and reverse
directions of the LSP. The mechanisms defined in [GMPLS-FRR] are directions of the LSP. The mechanisms defined in [RFC8271] are also
also useful for the FRR of associated bidirectional LSPs. useful for the FRR of associated bidirectional LSPs.
This document describes FRR procedures for both single-sided and This document describes FRR procedures for both single-sided and
double-sided provisioned associated bidirectional LSPs. The FRR double-sided provisioned associated bidirectional LSPs. The FRR
procedures can ensure that for the co-routed LSPs, traffic flows on procedures can ensure that for the co-routed LSPs, traffic flows on
co-routed paths in the forward and reverse directions after a failure co-routed paths in the forward and reverse directions after a failure
event. event.
1.1. Assumptions and Considerations 1.1. Assumptions and Considerations
The following assumptions and considerations apply to this document: The following assumptions and considerations apply to this document:
o The FRR procedure to co-ordinate the bypass tunnel assignment o The FRR procedure for the unidirectional LSPs is defined in
defined in this document may be used for non-corouted associated [RFC4090] and is not modified by this document.
bidirectional protected LSPs but requires that the downstream PLR
and MP pair of the forward LSP matches the upstream MP and PLR
pair of the reverse LSP.
o The FRR procedure when using the unidirectional bypass tunnels is o The FRR procedure when using the unidirectional bypass tunnels is
defined in [RFC4090] and is not modified by this document. defined in [RFC4090] and is not modified by this document.
o This document assumes that the FRR bypass tunnels used for o This document assumes that the FRR bypass tunnels used for
associated bidirectional protected LSPs are also bidirectional. protected associated bidirectional LSPs are also associated
bidirectional.
o The FRR bypass tunnels used for co-routed associated bidirectional o The FRR bypass tunnels used for protected co-routed associated
protected LSPs are assumed to be co-routed. bidirectional LSPs are assumed to be co-routed associated
bidirectional.
o The FRR procedure to coordinate the bypass tunnel assignment
defined in this document may be used for protected non-corouted
associated bidirectional LSPs but requires that the downstream
Point of Local Repair (PLR) and Merge Point (MP) pair of the
forward LSP matches the upstream MP and PLR pair of the reverse
LSP.
o Unless otherwise specified in this document, the fast reroute
procedures defined in [RFC4090] are used for associated
bidirectional LSPs.
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].
2.2. Terminology 2.2. Terminology
The reader is assumed to be familiar with the terminology defined in The reader is assumed to be familiar with the terminology defined in
[RFC2205], [RFC3209], [RFC4090], [RFC7551], and [GMPLS-FRR]. [RFC2205], [RFC3209], [RFC4090], [RFC7551], and [RFC8271].
2.2.1. Forward Unidirectional LSPs 2.2.1. Forward Unidirectional LSPs
Two reverse unidirectional point-to-point (P2P) LSPs are setup in the Two reverse unidirectional point-to-point (P2P) LSPs are setup in the
opposite directions between a pair of source and destination nodes to opposite directions between a pair of source and destination nodes to
form an associated bidirectional LSP. In the case of single-sided form an associated bidirectional LSP. In the case of single-sided
provisioned LSP, the originating LSP with REVERSE_LSP Object is provisioned LSP, the originating LSP with REVERSE_LSP Object is
identified as a forward unidirectional LSP. In the case of double- identified as a forward unidirectional LSP. In the case of double-
sided provisioned LSP, the LSP originating from the higher node sided provisioned LSP, the LSP originating from the higher node
address (as source) and terminating on the lower node address (as address (as source) and terminating on the lower node address (as
skipping to change at page 5, line 30 skipping to change at page 5, line 40
nodes of the bidirectional LSP. Both forward and reverse LSPs are nodes of the bidirectional LSP. Both forward and reverse LSPs are
initiated independently by the two endpoints with (Extended) initiated independently by the two endpoints with (Extended)
ASSOCIATION Object containing Association Type set to "double-sided ASSOCIATION Object containing Association Type set to "double-sided
associated bidirectional LSP". With both single-sided and double- associated bidirectional LSP". With both single-sided and double-
sided provisioned bidirectional LSPs, the reverse LSP may or may not sided provisioned bidirectional LSPs, the reverse LSP may or may not
be congruent (i.e. co-routed) and follow the same path as its forward be congruent (i.e. co-routed) and follow the same path as its forward
LSP. LSP.
Both single-sided and double-sided associated bidirectional LSPs Both single-sided and double-sided associated bidirectional LSPs
require solutions to the following issues for fast reroute to ensure require solutions to the following issues for fast reroute to ensure
co-routedness after a failure event. co-routing after a failure event.
3.1. Fast Reroute Bypass Tunnel Assignment 3.1. Fast Reroute Bypass Tunnel Assignment
In order to ensure that the traffic flows on a co-routed path after a In order to ensure that the traffic flows on a co-routed path after a
link or node failure on the co-routed protected LSP path, the mid- link or node failure on the protected co-routed LSP path, the mid-
point Point of Local Repair (PLR) nodes need to assign matching point Point of Local Repair (PLR) nodes need to assign matching
bidirectional bypass tunnels for fast reroute. Such bypass bidirectional bypass tunnels for fast reroute. Such bypass
assignment requires co-ordination between the forward and reverse assignment requires coordination between the forward and reverse
direction PLR nodes when more than one bypass tunnels are present on direction PLR nodes when more than one bypass tunnels are present on
a PLR node. a PLR node.
<-- Bypass N --> <-- Bypass N -->
+-----+ +-----+ +-----+ +-----+
| H +---------+ I | | H +---------+ I |
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
| | | |
LSP1 --> | LSP1 --> | LSP1 --> LSP1 --> LSP1 --> | LSP1 --> | LSP1 --> LSP1 -->
skipping to change at page 6, line 27 skipping to change at page 6, line 27
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| F +---------+ G | | F +---------+ G |
+-----+ +-----+ +-----+ +-----+
<-- Bypass S --> <-- Bypass S -->
Figure 1: Multiple Bidirectional Bypass Tunnels Figure 1: Multiple Bidirectional Bypass Tunnels
As shown in Figure 1, there are two bypass tunnels available, Bypass As shown in Figure 1, there are two bypass tunnels available, Bypass
tunnel N (on path B-H-I-C) and Bypass tunnel S (on path B-F-G-C). tunnel N (on path B-H-I-C) and Bypass tunnel S (on path B-F-G-C).
The mid-point PLR nodes B and C need to co-ordinate bypass tunnel The mid-point PLR nodes B and C need to coordinate bypass tunnel
assignment to ensure that traffic in both directions flow through assignment to ensure that traffic in both directions flow through
either on the Bypass tunnel N (on path B-H-I-C) or the Bypass tunnel either on the Bypass tunnel N (on path B-H-I-C) or the Bypass tunnel
S (on path B-F-G-C), after the link B-C failure. S (on path B-F-G-C), after the link B-C failure.
3.2. Node Protection Bypass Tunnels 3.2. Node Protection Bypass Tunnels
When using a node protection bypass tunnel with a bidirectional When using a node protection bypass tunnel with a protected
protected LSP, after a link failure, the forward and reverse LSP associated bidirectional LSP, after a link failure, the forward and
traffic can flow on different node protection bypass tunnels in the reverse LSP traffic can flow on different node protection bypass
upstream and downstream directions. tunnels in the upstream and downstream directions.
<-- Bypass N --> <-- Bypass N -->
+-----+ +-----+ +-----+ +-----+
| H +------------------------+ I | | H +------------------------+ I |
+--+--+ +--+--+ +--+--+ +--+--+
| <-- Rerouted-LSP2 | | <-- Rerouted-LSP2 |
| | | |
| | | |
| LSP1 --> LSP1 --> | LSP1 --> LSP1 --> | LSP1 --> LSP1 --> | LSP1 --> LSP1 -->
+--+--+ +-----+ +--+--+ +-----+ +-----+ +--+--+ +-----+ +--+--+ +-----+ +-----+
skipping to change at page 7, line 20 skipping to change at page 7, line 20
Figure 2: Node Protection Bypass Tunnels Figure 2: Node Protection Bypass Tunnels
As shown in Figure 2, after the link B-C failure, the downstream PLR As shown in Figure 2, after the link B-C failure, the downstream PLR
node B reroutes the protected forward LSP1 traffic over the bypass node B reroutes the protected forward LSP1 traffic over the bypass
tunnel S (on path B-F-G-D) to reach downstream MP node D whereas the tunnel S (on path B-F-G-D) to reach downstream MP node D whereas the
upstream PLR node C reroute the protected reverse LSP2 traffic over upstream PLR node C reroute the protected reverse LSP2 traffic over
the bypass tunnel N (on path C-I-H-A) to reach the upstream MP node the bypass tunnel N (on path C-I-H-A) to reach the upstream MP node
A. As a result, the traffic in the forward and revere directions A. As a result, the traffic in the forward and revere directions
flows on different bypass tunnels and this can cause the co-routed flows on different bypass tunnels and this can cause the co-routed
bidirectional LSP to become non-corouted. However, unlike GMPLS associated bidirectional LSP to become non-corouted. However, unlike
LSPs, the asymmetry of paths in the forward and reverse directions GMPLS LSPs, the asymmetry of paths in the forward and reverse
does not result in RSVP soft-state time-out with the associated directions does not result in RSVP soft-state timeout with the
bidirectional LSPs. associated bidirectional LSPs.
3.3. Bidirectional LSP Association At Mid-Points 3.3. Bidirectional LSP Association At Mid-Points
In packet transport networks, a restoration LSP is signaled after a In packet transport networks, a restoration LSP is signaled after a
link failure on the protected LSP path and the protected LSP may or link failure on the protected LSP path and the protected LSP may or
may not be torn down [RFC8131]. In this case, multiple forward and may not be torn down [RFC8131]. In this case, multiple forward and
reverse LSPs of a co-routed bidirectional LSP may be present at mid- reverse LSPs of a co-routed associated bidirectional LSP may be
point nodes with identical (Extended) ASSOCIATION Objects. This present at mid-point nodes with identical (Extended) ASSOCIATION
creates an ambiguity at mid-point nodes to identify the correct Objects. This creates an ambiguity at mid-point nodes to identify
associated LSP pair for fast reroute bypass assignment (e.g. during the correct associated LSP pair for fast reroute bypass assignment
the recovery phase of RSVP graceful restart procedure). (e.g. during the recovery phase of RSVP graceful restart procedure).
LSP3 --> LSP3 --> LSP3 --> LSP3 --> LSP3 --> LSP3 -->
LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 -->
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E | | A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +--+--+ +-----+ +-----+ +-----+ +--+--+ +--+--+ +-----+ +-----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
<-- LSP4 | | <-- LSP4 <-- LSP4 <-- LSP4 | | <-- LSP4 <-- LSP4
| | | |
| LSP3 --> | | LSP3 --> |
+--+--+ +--+--+ +--+--+ +--+--+
| F +---------+ G | | F +---------+ G |
+-----+ +-----+ +-----+ +-----+
<-- Bypass S --> <-- Bypass S -->
<-- LSP4 <-- LSP4
Figure 3: Restoration LSP Set-up After Link Failure Figure 3: Restoration LSP Set-up after Link Failure
As shown in Figure 3, the protected LSPs LSP1 and LSP2 are an As shown in Figure 3, the protected LSPs LSP1 and LSP2 are an
associated LSP pair, similarly the restoration LSPs LSP3 and LSP4 are associated LSP pair, similarly the restoration LSPs LSP3 and LSP4 are
an associated LSP pair, both pairs belong to the same associated an associated LSP pair, both pairs belong to the same associated
bidirectional LSP and carry identical (Extended) ASSOCIATION Objects. bidirectional LSP and carry identical (Extended) ASSOCIATION Objects.
In this example, the mid-point node D may mistakenly associate LSP1 In this example, the mid-point node D may mistakenly associate LSP1
with the reverse LSP4 instead of the reverse LSP3 due to the matching with the reverse LSP4 instead of the reverse LSP3 due to the matching
(Extended) ASSOCIATION Objects. This may cause the co-routed (Extended) ASSOCIATION Objects. This may cause the co-routed
bidirectional LSP to become non-corouted. Since the bypass associated bidirectional LSP to become non-corouted after fast
assignment needs to be co-ordinated between the forward and reverse reroute. Since the bypass assignment needs to be coordinated between
LSPs, this can also lead to undesired bypass tunnel assignments. the forward and reverse LSPs, this can also lead to undesired bypass
tunnel assignments.
4. Signaling Procedure 4. Signaling Procedure
4.1. Bidirectional LSP Fast Reroute 4.1. Associated Bidirectional LSP Fast Reroute
For both single-sided and double-sided associated bidirectional LSPs, For both single-sided and double-sided associated bidirectional LSPs,
the fast reroute procedure specified in [RFC4090] is used. In the fast reroute procedure specified in [RFC4090] is used. In
addition, the mechanisms defined in [GMPLS-FRR] are used as addition, the mechanisms defined in [RFC8271] are used as following.
following.
o The BYPASS_ASSIGNMENT subobject defined in [GMPLS-FRR] is used to o The BYPASS_ASSIGNMENT IPv4 subobject (value: 38) and IPv6
co-ordinate bypass tunnel assignment between the forward and subobject (value: 39) defined in [RFC8271] are used to coordinate
reverse direction PLR nodes (see Figure 1). The BYPASS_ASSIGNMENT bypass tunnel assignment between the forward and reverse direction
and Node-ID address [RFC4561] subobjects MUST be added by the PLR nodes (see Figure 1). The BYPASS_ASSIGNMENT and Node-ID
downstream PLR node in the RECORD_ROUTE Object (RRO) of the RSVP address [RFC4561] subobjects MUST be added by the downstream PLR
Path message of the forward LSP to indicate the bypass tunnel node in the RECORD_ROUTE Object (RRO) of the RSVP Path message of
assignment. The upstream PLR node MUST NOT add the the forward LSP to indicate the local bypass tunnel assignment
BYPASS_ASSIGNMENT subobject in the RRO of the RSVP Path message of using the procedure defined in [RFC8271]. The upstream node uses
the reverse LSP. the bypass assignment information (namely, bypass tunnel source
address, destination address and Tunnel ID) in the received RSVP
Path message of the protected forward LSP to find the associated
bypass tunnel in the reverse direction. The upstream PLR node
MUST NOT add the BYPASS_ASSIGNMENT subobject in the RRO of the
RSVP Path message of the reverse LSP.
o The downstream PLR node always initiates the bypass tunnel o The downstream PLR node always initiates the bypass tunnel
assignment for the forward LSP. The upstream PLR (forward assignment for the forward LSP. The upstream PLR (forward
direction LSP MP) node simply reflects the bypass tunnel direction LSP MP) node simply reflects the associated bypass
assignment for the reverse direction LSP. The upstream PLR node tunnel assignment for the reverse direction LSP. The upstream PLR
MUST NOT initiate the bypass tunnel assignment. node MUST NOT initiate the bypass tunnel assignment.
o If the bypass tunnel is not found, the upstream PLR SHOULD send a o If the indicated forward bypass tunnel or the associated reverse
Notify message [RFC3473] with Error-code - "FRR Bypass Assignment bypass tunnel is not found, the upstream PLR SHOULD send a Notify
Error" and Sub-code - "Bypass Tunnel Not Found" [GMPLS-FRR] to the message [RFC3473] with Error-code "FRR Bypass Assignment Error"
downstream PLR. (value: 44) and Sub-code "Bypass Tunnel Not Found" (value: 1)
o If the bypass tunnel can not be used due to a local policy as [RFC8271] to the downstream PLR.
described in Section 4.5.3 in [GMPLS-FRR], the upstream PLR SHOULD
send a Notify message [RFC3473] with Error-code - "FRR Bypass o If the bypass tunnel can not be used as described in Section 4.5.3
Assignment Error" and Sub-code - "Bypass Assignment Cannot Be in [RFC8271], the upstream PLR SHOULD send a Notify message
Used" [GMPLS-FRR] to the downstream PLR. [RFC3473] with Error-code "FRR Bypass Assignment Error" (value:
44) and Sub-code "Bypass Assignment Cannot Be Used" (value: 0)
[RFC8271] to the downstream PLR.
o After a link or node failure, the PLR nodes in both forward and o After a link or node failure, the PLR nodes in both forward and
reverse directions trigger fast reroute independently using the reverse directions trigger fast reroute independently using the
procedures defined in [RFC4090] and send the forward and reverse procedures defined in [RFC4090] and send the forward and protected
LSP RSVP Path messages and traffic over the bypass tunnel. reverse LSP modified RSVP Path messages and traffic over the
bypass tunnel. The RSVP Resv signaling of the protected forward
and reverse LSPs follows the same procedure as defined in
[RFC4090] and is not modified by this document.
4.1.1. Re-corouting with Node Protection Bypass Tunnels 4.1.1. Restoring Co-routing with Node Protection Bypass Tunnels
After fast reroute, the downstream MP node assumes the role of After fast reroute, the downstream MP node assumes the role of
upstream PLR and reroutes the reverse LSP RSVP Path messages and upstream PLR and reroutes the reverse LSP RSVP Path messages and
traffic over the bypass tunnel on which the forward LSP RSVP Path traffic over the bypass tunnel on which the forward LSP RSVP Path
messages and traffic are received. This is defined as re-corouting messages and traffic are received. This procedure is defined as
procedure in [GMPLS-FRR]. This procedure is used to ensure that both restoring co-routing in [RFC8271]. This procedure is used to ensure
forward and reverse LSP signaling and traffic flow on the same that both forward and reverse LSP signaling and traffic flow on the
bidirectional bypass tunnel after fast reroute. same bidirectional bypass tunnel after fast reroute.
As shown in Figure 2, when using a node protection bypass tunnel with As shown in Figure 2, when using a node protection bypass tunnel with
co-routed protected LSPs, asymmetry of paths can occur in the forward protected co-routed LSPs, asymmetry of paths can occur in the forward
and reverse directions after a link failure [GMPLS-FRR]. In order to and reverse directions after a link failure [RFC8271]. In order to
restore co-routedness, the downstream MP node D (acting as an restore co-routing, the downstream MP node D (acting as an upstream
upstream PLR) SHOULD trigger re-coroute procedure and reroute the PLR) SHOULD trigger procedure to restore co-routing and reroute the
reverse protected LSP2 RSVP Path messages and traffic over the bypass protected reverse LSP2 RSVP Path messages and traffic over the bypass
tunnel S (on path D-G-F-B) to the upstream MP node B. The upstream tunnel S (on path D-G-F-B) to the upstream MP node B upon receiving
the protected forward LSP modified RSVP Path messages and traffic
over the bypass tunnel S (on path D-G-F-B) from node B. The upstream
PLR node C stops receiving the RSVP Path messages and traffic for the PLR node C stops receiving the RSVP Path messages and traffic for the
reverse LSP2 from node D and it stops sending the RSVP Path messages reverse LSP2 from node D (resulting in RSVP soft-state timeout) and
for the reverse LSP2 on the bypass tunnel N (on path C-I-H-A). it stops sending the RSVP Path messages for the reverse LSP2 over the
bypass tunnel N (on path C-I-H-A) to node A.
4.1.2. Unidirectional Link Failures 4.1.2. Unidirectional Link Failures
The unidirectional link failures can cause co-routed bidirectional The unidirectional link failures can cause co-routed associated
LSPs to become non-corouted after fast reroute with both link bidirectional LSPs to become non-corouted after fast reroute with
protection and node protection bypass tunnels. The asymmetry of both link protection and node protection bypass tunnels. However,
forward and reverse LSP paths due to the unidirectional link failure the unidirectional link failures in the upstream and/or downstream
in the downstream direction can be corrected by using the directions do not result in RSVP soft-state timeout with the
re-corouting procedure specified in Section 4.1.1 of this document. associated bidirectional LSPs as upstream and downstream PLRs trigger
In any case, the unidirectional link failures in the upstream and/or fast reroute independently. The asymmetry of forward and reverse LSP
downstream directions do not result in RSVP soft-state time-out with paths due to the unidirectional link failure in the downstream
the associated bidirectional LSPs. direction can be corrected by using the procedure to restore co-
routing specified in Section 4.1.1.
4.1.3. Revertive Behavior After Fast Reroute 4.1.3. Revertive Behavior after Fast Reroute
When the revertive behavior is desired for a protected LSP after the When the revertive behavior is desired for a protected LSP after the
link is restored, the procedure defined in [RFC4090], Section 6.5.2, link is restored, the procedure defined in [RFC4090], Section 6.5.2,
is followed. is followed.
o The upstream and downstream PLR nodes independently start sending o The downstream PLR node starts sending the RSVP Path messages and
the RSVP Path messages and traffic flow of the protected LSP over traffic flow of the protected forward LSP over the restored link
the restored link and stop sending them over the bypass tunnel and stops sending them over the bypass tunnel [RFC4090].
[RFC4090].
o The upstream PLR node (when the protected LSP is present) also
starts sending the RSVP Path messages and traffic flow of the
protected reverse LSPs over the restored link and stops sending
them over the bypass tunnel [RFC4090].
o In case of node protection bypass tunnels (see Figure 2), after o In case of node protection bypass tunnels (see Figure 2), after
re-corouting, the upstream PLR node D SHOULD start sending RSVP restoring co-routing, the upstream PLR node D SHOULD start sending
Path messages and traffic for the reverse LSP over the original RSVP Path messages and traffic for the reverse LSP over the
link (D-C) when it receives the RSVP Path messages and traffic for original link (C-D) when it receives the un-modified RSVP Path
the forward LSP over it and stops sending them over the bypass messages and traffic for the protected forward LSP over it and
tunnel S. stops sending them over the bypass tunnel S (on path D-G-F-B).
4.1.4. Bypass Tunnel Provisioning 4.1.4. Bypass Tunnel Provisioning
Fast reroute bidirectional bypass tunnels can be single-sided or Fast reroute bidirectional bypass tunnels can be single-sided or
double-sided associated tunnels. For both single-sided and double- double-sided associated tunnels. For both single-sided and double-
sided associated bypass tunnels, the fast reroute assignment policies sided associated bypass tunnels, the fast reroute assignment policies
need to be configured on the downstream PLR nodes of the protected need to be configured on the downstream PLR nodes of the protected
LSPs that initiate the bypass tunnel assignments. For single-sided LSPs that initiate the bypass tunnel assignments. For single-sided
associated bypass tunnels, these nodes are the originating nodes of associated bypass tunnels, these nodes are the originating endpoints
their signaling. of their signaling.
4.1.5. One-to-One Bypass Tunnel
The fast reroute signaling 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
described in Section 5.4.2 of [RFC8271], in one-to-one backup method,
if the associated bidirectional 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: 44) and Sub-code
"One-to-One Bypass Already in Use" (value: 2) to the downstream PLR.
4.2. Bidirectional LSP Association At Mid-points 4.2. Bidirectional LSP Association At Mid-points
In order to associate the LSPs unambiguously at a mid-point node (see In order to associate the LSPs unambiguously at a mid-point node (see
Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object
and add unique Extended Association ID for each associated forward and add unique Extended Association ID for each associated forward
and reverse LSP pair forming the bidirectional LSP. As an example, and reverse LSP pair forming the bidirectional LSP. As an example,
an endpoint node MAY set the Extended Association ID to the value an endpoint node MAY set the Extended Association ID to the value
specified in Section 5.1 of this document. specified in Section 5.1.
o For single-sided provisioned bidirectional LSPs [RFC7551], the o For single-sided provisioned bidirectional LSPs [RFC7551], the
originating endpoint signals the Extended ASSOCIATION Object with originating endpoint signals the Extended ASSOCIATION Object with
a unique Extended Association ID. The remote endpoint copies the a unique Extended Association ID. The remote endpoint copies the
contents of the received Extended ASSOCIATION Object including the contents of the received Extended ASSOCIATION Object including the
Extended Association ID in the RSVP Path message of the reverse Extended Association ID in the RSVP Path message of the reverse
LSP's Extended ASSOCIATION Object. LSP's Extended ASSOCIATION Object.
o For double-sided provisioned bidirectional LSPs [RFC7551], both o For double-sided provisioned bidirectional LSPs [RFC7551], both
endpoints need to ensure that the bidirectional LSP has a unique endpoints need to ensure that the bidirectional LSP has a unique
Extended ASSOCIATION Object for each forward and reverse LSP pair Extended ASSOCIATION Object for each forward and reverse LSP pair
by selecting appropriate unique Extended Association IDs signaled by selecting appropriate unique Extended Association IDs signaled
by them. by them.
5. Message and Object Definitions 5. Message and Object Definitions
5.1. Extended ASSOCIATION Object 5.1. Extended ASSOCIATION ID
The Extended Association ID in the Extended ASSOCIATION Object The Extended Association ID in the Extended ASSOCIATION Object
[RFC6780] can be set to the value specified as following to uniquely [RFC6780] can be set to the value specified as following to uniquely
identify associated forward and reverse LSP pair of a bidirectional identify associated forward and reverse LSP pair of an associated
LSP. bidirectional LSP.
IPv4 Extended Association ID format is shown below: IPv4 Extended Association ID format is shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 LSP Source Address | | IPv4 LSP Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP-ID | | Reserved | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 32 skipping to change at page 13, line 11
Variable Length ID Variable Length ID
Variable length ID inserted by the endpoint node of the associated Variable length ID inserted by the endpoint node of the associated
bidirectional LSP [RFC6780]. bidirectional LSP [RFC6780].
6. Compatibility 6. Compatibility
This document describes the procedures for fast reroute for This document describes the procedures for fast reroute for
associated bidirectional LSPs. Operators wishing to use this associated bidirectional LSPs. Operators wishing to use this
function SHOULD ensure that it is supported on the nodes on the LSP function SHOULD ensure that it is supported on the nodes on the LSP
path. path. No new signaling messages are defines in this document.
7. Security Considerations 7. Security Considerations
This document uses the signaling mechanisms defined in [RFC7551] and This document uses the signaling mechanisms defined in [RFC7551] and
[GMPLS-FRR] and does not introduce any additional security [RFC8271] and does not introduce any additional security
considerations other than those already covered in [RFC7551], [GMPLS- considerations other than those already covered in [RFC7551],
FRR] and the MPLS/GMPLS security framework [RFC5920]. [RFC8271], and the MPLS/GMPLS security framework [RFC5920].
8. IANA Considerations 8. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
9. References 9. References
9.1. Normative References 9.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
skipping to change at page 13, line 27 skipping to change at page 14, line 27
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.
[RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
Association Object Extensions", RFC 6780, October 2012. Association Object Extensions", RFC 6780, October 2012.
[RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional LSPs", RFC 7551, Extensions for Associated Bidirectional Label Switched
May 2015. Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
<https://www.rfc-editor.org/info/rfc7551>.
[GMPLS-FRR] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., [RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and
and M. Bhatia, "Extensions to Resource Reservation M. Bhatia, "Updates to Resource Reservation Protocol for
Protocol For Fast Reroute of Traffic Engineering GMPLS Fast Reroute of Traffic Engineering GMPLS Label Switched
LSPs", draft-ietf-teas-gmpls-lsp-fastreroute (work in Paths (LSPs)", RFC 8271, October 2017.
progress).
9.2. Informative References 9.2. Informative References
[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
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
skipping to change at page 14, line 9 skipping to change at page 15, line 9
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E.
Gray, "MPLS Transport Profile (MPLS-TP) Control Plane Gray, "MPLS Transport Profile (MPLS-TP) Control Plane
Framework", RFC 6373, September 2011. Framework", RFC 6373, September 2011.
[RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., [RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and
Brzozowski, P., "RSVP-TE Signaling Procedure for End-to- P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End
End GMPLS Restoration and Resource Sharing", RFC 8131, GMPLS Restoration and Resource Sharing", RFC 8131, March
March 2017. 2017.
[PCE-ASSOC-BIDIR] Barth, C., Gandhi, R., and B. Wen, "PCEP [PCE-ASSOC-BIDIR] Barth, C., Gandhi, R., and B. Wen, "PCEP
Extensions for Associated Bidirectional Label Switched Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", draft-barth-pce-association-bidir (work in Paths (LSPs)", draft-barth-pce-association-bidir (work in
progress). progress).
Acknowledgments Acknowledgments
A special thanks to the authors of [GMPLS-FRR], this document uses A special thanks to the authors of [RFC8271], this document uses the
the mechanisms defined in that document. signaling mechanisms defined in that document.
Authors' Addresses Authors' Addresses
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com Email: rgandhi@cisco.com
Himanshu Shah Himanshu Shah
Ciena Ciena
Email: hshah@ciena.com Email: hshah@ciena.com
Jeremy Whittaker Jeremy Whittaker
Verizon Verizon
 End of changes. 48 change blocks. 
145 lines changed or deleted 188 lines changed or added

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