Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Rakesh Gandhi , Himanshu C. Shah , Jeremy Whittaker
Last updated 2017-02-14
Replaces draft-gandhi-shah-teas-assoc-corouted-bidir
Replaced by draft-ietf-teas-assoc-corouted-bidir-frr, draft-ietf-teas-assoc-corouted-bidir-frr, draft-ietf-teas-assoc-corouted-bidir-frr, RFC 8537
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-gandhishah-teas-assoc-corouted-bidir-03
TEAS Working Group                                        R. Gandhi, Ed.
Internet-Draft                                             Cisco Systems
Intended Status: Standards Track                                 H. Shah
Expires: August 18, 2017                                           Ciena
                                                        Jeremy Whittaker
                                                                 Verizon
                                                       February 14, 2017

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

Abstract

   Resource Reservation Protocol (RSVP) association signaling can be
   used to bind two unidirectional LSPs into an associated bidirectional
   LSP.  In packet transport networks, there are requirements where the
   reverse unidirectional LSP of an associated bidirectional LSP needs
   to follow the same path as its forward unidirectional LSP.  In
   addition, the associated bidirectional LSP needs to maintain
   co-routed-ness even after a failure event in the network.  This
   document describes fast reroute procedures for associated
   bidirectional LSPs that ensure the traffic flows on a co-routed path
   after a failure event for single-sided provisioning model.

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 August 18, 2017                 [Page 1]
Internet-Draft    FRR For Co-routed Bidirectional LSP  February 14, 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.  Co-routed Bidirectional LSP Association  . . . . . . . . .  4
     3.2.  Fast Reroute Bypass Tunnel Assignment  . . . . . . . . . .  5
   4.  Signaling Procedure  . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Co-routed Bidirectional LSP Association  . . . . . . . . .  6
     4.2.  Fast Reroute For Associated Co-routed Bidirectional LSP  .  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 August 18, 2017                 [Page 2]
Internet-Draft    FRR For Co-routed Bidirectional LSP  February 14, 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 this
   document, only the single-sided provisioned associated bidirectional
   LSPs are considered for co-routed-ness.

   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) mechanisms in the network.

   In packet transport networks, there are requirements where the
   reverse LSP of an associated bidirectional LSP needs to follow the
   same path as its forward LSP [RFC6373].  In addition, the associated
   bidirectional LSP needs to maintain co-routed-ness even after a
   failure event in the network.

   [GMPLS-FRR] defines fast reroute procedure for GMPLS signaled LSPs to
   co-ordinate bypass tunnel assignments in the forward and reverse
   directions.  The mechanisms defined in [GMPLS-FRR] can be used for
   fast reroute of the associated bidirectional LSPs.

   This document describes fast reroute procedures for associated
   co-routed bidirectional LSPs to ensure the traffic flows on the
   co-routed path in the forward and reverse direction of the LSP 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
 

Gandhi, et al.          Expires August 18, 2017                 [Page 3]
Internet-Draft    FRR For Co-routed Bidirectional LSP  February 14, 2017

   [RFC2205], [RFC3209], [RFC7551], and [RFC4090].

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.  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.  The reverse LSP thus created may or may
   not be congruent and follow the same path as its forward LSP. 

   The single-sided associated co-routed bidirectional LSP signaled
   using the mechanisms defined in [RFC7551] requires solutions for the
   following issues for fast reroute to ensure co-routed-ness.  

3.1.  Co-routed Bidirectional LSP Association

   Multiple forward and reverse LSPs of a bidirectional LSP may be
   present at mid-point nodes with identical (Extended) ASSOCIATION
   Objects.  For example, this can occur while RSVP states are timing
   out after fast reroute, or during recovery phase in RSVP graceful
   restart.  This creates an ambiguity at mid-point nodes to identify
   the correct associated LSP pair for fast reroute bypass assignment.

 

Gandhi, et al.          Expires August 18, 2017                 [Page 4]
Internet-Draft    FRR For Co-routed Bidirectional LSP  February 14, 2017

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

    Figure 1: Multiple LSPs with Matching (Extended) ASSOCIATION Object

   As shown in Figure 1, LSP1 and LSP2 are an associated co-routed LSP
   pair, similarly LSP3 and LSP4 are an associated co-routed LSP pair,
   both pairs belong to the same associated bidirectional LSP and carry
   identical (Extended) ASSOCIATION Objects.  In this example, mid-point
   nodes B and C may mistakenly associate LSP1 with non co-routed
   reverse LSP4 instead of co-routed reverse LSP3 due to the matching
   (Extended) ASSOCIATION Objects.

3.2.  Fast Reroute Bypass Tunnel Assignment

   In order to ensure that the traffic flows on the co-routed path after
   a link or node failure on the LSP path, the mid-point Point of Local
   Repair (PLR) nodes need to assign correct bidirectional co-routed
   bypass tunnels for fast reroute.  Such bypass assignment requires
   co-ordination between the forward and reverse direction PLR nodes
   when more than one bypass tunnels are present on a node.

                        +-----+           +-----+
                        |  G  +-----------+  H  |
                        +--+--+           +--+--+
                           |                 |
                           |                 |
               LSP1 -->    |     LSP1 -->    |     LSP1 -->
      +-----+           +--+--+           +--+--+           +-----+
      |  A  +-----------+  B  +-----------+  C  +-----------+  D  |
      +-----+           +--+--+           +--+--+           +-----+
               <-- LSP2    |     <-- LSP2    |     <-- LSP2
                           |                 |
                           |                 |
                        +--+--+           +--+--+
                        |  E  +-----------+  F  |
                        +-----+           +-----+
 

Gandhi, et al.          Expires August 18, 2017                 [Page 5]
Internet-Draft    FRR For Co-routed Bidirectional LSP  February 14, 2017

            Figure 2: Multiple Bidirectional Bypass Tunnels

   As shown in Figure 2, there are two bypass tunnels available, one on
   path B-G-H-C and other on path B-E-F-C.  In order to ensure co-
   routed-ness, 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 path B-G-H-C or path B-E-F-C, after the link
   B-C failure.

4.  Signaling Procedure

4.1.  Co-routed Bidirectional LSP Association

   In order to ensure co-routed-ness, Extended ASSOCIATION Object is
   used in the RSVP Path message using the procedures defined in
   [RFC7551] as following.

   o  The originating head-end node MUST add Extended ASSOCIATION Object
      with Association Type set to "single-sided associated
      bidirectional LSP" and unique Extended Association ID for each
      associated forward and reverse LSP pair forming the bidirectional
      LSP.  As an example, a node MAY set the Extended Association ID to
      the values specified in Section 5.1 of this document.  As
      specified in [RFC7551], 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  The originating head-end node MUST add an EXPLICIT_ROUTE Object
      (ERO) in the REVERSE_LSP Object by using the hops traversed by the
      forward LSP in the reverse order to ensure that reverse LSP
      follows the same path as forward direction LSP in the opposite
      direction.  As specified in [RFC7551], the remote endpoint builds
      the ERO of the reverse LSP using the ERO from the received
      REVERSE_LSP Object of the forward LSP.

   o  When an ERO contains one or more loose next-hop(s), the
      originating head-end MUST add RECORD_ROUTE Object (RRO) in the
      Path message of the forward LSP to record the hops traversed by
      the LSP.  The remote endpoint SHOULD use the recorded hops from
      the RRO in the forward LSP to expand the loose next-hop(s), to
      ensure that the reverse LSP follows the same path as the forward
      LSP.

 

Gandhi, et al.          Expires August 18, 2017                 [Page 6]
Internet-Draft    FRR For Co-routed Bidirectional LSP  February 14, 2017

4.2.  Fast Reroute For Associated Co-routed Bidirectional LSP

   The mechanisms defined in [GMPLS-FRR] can be used for associated
   co-routed bidirectional LSP to ensure the traffic flows on a
   co-routed path in the forward and reverse directions after a link or
   node failure 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 originating LSP to
      indicate the bypass tunnel assigned.

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

   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 [GMPLS-FRR].  This is corrected using the
      re-corouting procedure defined in [GMPLS-FRR].  Unlike GMPLS LSPs,
      the asymmetry of paths does not result in RSVP soft-state time-out
      with the associated bidirectional LSPs.

5.  Message and Object Definitions

5.1.  Extended ASSOCIATION Object

   The Extended Association ID in the Extended ASSOCIATION Object can be
   set by the originating node to the value specified as following when
   the associated bidirectional LSP is co-routed.

       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
 

Gandhi, et al.          Expires August 18, 2017                 [Page 7]
Internet-Draft    FRR For Co-routed Bidirectional LSP  February 14, 2017

      :                      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 originating LSP.

   LSP-ID 

      16-bits LSP-ID of the originating LSP.

   Variable Length ID

      Variable length ID inserted by the originating node of the
      Associated co-routed bidirectional LSP.

6.  Compatibility

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

Gandhi, et al.          Expires August 18, 2017                 [Page 8]
Internet-Draft    FRR For Co-routed Bidirectional LSP  February 14, 2017

   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 August 18, 2017                 [Page 9]
Internet-Draft    FRR For Co-routed Bidirectional LSP  February 14, 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.

 

Gandhi, et al.          Expires August 18, 2017                [Page 10]
Internet-Draft    FRR For Co-routed Bidirectional LSP  February 14, 2017

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 August 18, 2017                [Page 11]