doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc8537.txt b/doc/rfc/rfc8537.txt
new file mode 100644
index 0000000..ea0e0be
--- /dev/null
+++ b/doc/rfc/rfc8537.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    R. Gandhi, Ed.
+Request for Comments: 8537                           Cisco Systems, Inc.
+Updates: 4090, 7551                                              H. Shah
+Category: Standards Track                                          Ciena
+ISSN: 2070-1721                                             J. Whittaker
+                                                                 Verizon
+                                                           February 2019
+
+
+    Updates to the Fast Reroute Procedures for Co-routed Associated
+               Bidirectional Label Switched Paths (LSPs)
+
+Abstract
+
+   Resource Reservation Protocol (RSVP) association signaling can be
+   used to bind two unidirectional Label Switched Paths (LSPs) into an
+   associated bidirectional LSP.  When an associated bidirectional LSP
+   is co-routed, the reverse LSP follows the same path as its forward
+   LSP.  This document updates the fast reroute procedures defined in
+   RFC 4090 to support both single-sided and double-sided provisioned
+   associated bidirectional LSPs.  This document also updates the
+   procedure for associating two reverse LSPs defined in RFC 7551 to
+   support co-routed bidirectional LSPs.  The fast reroute procedures
+   can ensure that, for the co-routed LSPs, traffic flows on co-routed
+   paths in the forward and reverse directions after a failure event.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8537.
+
+
+
+
+
+
+
+
+
+
+
+
+Gandhi, et al.               Standards Track                    [Page 1]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+Copyright Notice
+
+   Copyright (c) 2019 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Assumptions and Considerations .............................4
+   2. Conventions Used in This Document ...............................4
+      2.1. Key Word Definitions .......................................4
+      2.2. Terminology ................................................4
+           2.2.1. Forward Unidirectional LSPs .........................5
+           2.2.2. Reverse Co-routed Unidirectional LSPs ...............5
+   3. Problem Statement ...............................................5
+      3.1. Fast Reroute Bypass Tunnel Assignment ......................6
+      3.2. Node Protection Bypass Tunnels .............................6
+      3.3. Bidirectional LSP Association at Midpoints .................7
+   4. Signaling Procedure .............................................8
+      4.1. Associated Bidirectional LSP Fast Reroute ..................8
+           4.1.1. Restoring Co-routing with Node Protection
+                  Bypass Tunnels ......................................9
+           4.1.2. Unidirectional Link Failures .......................10
+           4.1.3. Revertive Behavior after Fast Reroute ..............10
+           4.1.4. Bypass Tunnel Provisioning .........................10
+           4.1.5. One-to-One Bypass Tunnel ...........................11
+      4.2. Bidirectional LSP Association at Midpoints ................11
+   5. Compatibility ..................................................11
+   6. Security Considerations ........................................12
+   7. IANA Considerations ............................................12
+   8. References .....................................................12
+      8.1. Normative References ......................................12
+      8.2. Informative References ....................................13
+   Appendix A.  Extended Association ID ..............................14
+   Acknowledgments ...................................................16
+   Authors' Addresses ................................................16
+
+
+
+
+
+Gandhi, et al.               Standards Track                    [Page 2]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+1.  Introduction
+
+   The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION
+   Object is specified in [RFC6780] and can be used generically to
+   associate Multiprotocol Label Switching (MPLS) and Generalized MPLS
+   (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs).
+   [RFC7551] defines mechanisms for binding two point-to-point (P2P)
+   unidirectional LSPs [RFC3209] into an associated bidirectional LSP.
+   There are two models described in [RFC7551] for provisioning an
+   associated bidirectional LSP: single-sided and double-sided.  In both
+   models, the reverse LSP of the bidirectional LSP may or may not be
+   co-routed and follow the same path as its forward LSP.
+
+   In some packet transport networks, there are requirements where the
+   reverse LSP of a bidirectional LSP needs to follow the same path as
+   its forward LSP [RFC6373].  The MPLS Transport Profile (MPLS-TP)
+   [RFC6370] architecture facilitates the co-routed bidirectional LSP by
+   using GMPLS extensions [RFC3473] to achieve congruent paths.
+   However, RSVP association signaling allows enabling co-routed
+   bidirectional LSPs without having to deploy GMPLS extensions in the
+   existing networks.  The association signaling also allows taking
+   advantage of the existing TE and fast reroute mechanisms in the
+   network.
+
+   [RFC4090] defines fast reroute extensions for RSVP-TE LSPs, which are
+   also applicable to the associated bidirectional LSPs.  [RFC8271]
+   defines fast reroute procedures for GMPLS signaled bidirectional LSPs
+   such as coordinating bypass tunnel assignments in the forward and
+   reverse directions of the LSP.  The mechanisms defined in [RFC8271]
+   are also useful for the fast reroute of associated bidirectional
+   LSPs.
+
+   This document updates the fast reroute procedures defined in
+   [RFC4090] to support both single-sided and double-sided provisioned
+   associated bidirectional LSPs.  This document also updates the
+   procedure for associating two reverse LSPs defined in [RFC7551] to
+   support co-routed bidirectional LSPs.  The fast reroute procedures
+   can ensure that for the co-routed LSPs, traffic flows on co-routed
+   paths in the forward and reverse directions after fast reroute.
+
+
+
+
+
+
+
+
+
+
+
+
+Gandhi, et al.               Standards Track                    [Page 3]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+1.1.  Assumptions and Considerations
+
+   The following assumptions and considerations apply to this document:
+
+   o  The fast reroute procedure for the unidirectional LSPs is defined
+      in [RFC4090] and is not modified by this document.
+
+   o  The fast reroute procedure when using unidirectional bypass
+      tunnels is defined in [RFC4090] and is not modified by this
+      document.
+
+   o  This document assumes that the fast reroute bypass tunnels used
+      for protected associated bidirectional LSPs are also associated
+      bidirectional.
+
+   o  This document assumes that the fast reroute bypass tunnels used
+      for protected co-routed associated bidirectional LSPs are also co-
+      routed associated bidirectional.
+
+   o  The fast reroute procedure to coordinate the bypass tunnel
+      assignment defined in this document may be used for protected
+      associated bidirectional LSPs that are not co-routed 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.1.  Key Word Definitions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.2.  Terminology
+
+   The reader is assumed to be familiar with the terminology defined in
+   [RFC2205], [RFC3209], [RFC4090], [RFC7551], and [RFC8271].
+
+
+
+
+
+
+
+Gandhi, et al.               Standards Track                    [Page 4]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+2.2.1.  Forward Unidirectional LSPs
+
+   Two reverse unidirectional P2P LSPs are set up in 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 a REVERSE_LSP Object [RFC7551] 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 P2P LSPs are set up in opposite directions
+   between a pair of source and destination nodes to form an associated
+   bidirectional LSP.  A reverse unidirectional LSP originates on the
+   same node where the forward unidirectional LSP terminates, and it
+   terminates on the same node where the forward unidirectional LSP
+   originates.  A reverse co-routed unidirectional LSP traverses along
+   the same path as the forward-direction unidirectional LSP in the
+   opposite direction.
+
+3.  Problem Statement
+
+   As specified in [RFC7551], in the single-sided provisioning case, the
+   RSVP-TE tunnel is configured only on one endpoint node of the
+   bidirectional LSP.  An LSP for this tunnel is initiated by the
+   originating endpoint with the (Extended) ASSOCIATION Object
+   containing Association Type set to "Single-Sided Associated
+   Bidirectional LSP" and the REVERSE_LSP Object inserted in the RSVP
+   Path message.  The remote endpoint then creates the corresponding
+   reverse TE tunnel and signals the reverse LSP in response using the
+   information from the REVERSE_LSP Object and other objects present in
+   the received RSVP Path message.  As specified in [RFC7551], in the
+   double-sided provisioning case, the RSVP-TE tunnel is configured on
+   both endpoint nodes of the bidirectional LSP.  Both forward and
+   reverse LSPs are initiated independently by the two endpoints with
+   the (Extended) ASSOCIATION Object containing Association Type set to
+   "Double-Sided Associated Bidirectional LSP".  With both single-sided
+   and double-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 LSP.
+
+   Both single-sided and double-sided associated bidirectional LSPs
+   require solutions to the following issues for fast reroute to ensure
+   co-routing after a failure event.
+
+
+
+
+
+Gandhi, et al.               Standards Track                    [Page 5]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+3.1.  Fast Reroute Bypass Tunnel Assignment
+
+   In order to ensure that the traffic flows on a co-routed path after a
+   link or node failure on the protected co-routed LSP path, the
+   midpoint PLR nodes need to assign matching bidirectional bypass
+   tunnels for fast reroute.  Such bypass assignment requires
+   coordination between the PLR nodes in both the forward and reverse
+   directions when more than one bypass tunnel is present on a PLR node.
+
+                      <-- Bypass N -->
+                  +-----+         +-----+
+                  |  H  +---------+  I  |
+                  +--+--+         +--+--+
+                     |               |
+                     |               |
+          LSP1 -->   |   LSP1 -->    |   LSP1 -->       LSP1 -->
+   +-----+        +--+--+         +--+--+        +-----+        +-----+
+   |  A  +--------+  B  +----X----+  C  +--------+  D  +--------+  E  |
+   +-----+        +--+--+         +--+--+        +-----+        +-----+
+          <-- LSP2   |    <-- LSP2   |   <-- LSP2       <-- LSP2
+                     |               |
+                     |               |
+                  +--+--+         +--+--+
+                  |  F  +---------+  G  |
+                  +-----+         +-----+
+                      <-- Bypass S -->
+
+              Figure 1: Multiple Bidirectional Bypass Tunnels
+
+   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).
+   The midpoint PLR nodes B and C need to coordinate bypass tunnel
+   assignment to ensure that traffic in both directions flows through
+   either bypass tunnel N or bypass tunnel S after the link B-C failure.
+
+3.2.  Node Protection Bypass Tunnels
+
+   When using a node protection bypass tunnel with a protected
+   associated bidirectional 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.
+
+
+
+
+
+
+
+
+
+
+Gandhi, et al.               Standards Track                    [Page 6]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+              <-- 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 bypass tunnel
+   S (on path B-F-G-D) to reach downstream MP node D, whereas the
+   upstream PLR node C reroutes the protected reverse LSP2 traffic over
+   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 reverse directions flows
+   on different bypass tunnels, which can cause the co-routed associated
+   bidirectional LSP to be no longer co-routed.  However, unlike GMPLS
+   LSPs, the asymmetry of paths in the forward and reverse directions
+   does not result in RSVP soft-state timeout with the associated
+   bidirectional LSPs.
+
+3.3.  Bidirectional LSP Association at Midpoints
+
+   In packet transport networks, a restoration LSP is signaled after a
+   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
+   reverse LSPs of a co-routed associated bidirectional LSP may be
+   present at midpoint nodes with identical (Extended) ASSOCIATION
+   Objects.  This creates an ambiguity at midpoint nodes to identify the
+   correct associated LSP pair for fast reroute bypass assignment (e.g.,
+   during the recovery phase of the RSVP graceful restart procedure).
+
+
+
+
+
+
+
+Gandhi, et al.               Standards Track                    [Page 7]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+          LSP3 -->                       LSP3 -->       LSP3 -->
+          LSP1 -->       LSP1 -->        LSP1 -->       LSP1 -->
+   +-----+        +-----+         +-----+        +-----+        +-----+
+   |  A  +--------+  B  +----X----+  C  +--------+  D  +--------+  E  |
+   +-----+        +--+--+         +--+--+        +-----+        +-----+
+          <-- LSP2   |    <-- LSP2   |   <-- LSP2       <-- LSP2
+          <-- LSP4   |               |   <-- LSP4       <-- LSP4
+                     |               |
+                     |   LSP3 -->    |
+                  +--+--+         +--+--+
+                  |  F  +---------+  G  |
+                  +-----+         +-----+
+                      <-- Bypass S -->
+                          <-- LSP4
+
+            Figure 3: Restoration LSP Setup after Link Failure
+
+   As shown in Figure 3, the protected LSPs (LSP1 and LSP2) are an
+   associated LSP pair; similarly, the restoration LSPs (LSP3 and LSP4)
+   are an associated LSP pair.  Both pairs belong to the same associated
+   bidirectional LSP and carry identical (Extended) ASSOCIATION Objects.
+   In this example, the midpoint node D may mistakenly associate LSP1
+   with the reverse LSP4 instead of the reverse LSP2 due to the matching
+   (Extended) ASSOCIATION Objects.  This may cause the co-routed
+   associated bidirectional LSP to be no longer co-routed after fast
+   reroute.  Since the bypass assignment needs to be coordinated between
+   the forward and reverse LSPs, this can also lead to undesired bypass
+   tunnel assignments.
+
+4.  Signaling Procedure
+
+4.1.  Associated Bidirectional LSP Fast Reroute
+
+   For both single-sided and double-sided associated bidirectional LSPs,
+   the fast reroute procedure specified in [RFC4090] is used.  In
+   addition, the mechanisms defined in [RFC8271] are used as follows:
+
+   o  The BYPASS_ASSIGNMENT IPv4 subobject (value 38) and IPv6 subobject
+      (value 39) defined in [RFC8271] are used to coordinate bypass
+      tunnel assignment between the PLR nodes in both the forward and
+      reverse directions (see Figure 1).  The BYPASS_ASSIGNMENT and
+      Node-ID address [RFC4561] subobjects MUST be added by the
+      downstream PLR node in the RECORD_ROUTE Object (RRO) of the RSVP
+      Path message of the forward LSP to indicate the local bypass
+      tunnel assignment using the procedure defined in [RFC8271].  The
+      upstream node uses 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
+
+
+
+Gandhi, et al.               Standards Track                    [Page 8]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+      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 initiates the bypass tunnel assignment for
+      the forward LSP.  The upstream PLR (forward-direction LSP MP) node
+      reflects the associated bypass tunnel assignment for the reverse-
+      direction LSP.  The upstream PLR node MUST NOT initiate the bypass
+      tunnel assignment.
+
+   o  If the indicated forward bypass tunnel or the associated reverse
+      bypass tunnel is not found, the upstream PLR SHOULD send a Notify
+      message [RFC3473] with Error Code "FRR Bypass Assignment Error"
+      (value 44) and Sub-code "Bypass Tunnel Not Found" (value 1)
+      [RFC8271] to the downstream PLR.
+
+   o  If the bypass tunnel cannot be used as described in Section 4.5.3
+      of [RFC8271], the upstream PLR SHOULD send a Notify message
+      [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
+      reverse directions trigger fast reroute independently using the
+      procedures defined in [RFC4090] and send the forward and protected
+      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.  Restoring Co-routing with Node Protection Bypass Tunnels
+
+   After fast reroute, the downstream MP node assumes the role of
+   upstream PLR and reroutes the reverse LSP RSVP Path messages and
+   traffic over the bypass tunnel on which the forward LSP RSVP Path
+   messages and traffic are received.  This procedure is defined as
+   "restoring co-routing" in [RFC8271].  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
+   protected co-routed LSPs, asymmetry of paths can occur in the forward
+   and reverse directions after a link failure [RFC8271].  In order to
+   restore co-routing, the downstream MP node D (acting as an upstream
+   PLR) MUST trigger the procedure to restore co-routing and reroute the
+   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 upon receiving
+   the protected forward LSP modified RSVP Path messages and traffic
+
+
+
+Gandhi, et al.               Standards Track                    [Page 9]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+   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
+   reverse LSP2 from node D (resulting in RSVP soft-state timeout), and
+   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
+
+   The unidirectional link failures can cause co-routed associated
+   bidirectional LSPs to be no longer co-routed after fast reroute with
+   both link protection and node protection bypass tunnels.  However,
+   the unidirectional link failures in the upstream and/or downstream
+   directions do not result in RSVP soft-state timeout with the
+   associated bidirectional LSPs as upstream and downstream PLRs trigger
+   fast reroute independently.  The asymmetry of forward and reverse LSP
+   paths due to the unidirectional link failure in the downstream
+   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
+
+   When the revertive behavior is desired for a protected LSP after the
+   link is restored, the procedure defined in Section 6.5.2 of [RFC4090]
+   is followed.
+
+   o  The downstream PLR node starts sending the RSVP Path messages and
+      traffic flow of the protected forward LSP over the restored link
+      and stops sending them over the bypass tunnel [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  For node protection bypass tunnels (see Figure 2), after restoring
+      co-routing, the upstream PLR node D SHOULD start sending RSVP Path
+      messages and traffic for the reverse LSP over the original link
+      (C-D) when it receives the unmodified RSVP Path messages and
+      traffic for the protected forward LSP over it and stops sending
+      them over the bypass tunnel S (on path D-G-F-B).
+
+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
+
+
+
+
+Gandhi, et al.               Standards Track                   [Page 10]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+   LSPs that initiate the bypass tunnel assignments.  For single-sided
+   associated bypass tunnels, these nodes are the originating endpoints
+   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 4.5.2 of [RFC8271], in the 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 Midpoints
+
+   In order to associate the LSPs unambiguously at a midpoint node (see
+   Figure 3), the endpoint node MUST signal the Extended ASSOCIATION
+   Object and add a unique Extended Association ID for each associated
+   forward and reverse LSP pair forming the bidirectional LSP.  An
+   endpoint node MAY set the Extended Association ID to the value
+   formatted according to the structure shown in Appendix A.
+
+   o  For single-sided provisioned bidirectional LSPs [RFC7551], the
+      originating endpoint signals the Extended ASSOCIATION Object with
+      a unique Extended Association ID.  The remote endpoint copies the
+      contents of the received Extended ASSOCIATION Object including the
+      Extended Association ID in the RSVP Path message of the reverse
+      LSP's Extended ASSOCIATION Object.
+
+   o  For double-sided provisioned bidirectional LSPs [RFC7551], both
+      endpoints need to ensure that the bidirectional LSP has a unique
+      Extended ASSOCIATION Object for each forward and reverse LSP pair
+      by selecting appropriate unique Extended Association IDs signaled
+      by them.  A controller can be used to provision a unique Extended
+      Association ID on both endpoints.  The procedure for selecting
+      unique Extended Association IDs is outside the scope of this
+      document.
+
+5.  Compatibility
+
+   This document updates the procedures for fast reroute for associated
+   bidirectional LSPs defined in [RFC4090] and the procedures for
+   associating bidirectional LSPs defined in [RFC7551].  The procedures
+   use the signaling messages defined in [RFC8271]; no new signaling
+   messages are defined in this document.  The procedures ensure that
+   for the co-routed LSPs, traffic flows on co-routed paths in the
+
+
+
+Gandhi, et al.               Standards Track                   [Page 11]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+   forward and reverse directions after fast reroute.  Operators wishing
+   to use this function SHOULD ensure that it is supported on all the
+   nodes on the LSP path.  The nodes not supporting this function can
+   cause the traffic to flow on asymmetric paths in the forward and
+   reverse directions of the associated bidirectional LSPs after fast
+   reroute.
+
+6.  Security Considerations
+
+   This document updates the signaling mechanisms defined in [RFC4090]
+   and [RFC7551].  It does not introduce any additional security
+   considerations other than those already covered in [RFC4090],
+   [RFC7551], [RFC8271], and the MPLS/GMPLS security framework
+   [RFC5920].
+
+7.  IANA Considerations
+
+   This document has no IANA actions.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
+              September 1997, <https://www.rfc-editor.org/info/rfc2205>.
+
+   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
+              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
+              DOI 10.17487/RFC4090, May 2005,
+              <https://www.rfc-editor.org/info/rfc4090>.
+
+   [RFC4561]  Vasseur, J., Ed., Ali, Z., and S. Sivabalan, "Definition
+              of a Record Route Object (RRO) Node-Id Sub-Object",
+              RFC 4561, DOI 10.17487/RFC4561, June 2006,
+              <https://www.rfc-editor.org/info/rfc4561>.
+
+   [RFC6780]  Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
+              ASSOCIATION Object Extensions", RFC 6780,
+              DOI 10.17487/RFC6780, October 2012,
+              <https://www.rfc-editor.org/info/rfc6780>.
+
+
+
+
+Gandhi, et al.               Standards Track                   [Page 12]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+   [RFC7551]  Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
+              Extensions for Associated Bidirectional Label Switched
+              Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
+              <https://www.rfc-editor.org/info/rfc7551>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8271]  Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and
+              M. Bhatia, "Updates to the Resource Reservation Protocol
+              for Fast Reroute of Traffic Engineering GMPLS Label
+              Switched Paths (LSPs)", RFC 8271, DOI 10.17487/RFC8271,
+              October 2017, <https://www.rfc-editor.org/info/rfc8271>.
+
+8.2.  Informative References
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+              <https://www.rfc-editor.org/info/rfc3209>.
+
+   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Resource ReserVation Protocol-
+              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
+              DOI 10.17487/RFC3473, January 2003,
+              <https://www.rfc-editor.org/info/rfc3473>.
+
+   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
+              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
+              <https://www.rfc-editor.org/info/rfc5920>.
+
+   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
+              Profile (MPLS-TP) Identifiers", RFC 6370,
+              DOI 10.17487/RFC6370, September 2011,
+              <https://www.rfc-editor.org/info/rfc6370>.
+
+   [RFC6373]  Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar,
+              N., Ed., and E. Gray, Ed., "MPLS Transport Profile (MPLS-
+              TP) Control Plane Framework", RFC 6373,
+              DOI 10.17487/RFC6373, September 2011,
+              <https://www.rfc-editor.org/info/rfc6373>.
+
+   [RFC8131]  Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and
+              P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End
+              GMPLS Restoration and Resource Sharing", RFC 8131,
+              DOI 10.17487/RFC8131, March 2017,
+              <https://www.rfc-editor.org/info/rfc8131>.
+
+
+
+Gandhi, et al.               Standards Track                   [Page 13]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+Appendix A.  Extended Association ID
+
+   The Extended Association ID in the Extended ASSOCIATION Object
+   [RFC6780] can be set to the value formatted according to the
+   structure shown in the following example to uniquely identify
+   associated forward and reverse LSP pairs of an associated
+   bidirectional LSP.
+
+   An example of the IPv4 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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                    IPv4 LSP Source Address                    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |           Reserved            |            LSP ID             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     :                                                               :
+     :                      Variable Length ID                       :
+     :                                                               :
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+           Figure 4: IPv4 Extended Association ID Format Example
+
+   IPv4 LSP Source Address
+
+      IPv4 source address of the forward LSP [RFC3209].
+
+   LSP ID
+
+      16-bit LSP ID of the forward LSP [RFC3209].
+
+   Variable Length ID
+
+      Variable length Extended Association ID [RFC6780] inserted by the
+      endpoint node of the associated bidirectional LSP [RFC7551].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gandhi, et al.               Standards Track                   [Page 14]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+   An example of the 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 Example
+
+   LSP Source Address
+
+      IPv6 source address of the forward LSP [RFC3209].
+
+   LSP ID
+
+      16-bit LSP ID of the forward LSP [RFC3209].
+
+   Variable Length ID
+
+      Variable length Extended Association ID [RFC6780] inserted by the
+      endpoint node of the associated bidirectional LSP [RFC7551].
+
+   In both IPv4 and IPv6 examples, the Reserved flags MUST be set to 0
+   on transmission.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gandhi, et al.               Standards Track                   [Page 15]
+
+RFC 8537        Associated Bidirectional LSP Fast Reroute  February 2019
+
+
+Acknowledgments
+
+   A special thanks to the authors of [RFC8271]; this document uses the
+   signaling mechanisms defined in that document.  The authors would
+   also like to thank Vishnu Pavan Beeram, Daniele Ceccarelli, Deborah
+   Brungard, Adam Roach, and Benjamin Kaduk for reviewing this document
+   and providing valuable comments.
+
+Authors' Addresses
+
+   Rakesh Gandhi (editor)
+   Cisco Systems, Inc.
+   Canada
+
+   Email: rgandhi@cisco.com
+
+
+   Himanshu Shah
+   Ciena
+
+   Email: hshah@ciena.com
+
+
+   Jeremy Whittaker
+   Verizon
+
+   Email: jeremy.whittaker@verizon.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gandhi, et al.               Standards Track                   [Page 16]
+