[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-gandhi-shah-teas-assoc-corouted-bidir) 00 01 02 03 04 draft-ietf-teas-assoc-corouted-bidir-frr

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


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


Abstract

   In packet transport networks, there are requirements where reverse
   unidirectional LSP of a bidirectional LSP needs to follow the same
   path as its forward unidirectional LSP.  The bidirectional LSP needs
   to maintain co-routed-ness even after a failure event in the network.
    This document describes RSVP signaling to unambiguously bind two co-
   routed point-to-point LSPs into an associated co-routed bidirectional
   LSP.  Fast-reroute procedures are defined to ensure that the traffic
   flows on the co-routed path 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) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Gandhi, et al.           Expires March 14, 2017                 [Page 1]


Internet-Draft    FRR For Co-routed Bidirectional LSP September 10, 2016


   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.  Reverse Co-routed Unidirectional LSPs  . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Message and Object Definitions . . . . . . . . . . . . . . . .  6
     4.1.  Extended ASSOCIATION Object  . . . . . . . . . . . . . . .  6
   5.  Signaling Procedure  . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Co-routed Bidirectional LSP Association  . . . . . . . . .  7
     5.2.  Fast-Reroute For Associated Co-routed Bidirectional LSP  .  8
   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 March 14, 2017                 [Page 2]


Internet-Draft    FRR For Co-routed Bidirectional LSP September 10, 2016


1.  Introduction

   In packet transport networks, there are requirements where a reverse
   Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) of a
   bidirectional LSP needs to follow the same path as its forward LSP
   [RFC6373].  The bidirectional LSP needs to maintain co-routed-ness
   even after a failure event in the network.

   The Resource Reservation Protocol (RSVP) Extended ASSOCIATION Object
   is specified in [RFC6780] which can be used generically to associate
   (G)MPLS LSPs.  [RFC7551] defines mechanisms for binding two point-to-
   point unidirectional LSPs [RFC3209] into an associated bidirectional
   LSP.  There are two models described for provisioning the
   bidirectional LSP, single-sided and double-sided.  Only the single-
   sided provisioned bidirectional LSPs are considered in this document
   for providing fast-reroute for the co-routed bidirectional LSPs.

   The MPLS Transport Profile (TP) [RFC6370] architecture facilitates
   the co-routed bidirectional LSP by using 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.

   [GMPLS-FRR] defines fast-reroute procedures for GMPLS signaled LSPs
   to ensure traffic flows on a co-routed path after a failure event on
   the LSP path.  [GMPLS-FRR] defined fast-reroute mechanisms are
   equally applicable to the associated co-routed bidirectional LSPs.

   This document describes how Extended ASSOCIATION Object can be used
   to unambiguously bind two reverse co-routed unidirectional LSPs into
   an associated co-routed bidirectional LSP in the single-sided
   provisioning case.  Fast-reroute procedures are defined to ensure the
   traffic flows on the co-routed path 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.  Reverse Co-routed Unidirectional LSPs

   Two reverse unidirectional point-to-point (P2P) LSPs are setup in the



Gandhi, et al.           Expires March 14, 2017                 [Page 3]


Internet-Draft    FRR For Co-routed Bidirectional LSP September 10, 2016


   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 Traffic Engineering (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.


               LSP1 -->         LSP1 -->           LSP1 -->
      +-----+           +-----+           +-----+           +-----+
      |  A  +-----------+  B  +-----------+  C  |-----------+  D  |
      +-----+           +-----+           +-----+           +-----+
              <-- LSP2          <-- LSP2           <-- LSP2

      Figure 1a: An Example of Associated Co-routed Bidirectional LSP


   As shown in Figure 1a, LSP1 is provisioned on the originating
   endpoint A.  The creation of reverse LSP2 on the remote endpoint D is
   triggered by the LSP1.  LSP2 follows the path in the reverse
   direction using the EXPLICIT_ROUTE Object (ERO) from the received
   REVERSE_LSP Object in the Path message of LSP1 [RFC7551].

   For co-routed bidirectional LSP, the originating endpoint A can
   ensure that the reverse LSP follows the same path as the forward LSP
   (e.g. A-B-C-D) by populating the ERO in the REVERSE_LSP Object using
   the hops traversed by the forward LSP in the reverse order (e.g. D-C-
   B-A).

   For fast-reroute, the associated co-routed bidirectional LSP signaled
   using mechanisms defined in [RFC7551] requires solutions for the
   following issues:



Gandhi, et al.           Expires March 14, 2017                 [Page 4]


Internet-Draft    FRR For Co-routed Bidirectional LSP September 10, 2016


   o  Multiple forward and reverse LSPs of a bidirectional LSP may be
   present at mid-point nodes with identical Extended ASSOCIATION
   Objects.  As examples, this can happen while RSVP states are timing
   out, during recovery phase in RSVP graceful restart, etc.  This
   creates an ambiguity at mid-point nodes to identify the correct
   associated LSP pair that can lead to undesirable fast-reroute bypass
   assignment.

   As shown in Figure 1b, 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.

   In order to ensure co-routed-ness, the mid-point nodes must
   unambiguously identify the correct matching co-routed associated
   forward and reverse LSP pair.  To ensure this, the Extended
   ASSOCIATION Object needs to be unique per associated co-routed
   forward and reverse LSP pair.


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

   Figure 1b: Example of LSPs with matching Extended ASSOCIATION Objects

   o  The ERO for the reverse LSP signaled by the originating endpoint
   may contain loose next-hop(s) in case of loosely routed LSPs (e.g.
   inter-domain LSPs).  For co-routed bidirectional LSP, the mid-point
   and endpoint nodes need to ensure that the loose next-hop expansion
   for the reverse LSP is on the co-routed path as its forward LSP.  To
   achieve this, the expanding node may require the recorded path of the
   forward LSP.

   o  In order to ensure that the traffic flows on the co-routed path



Gandhi, et al.           Expires March 14, 2017                 [Page 5]


Internet-Draft    FRR For Co-routed Bidirectional LSP September 10, 2016


   after a link or node failure on the LSP path, the mid-point Point of
   Local Repair (PLR) nodes need to identify the correct matching pair
   and know that it is co-routed.  This way PLR nodes can assign
   bidirectional co-routed bypass tunnels for fast-reroute.  Such bypass
   assignment requires co-ordination between the forward and reverse
   direction PLR nodes.


4.  Message and Object Definitions

4.1.  Extended ASSOCIATION Object

   The Extended ASSOCIATION Object is populated using the rules defined
   in [RFC7551] for the Association Type "single-sided associated
   bidirectional LSP".

   The Extended Association ID is 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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                  Variable Length Extended ID                  :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: IPv4 Extended Association ID Format



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



Gandhi, et al.           Expires March 14, 2017                 [Page 6]


Internet-Draft    FRR For Co-routed Bidirectional LSP September 10, 2016


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

                Figure 3: IPv6 Extended Association ID Format



   LSP Source Address

      IPv4/IPv6 source address of the originating LSP.

   LSP-ID

      16-bits LSP-ID of the originating LSP.

   Variable Length Extended ID

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


5.  Signaling Procedure

5.1.  Co-routed Bidirectional LSP Association

   In general, the processing rules for the Extended ASSOCIATION Object
   as specified in [RFC6780] and [RFC7551] are followed for co-routed
   bidirectional LSP association.

   The originating head-end node MUST add Extended ASSOCIATION Object
   with Association Type set to "single-sided associated bidirectional
   LSP" and the Extended Association ID set to the values specified in
   Section 4.1 of this document in the RSVP Path message.  The Extended
   Association ID thus added allows to identify each associated LSP pair
   of the associated co-routed bidirectional LSP.  The presence of
   Extended Association ID in this format indicates the nodes on the LSP
   path that the bidirectional LSP is co-routed.  In addition, the
   originating head-end node MUST add 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.  When the ERO
   contains one or more loose next-hop(s), the originating endpoint MUST
   add RECORD_ROUTE Object (RRO) in the Path message of the forward LSP
   to record the hops traversed by the LSP.



Gandhi, et al.           Expires March 14, 2017                 [Page 7]


Internet-Draft    FRR For Co-routed Bidirectional LSP September 10, 2016


   As defined in [RFC7551], the remote endpoint simply copies the
   contents of the received Extended ASSOCIATION Object including the
   Extended Association ID in the Path message of the reverse LSP's
   Extended ASSOCIATION Object.  In addition, the remote endpoint builds
   the ERO of the reverse LSP using the ERO from the received
   REVERSE_LSP Object of the forward LSP.  If ERO contains one or more
   loose next-hop(s), 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.

   As contents of the Extended ASSOCIATION Objects are unique for each
   associated LSP pair of the associated co-routed bidirectional LSP, a
   mid-point node can unambiguously identify the associated LSP pair by
   matching their Extended ASSOCIATION Objects.  When a mid-point node
   needs to expand the loose next-hop in the ERO, it SHOULD use the
   recorded hops from the RRO in the forward LSP to ensure that the
   reverse LSP is co-routed and follows the same path as its forward
   LSP.


5.2.  Fast-Reroute For Associated Co-routed Bidirectional LSP

   The procedures defined in [GMPLS-FRR] are used for associated
   co-routed bidirectional LSP to ensure that the traffic flows on a
   co-routed path after a link or node failure.

   As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject in the RRO
   is signaled to co-ordinate bypass tunnel assignment between its
   forward and reverse direction PLR nodes.  This subobject MUST be
   added by the forward direction PLR node in the Path message of the
   originating LSP.  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
   on the co-routed path.

   After a link or node failure, PLR nodes in both directions trigger
   fast-reroute independently using the procedures defined in [RFC4090].
    As specified in [GMPLS-FRR], reverse direction PLR node triggers the
   fast-reroute in the reverse direction on the matching associated co-
   routed bypass tunnel to ensure that both traffic and RSVP signaling
   flow on the co-routed path after the failure.


6.  Compatibility

   The Extended ASSOCIATION Object has been defined in [RFC6780], with
   class number in the form 11bbbbbb, which ensures compatibility with



Gandhi, et al.           Expires March 14, 2017                 [Page 8]


Internet-Draft    FRR For Co-routed Bidirectional LSP September 10, 2016


   non-supporting nodes.  Per [RFC2205], such nodes will ignore the
   object but forward it without modification.

   This document defines 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 LSP path.  The
   Extended Association ID defined in this document is backwards
   compatible with the functions defined in [RFC7551] and [RFC6780].


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

   Using the Extended Association ID in the intercepted signalling
   message, a node may be able to get additional information of the LSP
   such as co-routed type and the originating node.  This is judged to
   be a very minor security risk as this information is already
   available by other means.


8.  IANA Considerations

   This document does not make any request for IANA action.
























Gandhi, et al.           Expires March 14, 2017                 [Page 9]


Internet-Draft    FRR For Co-routed Bidirectional LSP September 10, 2016


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.,
              "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 March 14, 2017                [Page 10]


Internet-Draft    FRR For Co-routed Bidirectional LSP September 10, 2016


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 March 14, 2017                [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/