TEAS Working Group                                        R. Gandhi, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended Status: Standards Track                                 H. Shah
Expires: September 11, 2017                                        Ciena
                                                        Jeremy Whittaker
                                                                 Verizon
                                                          March 10, 2017


      Fast Reroute Procedures For Associated Bidirectional Label
                         Switched Paths (LSPs)
            draft-gandhishah-teas-assoc-corouted-bidir-04


Abstract

   Resource Reservation Protocol (RSVP) association signaling can be
   used to bind two unidirectional 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
   describes Fast Reroute (FRR) procedures for both single-sided and
   double-sided provisioned associated bidirectional LSPs.  The FRR
   procedures are applicable to co-routed and non co-routed LSPs.  For
   co-routed LSPs, the FRR procedures can ensure that traffic flows on
   co-routed paths in the forward and reverse directions after a failure
   event.


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the



Gandhi, et al.         Expires September 11, 2017               [Page 1]


Internet-Draft   FRR For Associated Bidirectional LSPs    March 10, 2017


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
     2.1.  Key Word Definitions . . . . . . . . . . . . . . . . . . .  3
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
       2.2.1.  Reverse Co-routed Unidirectional LSPs  . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Fast Reroute Bypass Tunnel Assignment  . . . . . . . . . .  4
     3.2.  Bidirectional LSP Association At Mid-Points  . . . . . . .  5
   4.  Signaling Procedure  . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Bidirectional LSP Fast Reroute . . . . . . . . . . . . . .  6
     4.2.  Bidirectional LSP Association At Mid-points  . . . . . . .  7
   5.  Message and Object Definitions . . . . . . . . . . . . . . . .  7
     5.1.  Extended ASSOCIATION Object  . . . . . . . . . . . . . . .  7
   6.  Compatibility  . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11











Gandhi, et al.         Expires September 11, 2017               [Page 2]


Internet-Draft   FRR For Associated Bidirectional LSPs    March 10, 2017


1.  Introduction

   The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION
   Object is specified in [RFC6780] which can be used generically to
   associate (G)Multi-Protocol Label Switching (MPLS) Label Switched
   Paths (LSPs).  [RFC7551] defines mechanisms for binding two point-to-
   point 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.

   [GMPLS-FRR] defines Fast Reroute (FRR) procedure for GMPLS signaled
   LSPs to co-ordinate bypass tunnel assignments in the forward and
   reverse directions.  The mechanisms defined in [GMPLS-FRR] are
   applicable to FRR of associated bidirectional LSPs.

   In 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 (TP) [RFC6370]
   architecture facilitates the co-routed bidirectional LSP by using the
   GMPLS extensions [RFC3473] to achieve congruent paths.  However, the
   RSVP association signaling allows to enable co-routed bidirectional
   LSPs without having to deploy GMPLS extensions in the existing
   networks.  The association signaling also allows to take advantage of
   the existing Traffic Engineering (TE) and FRR mechanisms in the
   network.

   This document describes FRR procedures for both single-sided and
   double-sided provisioned associated bidirectional LSPs.  The FRR
   procedures are applicable to co-routed and non co-routed LSPs.  For
   co-routed LSPs, the FRR procedures can ensure that traffic flows on
   co-routed paths in the forward and reverse directions after a failure
   event.


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", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.2.  Terminology

   The reader is assumed to be familiar with the terminology in
   [RFC2205], [RFC3209], [RFC4090] and [RFC7551].



Gandhi, et al.         Expires September 11, 2017               [Page 3]


Internet-Draft   FRR For Associated Bidirectional LSPs    March 10, 2017


2.2.1.  Reverse Co-routed 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.  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 of the forward direction
   unidirectional LSP in the opposite direction.


3.  Overview

   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 (Extended) ASSOCIATION Object containing
   Association Type set to "single-sided associated bidirectional LSP"
   and REVERSE_LSP Object inserted in the 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 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 (Extended) ASSOCIATION Object
   containing Association Type set to "double-sided associated
   bidirectional LSP".  In 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.

   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
   require solutions to the following issues for fast reroute.

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 LSP path, the mid-point Point



Gandhi, et al.         Expires September 11, 2017               [Page 4]


Internet-Draft   FRR For Associated Bidirectional LSPs    March 10, 2017


   of Local Repair (PLR) nodes need to assign matching bidirectional
   bypass tunnels for fast reroute.  Even for a non co-routed
   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
   direction PLR nodes when more than one bypass tunnels are 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
   N on path B-H-I-C and Bypass S on path B-F-G-C.  The mid-point PLR
   nodes B and C need to co-ordinate bypass tunnel assignment to ensure
   that traffic in both directions flow through either on the Bypass N
   path B-H-I-C or the Bypass S path B-F-G-C, after the link B-C
   failure.

3.2.  Bidirectional LSP Association At Mid-Points

   In packet transport networks, a restoration LSP is signaled after a
   link failure on the protected LSP and the protected LSP may or may
   not be torn down [GMPLS-REST].  In this case, multiple forward and
   reverse LSPs of a bidirectional LSP may be present at mid-point nodes
   with identical (Extended) ASSOCIATION Objects.  This creates an
   ambiguity at mid-point nodes to identify the correct associated LSP
   pair for fast reroute bypass assignment (e.g. during the recovery
   phase of RSVP graceful restart procedure).





Gandhi, et al.         Expires September 11, 2017               [Page 5]


Internet-Draft   FRR For Associated Bidirectional LSPs    March 10, 2017


          LSP3 -->                        LSP3 -->       LSP3 -->
          LSP1 -->        LSP1 -->        LSP1 -->       LSP1 -->
   +----+         +-----+         +-----+         +----+         +----+
   | A  +---------+  B  +----X----+  C  +---------+ D  +---------+ E  |
   +----+         +--+--+         +--+--+         +----+         +----+
          <-- LSP2   |    <-- LSP2   |    <-- LSP2       <-- LSP2
          <-- LSP4   |               |    <-- LSP4       <-- LSP4
                     |               |
                     |    LSP3 -->   |
                  +--+--+         +--+--+
                  |  F  +---------+  G  |
                  +-----+         +-----+
                          <-- LSP4

       Figure 2: Restoration LSP Set-up After Link Failure

   As shown in Figure 2, protected LSPs LSP1 and LSP2 are an associated
   LSP pair, similarly 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,
   mid-point node D may mistakenly associate LSP1 with reverse LSP4
   instead of reverse LSP3 due to the matching (Extended) ASSOCIATION
   Objects.  This may cause the bidirectional LSP to become non co-
   routed.  Since a reverse LSP reflects the bypass tunnel assignment
   received in the forward LSP, this can also lead to undesired bypass
   tunnel assignments.


4.  Signaling Procedure

4.1.  Bidirectional LSP Fast Reroute

   The mechanisms defined in [GMPLS-FRR] are used for fast reroute of
   both single-sided and double-sided associated bidirectional LSPs as
   following.

   o  As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject is
      signaled in the RRO of the Path message to co-ordinate bypass
      tunnel assignment between the forward and reverse direction PLR
      nodes.  A BYPASS_ASSIGNMENT subobject MUST be added by the forward
      direction PLR node in the Path message of the forward LSP to
      indicate the bypass tunnel assigned.

   o  The forward direction PLR node always initiates the bypass tunnel
      assignment for the forward LSP.  The reverse direction PLR
      (forward direction LSP Merge Point (MP)) node simply reflects the
      bypass tunnel assignment for the reverse direction LSP.




Gandhi, et al.         Expires September 11, 2017               [Page 6]


Internet-Draft   FRR For Associated Bidirectional LSPs    March 10, 2017


   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].

   o  When using a node protection bypass tunnel, asymmetry of paths can
      occur in the forward and reverse directions of the bidirectional
      LSP after a link failure when using co-routed LSPs [GMPLS-FRR].
      This can be corrected using the re-corouting procedure defined in
      [GMPLS-FRR].  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.

4.2.  Bidirectional LSP Association At Mid-points

   In order to associate the correct LSPs at a mid-point node, an
   endpoint node MUST signal Extended ASSOCIATION Object and add unique
   Extended Association ID for each associated forward and reverse LSP
   pair forming the bidirectional LSP.  As an example, an endpoint node
   MAY set the Extended Association ID to the value specified in Section
   5.1 of this document.

   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 provisioning appropriate Extended Association IDs signaled by
      them.


5.  Message and Object Definitions

5.1.  Extended ASSOCIATION Object

   The Extended Association ID in the Extended ASSOCIATION Object can be
   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 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                    |



Gandhi, et al.         Expires September 11, 2017               [Page 7]


Internet-Draft   FRR For Associated Bidirectional LSPs    March 10, 2017


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |            LSP-ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                      Variable Length ID                       :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: IPv4 Extended Association ID


        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 4: IPv6 Extended Association ID


   LSP Source Address

      IPv4/IPv6 source address of the forward LSP.

   LSP-ID

      16-bits LSP-ID of the forward LSP.

   Variable Length ID

      Variable length ID inserted by the endpoint node of the associated
      bidirectional LSP [RFC6780].


6.  Compatibility




Gandhi, et al.         Expires September 11, 2017               [Page 8]


Internet-Draft   FRR For Associated Bidirectional LSPs    March 10, 2017


   This document describes the procedures for fast reroute for
   associated bidirectional LSPs.  Operators wishing to use this
   function SHOULD ensure that it is supported on the nodes on the LSP
   path.


7.  Security Considerations

   This document uses signaling mechanisms defined in [RFC7551] and
   [GMPLS-FRR] and does not introduce any additional security
   considerations other than already covered in [RFC7551], [GMPLS-FRR]
   and the MPLS/GMPLS security framework [RFC5920].


8.  IANA Considerations

   This document does not make any request for IANA action.


































Gandhi, et al.         Expires September 11, 2017               [Page 9]


Internet-Draft   FRR For Associated Bidirectional LSPs    March 10, 2017


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              May 2005.

   [RFC6780]  Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
              Association Object Extensions", RFC 6780, October 2012.

   [RFC7551]  Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE
              Extensions for Associated Bidirectional LSPs", RFC 7551,
              May 2015.

   [GMPLS-FRR]  Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z.,
              Bhatia, M., "Extensions to Resource Reservation Protocol
              For Fast Reroute of Traffic Engineering GMPLS LSPs",
              draft-ietf-teas-gmpls-lsp-fastreroute, work in progress.

9.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, December 2001.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
              Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.

   [RFC6373]  Andersson, L., Berger, L., Fang, L., Bitar, N., and E.
              Gray, "MPLS Transport Profile (MPLS-TP) Control Plane
              Framework", RFC 6373, September 2011.

   [GMPLS-REST]  Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z.,



Gandhi, et al.         Expires September 11, 2017              [Page 10]


Internet-Draft   FRR For Associated Bidirectional LSPs    March 10, 2017


              Brzozowski, P., "RSVP-TE Signaling Procedure for End-to-
              End GMPLS Restoration and Resource Sharing", draft-ietf-
              teas-gmpls-resource-sharing-proc, work in progress.



Authors' Addresses

   Rakesh Gandhi (editor)
   Cisco Systems, Inc.

   EMail: rgandhi@cisco.com


   Himanshu Shah
   Ciena

   EMail: hshah@ciena.com


   Jeremy Whittaker
   Verizon

   EMail: jeremy.whittaker@verizon.com



























Gandhi, et al.         Expires September 11, 2017              [Page 11]