draft-ietf-teas-assoc-corouted-bidir-frr-00.txt   draft-ietf-teas-assoc-corouted-bidir-frr-01.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 19, 2017 Ciena Expires: November 25, 2017 Ciena
Jeremy Whittaker J. Whittaker
Verizon Verizon
May 18, 2017 May 24, 2017
Fast Reroute Procedures For Associated Bidirectional Label Fast Reroute Procedures for
Switched Paths (LSPs) Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-teas-assoc-corouted-bidir-frr-00 draft-ietf-teas-assoc-corouted-bidir-frr-01
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 are applicable to co-routed and non co-routed LSPs. For procedures can ensure that for the co-routed LSPs, traffic flows on
co-routed LSPs, the FRR procedures can ensure that 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.
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
skipping to change at page 2, line 19 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 1.1. Assumptions and Considerations . . . . . . . . . . . . . . 3
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4
2.2.1. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Forward Unidirectional LSPs . . . . . . . . . . . . . 4
3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 4 2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4
3.2. Bidirectional LSP Association At Mid-Points . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 6 3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 5
4.1. Bidirectional LSP Fast Reroute . . . . . . . . . . . . . . 6 3.2. Node Protection Bypass Tunnels . . . . . . . . . . . . . . 6
4.2. Bidirectional LSP Association At Mid-points . . . . . . . 7 3.3. Bidirectional LSP Association At Mid-Points . . . . . . . 7
5. Message and Object Definitions . . . . . . . . . . . . . . . . 7 4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 8
5.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 7 4.1. Bidirectional LSP Fast Reroute . . . . . . . . . . . . . . 8
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Re-corouting with Node Protection Bypass Tunnels . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4.1.2. Unidirectional Link Failures . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. Revertive Behavior After Fast Reroute . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.4. Bypass Tunnel Provisioning . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 4.2. Bidirectional LSP Association At Mid-points . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10 5. Message and Object Definitions . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 10
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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) Label Switched associate (G)Multi-Protocol Label Switching (MPLS) Traffic
Paths (LSPs). [RFC7551] defines mechanisms for binding two point-to- Engineering (TE) Label Switched Paths (LSPs). [RFC7551] defines
point unidirectional LSPs [RFC3209] into an associated bidirectional mechanisms for binding two point-to-point unidirectional LSPs
LSP. There are two models described in [RFC7551] for provisioning an [RFC3209] into an associated bidirectional LSP. There are two models
associated bidirectional LSP, single-sided and double-sided. In both described in [RFC7551] for provisioning an associated bidirectional
models, the reverse LSP of the bidirectional LSP may or may not be LSP, single-sided and double-sided. In both models, the reverse LSP
co-routed and follow the same path as its forward LSP. of the bidirectional LSP may or may not be co-routed and follow the
same path as its forward LSP.
[GMPLS-FRR] defines Fast Reroute (FRR) procedure for GMPLS signaled The Path Computation Element Communication Protocol (PCEP) provides
LSPs to co-ordinate bypass tunnel assignments in the forward and mechanisms for Path Computation Elements (PCEs) to perform path
reverse directions. The mechanisms defined in [GMPLS-FRR] are computations in response to Path Computation Clients (PCCs) requests.
applicable to FRR of associated bidirectional LSPs. 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-
BIDIR], a Stateful PCE can be employed to initiate single-sided and
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 Traffic Engineering (TE) and FRR mechanisms in the the existing TE and Fast Reroute (FRR) mechanisms in the network.
network.
[RFC4090] defines FRR extensions for MPLS TE LSPs and those are also
applicable to the associated bidirectional LSPs. [GMPLS-FRR] defines
FRR procedure for GMPLS signaled bidirectional LSPs, such as, co-
ordinate bypass tunnel assignments in the forward and reverse
directions of the LSP. The mechanisms defined in [GMPLS-FRR] are
also 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 are applicable to co-routed and non co-routed LSPs. For procedures can ensure that for the co-routed LSPs, traffic flows on
co-routed LSPs, the FRR procedures can ensure that 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
The following assumptions and considerations apply to this document:
o The FRR procedure to co-ordinate the bypass tunnel assignment
defined in this document may be used for non-corouted associated
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
defined in [RFC4090] and is not modified by this document.
o This document assumes that the FRR bypass tunnels used for
associated bidirectional protected LSPs are also bidirectional.
o The FRR bypass tunnels used for co-routed associated bidirectional
protected LSPs are assumed to be co-routed.
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 in The reader is assumed to be familiar with the terminology defined in
[RFC2205], [RFC3209], [RFC4090] and [RFC7551]. [RFC2205], [RFC3209], [RFC4090], [RFC7551], and [GMPLS-FRR].
2.2.1. Reverse Co-routed Unidirectional LSPs 2.2.1. Forward Unidirectional LSPs
Two reverse unidirectional point-to-point (P2P) LSPs are setup in the
opposite directions between a pair of source and destination nodes to
form an associated bidirectional LSP. In the case of single-sided
provisioned LSP, the originating LSP with REVERSE_LSP Object is
identified as a forward unidirectional LSP. In the case of double-
sided provisioned LSP, the LSP originating from the higher node
address (as source) and terminating on the lower node address (as
destination) is identified as a forward unidirectional LSP.
2.2.2. Reverse Co-routed 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. A reverse unidirectional LSP form an associated bidirectional LSP. A reverse unidirectional LSP
originates on the same node where the forward unidirectional LSP originates on the same node where the forward unidirectional LSP
terminates, and it terminates on the same node where the forward terminates, and it terminates on the same node where the forward
unidirectional LSP originates. A reverse co-routed unidirectional unidirectional LSP originates. A reverse co-routed unidirectional
LSP traverses along the same path of the forward direction LSP traverses along the same path as the forward direction
unidirectional LSP in the opposite direction. unidirectional LSP in the opposite direction.
3. Overview 3. Overview
As specified in [RFC7551], in the single-sided provisioning case, the As specified in [RFC7551], in the single-sided provisioning case, the
RSVP TE tunnel is configured only on one endpoint node of the RSVP TE tunnel is configured only on one endpoint node of the
bidirectional LSP. An LSP for this tunnel is initiated by the bidirectional LSP. An LSP for this tunnel is initiated by the
originating endpoint with (Extended) ASSOCIATION Object containing originating endpoint with (Extended) ASSOCIATION Object containing
Association Type set to "single-sided associated bidirectional LSP" Association Type set to "single-sided associated bidirectional LSP"
and REVERSE_LSP Object inserted in the Path message. The remote and REVERSE_LSP Object inserted in the RSVP Path message. The remote
endpoint then creates the corresponding reverse TE tunnel and signals endpoint then creates the corresponding reverse TE tunnel and signals
the reverse LSP in response using the information from the the reverse LSP in response using the information from the
REVERSE_LSP Object and other objects present in the received Path REVERSE_LSP Object and other objects present in the received RSVP
message. As specified in [RFC7551], in the double-sided provisioning Path message. As specified in [RFC7551], in the double-sided
case, the RSVP TE tunnel is configured on both endpoint nodes of the provisioning case, the RSVP TE tunnel is configured on both endpoint
bidirectional LSP. Both forward and reverse LSPs are initiated nodes of the bidirectional LSP. Both forward and reverse LSPs are
independently by the two endpoints with (Extended) ASSOCIATION Object initiated independently by the two endpoints with (Extended)
containing Association Type set to "double-sided associated ASSOCIATION Object containing Association Type set to "double-sided
bidirectional LSP". In both single-sided and double-sided associated bidirectional LSP". With both single-sided and double-
provisioned bidirectional LSPs, the reverse LSP may or may not be sided provisioned bidirectional LSPs, the reverse LSP may or may not
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.
In the case of single-sided provisioned LSP, the originating LSP with
REVERSE_LSP Object is identified as a forward LSP. In the case of
double-sided provisioned LSP, the LSP originating from the higher
node address (as source) and terminating on the lower node address
(as destination) is identified as a forward LSP. The reverse LSP of
the bidirectional LSP traverses in the opposite direction of the
forward 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. require solutions to the following issues for fast reroute to ensure
co-routedness 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 protected LSP path, the mid-point Point link or node failure on the co-routed protected LSP path, the mid-
of Local Repair (PLR) nodes need to assign matching bidirectional point Point of Local Repair (PLR) nodes need to assign matching
bypass tunnels for fast reroute. Even for a non co-routed bidirectional bypass tunnels for fast reroute. Such bypass
bidirectional LSP, it is desired that the same bidirectional bypass
tunnel is used in both directions of the protected LSP. Such bypass
assignment requires co-ordination between the forward and reverse assignment requires co-ordination 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 -->
+----+ +--+--+ +--+--+ +----+ +----+ +-----+ +--+--+ +--+--+ +-----+ +-----+
| A +---------+ B +----X----+ C +---------+ D +---------+ E | | A +--------+ B +----X----+ C +--------+ D +--------+ E |
+----+ +--+--+ +--+--+ +----+ +----+ +-----+ +--+--+ +--+--+ +-----+ +-----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
| | | |
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| 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
N on path B-H-I-C and Bypass S on path B-F-G-C. The mid-point PLR tunnel N (on path B-H-I-C) and Bypass tunnel S (on path B-F-G-C).
nodes B and C need to co-ordinate bypass tunnel assignment to ensure The mid-point PLR nodes B and C need to co-ordinate bypass tunnel
that traffic in both directions flow through either on the Bypass N assignment to ensure that traffic in both directions flow through
path B-H-I-C or the Bypass S path B-F-G-C, after the link B-C either on the Bypass tunnel N (on path B-H-I-C) or the Bypass tunnel
failure. S (on path B-F-G-C), after the link B-C failure.
3.2. Bidirectional LSP Association At Mid-Points 3.2. Node Protection Bypass Tunnels
When using a node protection bypass tunnel with a bidirectional
protected LSP, after a link failure, the forward and reverse LSP
traffic can flow on different node protection bypass tunnels in the
upstream and downstream directions.
<-- Bypass N -->
+-----+ +-----+
| H +------------------------+ I |
+--+--+ +--+--+
| <-- Rerouted-LSP2 |
| |
| |
| LSP1 --> LSP1 --> | LSP1 --> LSP1 -->
+--+--+ +-----+ +--+--+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +-----+ +--+--+ +-----+
<-- LSP2 | <-- LSP2 <-- LSP2 | <-- LSP2
| |
| |
| Rerouted-LSP1 --> |
+--+--+ +--+--+
| F +------------------------+ G |
+-----+ +-----+
<-- Bypass S -->
Figure 2: Node Protection Bypass Tunnels
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
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
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
flows on different bypass tunnels and this can cause the co-routed
bidirectional LSP to become non-corouted. However, unlike GMPLS
LSPs, the asymmetry of paths in the forward and reverse directions
does not result in RSVP soft-state time-out with the associated
bidirectional LSPs.
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 and the protected LSP may or may link failure on the protected LSP path and the protected LSP may or
not be torn down [GMPLS-REST]. In this case, multiple forward and may not be torn down [RFC8131]. In this case, multiple forward and
reverse LSPs of a bidirectional LSP may be present at mid-point nodes reverse LSPs of a co-routed bidirectional LSP may be present at mid-
with identical (Extended) ASSOCIATION Objects. This creates an point nodes with identical (Extended) ASSOCIATION Objects. This
ambiguity at mid-point nodes to identify the correct associated LSP creates an ambiguity at mid-point nodes to identify the correct
pair for fast reroute bypass assignment (e.g. during the recovery associated LSP pair for fast reroute bypass assignment (e.g. during
phase of RSVP graceful restart procedure). 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 -->
<-- LSP4 <-- LSP4
Figure 2: Restoration LSP Set-up After Link Failure Figure 3: Restoration LSP Set-up After Link Failure
As shown in Figure 2, protected LSPs LSP1 and LSP2 are an associated As shown in Figure 3, the protected LSPs LSP1 and LSP2 are an
LSP pair, similarly restoration LSPs LSP3 and LSP4 are an associated associated LSP pair, similarly the restoration LSPs LSP3 and LSP4 are
LSP pair, both pairs belong to the same associated bidirectional LSP an associated LSP pair, both pairs belong to the same associated
and carry identical (Extended) ASSOCIATION Objects. In this example, bidirectional LSP and carry identical (Extended) ASSOCIATION Objects.
mid-point node D may mistakenly associate LSP1 with reverse LSP4 In this example, the mid-point node D may mistakenly associate LSP1
instead of reverse LSP3 due to the matching (Extended) ASSOCIATION with the reverse LSP4 instead of the reverse LSP3 due to the matching
Objects. This may cause the bidirectional LSP to become non co- (Extended) ASSOCIATION Objects. This may cause the co-routed
routed. Since a reverse LSP reflects the bypass tunnel assignment bidirectional LSP to become non-corouted. Since the bypass
received in the forward LSP, this can also lead to undesired bypass assignment needs to be co-ordinated between the forward and reverse
tunnel assignments. LSPs, this can also lead to undesired bypass tunnel assignments.
4. Signaling Procedure 4. Signaling Procedure
4.1. Bidirectional LSP Fast Reroute 4.1. Bidirectional LSP Fast Reroute
The mechanisms defined in [GMPLS-FRR] are used for fast reroute of For both single-sided and double-sided associated bidirectional LSPs,
both single-sided and double-sided associated bidirectional LSPs as the fast reroute procedure specified in [RFC4090] is used. In
addition, the mechanisms defined in [GMPLS-FRR] are used as
following. following.
o As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject is o The BYPASS_ASSIGNMENT subobject defined in [GMPLS-FRR] is used to
signaled in the RRO of the Path message to co-ordinate bypass co-ordinate bypass tunnel assignment between the forward and
tunnel assignment between the forward and reverse direction PLR reverse direction PLR nodes (see Figure 1). The BYPASS_ASSIGNMENT
nodes. A BYPASS_ASSIGNMENT subobject MUST be added by the forward and Node-ID address [RFC4561] subobjects MUST be added by the
direction PLR node in the Path message of the forward LSP to downstream PLR node in the RECORD_ROUTE Object (RRO) of the RSVP
indicate the bypass tunnel assigned. Path message of the forward LSP to indicate the bypass tunnel
assignment. 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 forward direction PLR node always initiates the bypass tunnel o The downstream PLR node always initiates the bypass tunnel
assignment for the forward LSP. The reverse direction PLR assignment for the forward LSP. The upstream PLR (forward
(forward direction LSP Merge Point (MP)) node simply reflects the direction LSP MP) node simply reflects the bypass tunnel
bypass tunnel assignment for the reverse direction LSP. assignment for the reverse direction LSP. The upstream PLR node
MUST NOT initiate the bypass tunnel assignment.
o If the bypass tunnel is not found, the upstream PLR SHOULD send a
Notify message [RFC3473] with Error-code - "FRR Bypass Assignment
Error" and Sub-code - "Bypass Tunnel Not Found" [GMPLS-FRR] to the
downstream PLR.
o If the bypass tunnel can not be used due to a local policy as
described in Section 4.5.3 in [GMPLS-FRR], the upstream PLR SHOULD
send a Notify message [RFC3473] with Error-code - "FRR Bypass
Assignment Error" and Sub-code - "Bypass Assignment Cannot Be
Used" [GMPLS-FRR] 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]. procedures defined in [RFC4090] and send the forward and reverse
LSP RSVP Path messages and traffic over the bypass tunnel.
o When using a node protection bypass tunnel, asymmetry of paths can 4.1.1. Re-corouting with Node Protection Bypass Tunnels
occur in the forward and reverse directions of the bidirectional
LSP after a link failure when using co-routed LSPs [GMPLS-FRR]. After fast reroute, the downstream MP node assumes the role of
This can be corrected using the re-corouting procedure defined in upstream PLR and reroutes the reverse LSP RSVP Path messages and
[GMPLS-FRR]. Unlike GMPLS LSPs, the asymmetry of paths in the traffic over the bypass tunnel on which the forward LSP RSVP Path
forward and reverse directions does not result in RSVP soft-state messages and traffic are received. This is defined as re-corouting
time-out with the associated bidirectional LSPs. procedure in [GMPLS-FRR]. This procedure is used to ensure that both
forward and reverse LSP signaling and traffic flow on the same
bidirectional bypass tunnel after fast reroute.
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
and reverse directions after a link failure [GMPLS-FRR]. In order to
restore co-routedness, the downstream MP node D (acting as an
upstream PLR) SHOULD trigger re-coroute procedure and reroute the
reverse protected 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
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
for the reverse LSP2 on the bypass tunnel N (on path C-I-H-A).
4.1.2. Unidirectional Link Failures
The unidirectional link failures can cause co-routed bidirectional
LSPs to become non-corouted after fast reroute with both link
protection and node protection bypass tunnels. The asymmetry of
forward and reverse LSP paths due to the unidirectional link failure
in the downstream direction can be corrected by using the
re-corouting procedure specified in Section 4.1.1 of this document.
In any case, the unidirectional link failures in the upstream and/or
downstream directions do not result in RSVP soft-state time-out with
the associated bidirectional LSPs.
4.1.3. Revertive Behavior After Fast Reroute
When the revertive behavior is desired for a protected LSP after the
link is restored, the procedure defined in [RFC4090], Section 6.5.2,
is followed.
o The upstream and downstream PLR nodes independently start sending
the RSVP Path messages and traffic flow of the protected LSP over
the restored link and stop sending them over the bypass tunnel
[RFC4090].
o In case of node protection bypass tunnels (see Figure 2), after
re-corouting, the upstream PLR node D SHOULD start sending RSVP
Path messages and traffic for the reverse LSP over the original
link (D-C) when it receives the RSVP Path messages and traffic for
the forward LSP over it and stops sending them over the bypass
tunnel S.
4.1.4. Bypass Tunnel Provisioning
Fast reroute bidirectional bypass tunnels can be single-sided or
double-sided associated tunnels. For both single-sided and double-
sided associated bypass tunnels, the fast reroute assignment policies
need to be configured on the downstream PLR nodes of the protected
LSPs that initiate the bypass tunnel assignments. For single-sided
associated bypass tunnels, these nodes are the originating nodes of
their signaling.
4.2. Bidirectional LSP Association At Mid-points 4.2. Bidirectional LSP Association At Mid-points
In order to associate the correct LSPs at a mid-point node, an In order to associate the LSPs unambiguously at a mid-point node (see
endpoint node MUST signal Extended ASSOCIATION Object and add unique Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object
Extended Association ID for each associated forward and reverse LSP and add unique Extended Association ID for each associated forward
pair forming the bidirectional LSP. As an example, an endpoint node and reverse LSP pair forming the bidirectional LSP. As an example,
MAY set the Extended Association ID to the value specified in Section an endpoint node MAY set the Extended Association ID to the value
5.1 of this document. specified in Section 5.1 of this document.
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 provisioning appropriate Extended Association IDs signaled by by selecting appropriate unique Extended Association IDs signaled
them. by them.
5. Message and Object Definitions 5. Message and Object Definitions
5.1. Extended ASSOCIATION Object 5.1. Extended ASSOCIATION Object
The Extended Association ID in the Extended ASSOCIATION Object
[RFC6780] can be set to the value specified as following to uniquely
identify associated forward and reverse LSP pair of a bidirectional
LSP.
The Extended Association ID in the Extended ASSOCIATION Object can be IPv4 Extended Association ID format is shown below:
set to the value specified as following to uniquely identify
associated forward and reverse LSP pair of a bidirectional LSP.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: Variable Length ID : : Variable Length ID :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 Extended Association ID Figure 4: IPv4 Extended Association ID Format
0 1 2 3 LSP Source Address
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 LSP Source Address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Variable Length ID :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv6 Extended Association ID IPv4 source address of the forward LSP [RFC3209].
LSP-ID
16-bits LSP-ID of the forward LSP [RFC3209].
Variable Length ID
Variable length ID inserted by the endpoint node of the associated
bidirectional LSP [RFC6780].
IPv6 Extended Association ID format is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 LSP Source Address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Variable Length ID :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 Extended Association ID Format
LSP Source Address LSP Source Address
IPv4/IPv6 source address of the forward LSP. IPv6 source address of the forward LSP [RFC3209].
LSP-ID LSP-ID
16-bits LSP-ID of the forward LSP. 16-bits LSP-ID of the forward LSP [RFC3209].
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.
7. Security Considerations 7. Security Considerations
This document uses 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 [GMPLS-FRR] and does not introduce any additional security
considerations other than already covered in [RFC7551], [GMPLS-FRR] considerations other than those already covered in [RFC7551], [GMPLS-
and the MPLS/GMPLS security framework [RFC5920]. FRR] and the MPLS/GMPLS security framework [RFC5920].
8. IANA Considerations 8. IANA Considerations
This document does not make any request for IANA action. 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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., 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.
[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
of a Record Route Object (RRO) Node-Id Sub-Object", RFC
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 Gandhi, R., Ed., "RSVP-TE
Extensions for Associated Bidirectional LSPs", RFC 7551, Extensions for Associated Bidirectional LSPs", RFC 7551,
May 2015. May 2015.
[GMPLS-FRR] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., [GMPLS-FRR] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z.,
Bhatia, M., "Extensions to Resource Reservation Protocol and M. Bhatia, "Extensions to Resource Reservation
For Fast Reroute of Traffic Engineering GMPLS LSPs", Protocol For Fast Reroute of Traffic Engineering GMPLS
draft-ietf-teas-gmpls-lsp-fastreroute, work in progress. LSPs", draft-ietf-teas-gmpls-lsp-fastreroute (work in
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 10, line 52 skipping to change at page 14, 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.
[GMPLS-REST] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., [RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z.,
Brzozowski, P., "RSVP-TE Signaling Procedure for End-to- Brzozowski, P., "RSVP-TE Signaling Procedure for End-to-
End GMPLS Restoration and Resource Sharing", draft-ietf- End GMPLS Restoration and Resource Sharing", RFC 8131,
teas-gmpls-resource-sharing-proc, work in progress. March 2017.
[PCE-ASSOC-BIDIR] Barth, C., Gandhi, R., and B. Wen, "PCEP
Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", draft-barth-pce-association-bidir (work in
progress).
Acknowledgments
A special thanks to the authors of [GMPLS-FRR], this document uses
the mechanisms defined in that document.
Authors' Addresses Authors' Addresses
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
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
EMail: jeremy.whittaker@verizon.com Email: jeremy.whittaker@verizon.com
 End of changes. 53 change blocks. 
182 lines changed or deleted 364 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/