    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]