Internet DRAFT - draft-gandhi-shah-teas-assoc-corouted-bidir

draft-gandhi-shah-teas-assoc-corouted-bidir



 



TEAS Working Group                                        R. Gandhi, Ed.
Internet-Draft                                             Cisco Systems
Intended Status: Standards Track                                 H. Shah
Expires: July 14, 2016                                             Ciena
                                                        Jeremy Whittaker
                                                                 Verizon
                                                        January 11, 2016


         RSVP-TE Extensions For Associated Co-routed Bidirectional 
                        Label Switched Paths (LSPs)
             draft-gandhi-shah-teas-assoc-corouted-bidir-00


Abstract

   In transport networks, there are requirements where reverse
   unidirectional LSP of a bidirectional LSP needs to follow the same
   path as its forward unidirectional LSP.  This document describes how
   RSVP Extended ASSOCIATION Object can be used to bind two co-routed
   point-to-point unidirectional LSPs into an associated co-routed
   bidirectional LSP in single-sided provisioning case.  The RSVP
   REVERSE_LSP Object is used to enable an endpoint to trigger creation
   of the reverse LSP along the same path as the forward LSP. 
   Fast-reroute procedures to ensure that the traffic flows on the co-
   routed path after a failure event are also described.


Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html
 


Gandhi, Shah, et al.     Expires July 14, 2016                  [Page 1]

Internet-Draft        Co-routed Bidirectional LSP       January 11, 2016


Copyright and License Notice

   Copyright (c) 2016 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
   (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 . . . . . . . . . . . . . . . .  4
     4.1.  Extended ASSOCIATION Object  . . . . . . . . . . . . . . .  4
   5.  Signaling Procedure  . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Co-routed Bidirectional LSP Association  . . . . . . . . .  6
     5.2.  Fast-Reroute For Associated Co-routed Bidirectional LSP  .  6
   6.  Compatibility  . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9










 


Gandhi, Shah, et al.     Expires July 14, 2016                  [Page 2]

Internet-Draft        Co-routed Bidirectional LSP       January 11, 2016


1.  Introduction

   In transport networks, there are requirements where a reverse LSP of
   a bidirectional LSP needs to follow the same path as its forward LSP
   [RFC6373].

   The 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 into an
   associated bidirectional LSP.  There are two models described for
   provisioning the LSP, single-sided and double-sided.  The double-
   sided provisioned bidirectional LSPs are not considered in this
   document.

   The MPLS TP [RFC6370] architecture facilitates the co-routed
   bidirectional LSP by using GMPLS extensions to achieve congruent
   paths.  The RSVP association signaling allows to take advantages of
   the 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 fast-reroute mechanisms.

   [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 primary LSP path.  [GMPLS-FRR] does not define fast-reroute
   mechanisms for associated co-routed bidirectional LSPs.

   This document describes how Extended ASSOCIATION Object can be used
   to bind two reverse co-routed unidirectional LSPs into an associated
   co-routed bidirectional LSP in single-sided provisioning case.  The
   REVERSE_LSP Object is used to enable an endpoint to trigger creation
   of the reverse LSP along the same path as the forward LSP.  Fast-
   reroute procedures to ensure that the traffic flows on the co-routed
   path after a failure event are also described.


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


Gandhi, Shah, et al.     Expires July 14, 2016                  [Page 3]

Internet-Draft        Co-routed Bidirectional LSP       January 11, 2016


   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

   For single-sided provisioning, the Traffic Engineering (TE) tunnel is
   configured only on one endpoint.  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 information
   from the REVERSE_LSP Object and other objects present in the received
   Path message [RFC7551].  The reverse LSP thus created may or may not
   be congruent.


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

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

   As shown in Figure 1, creation of reverse LSP2 on remote endpoint B
   is triggered by LSP1.  LSP2 follows the path in the reverse direction
   using the EXPLICIT_ROUTE Object (ERO) from the received REVERSE_LSP
   Object in LSP1.  

   For co-routed bidirectional LSP, the originating endpoint A ensures
   the reverse LSP follow the same path as the forward LSP by populating
   EXPLICIT_ROUTE Object in the REVERSE_LSP Object using the hops
   traversed by the forward LSP in the reverse order. 



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


Gandhi, Shah, et al.     Expires July 14, 2016                  [Page 4]

Internet-Draft        Co-routed Bidirectional LSP       January 11, 2016


   The Extended Association ID is set by the originating node to the
   value specified as following. 



       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      LSP Source Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Flags               |            LSP-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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      LSP Source Address                       |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Flags               |            LSP-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.

   Flags

      Bit 0: COROUTED-LSP-FLAG: When set, this flag indicates the
      associated bidirectional LSP is co-routed.

      Bit 1-15: Not used.  Must be set to 0.


 


Gandhi, Shah, et al.     Expires July 14, 2016                  [Page 5]

Internet-Draft        Co-routed Bidirectional LSP       January 11, 2016


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 MUST add Extended ASSOCIATION Object with
   Association Type set to "single-sided associated bidirectional LSP"
   and the extended association ID as specified in Section 4.1 of this
   document.  The COROUTED-LSP-FLAG MUST be set to indicate the nodes on
   the LSP path that 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. 

   As defined in [RFC7551], the remote endpoint simply copies the
   content of the received Extended ASSOCIATION Object including the
   extended association ID in the reverse LSP 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.

   As contents of the Extended ASSOCIATION Object are unique for each
   associated co-routed bidirectional LSP, a node can unambiguously
   identify the associated LSP pair by matching their Extended
   ASSOCIATION Objects.  In addition, a node can identify an originating
   (forward) LSP by matching the LSP source address with the source
   address in the extended association ID.


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 traffic flows on a co-routed
   path after a link or node failure.  The COROUTED-LSP-FLAG is used by
   the PLR nodes to provide fast-reroute protection using associated co-
   routed bypass tunnels.  

   As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject in RRO is
   used to co-ordinate bypass tunnel assignment between a forward and
   reverse direction PLRs.  This subobject MUST be added by the forward
   direction PLR in the Path message of the originating LSP.  The
   reverse direction PLR (forward direction LSP MP) simply reflects the
   bypass tunnel assignment for the reverse direction LSP on the co-
   routed path.
 


Gandhi, Shah, et al.     Expires July 14, 2016                  [Page 6]

Internet-Draft        Co-routed Bidirectional LSP       January 11, 2016


   After a link or node failure, PLRs in both directions trigger fast-
   reroute independently using the procedures defined in [RFC4090].

   As specified in [GMPLS-FRR], re-corouting procedure can be used to
   reroute the traffic in the reverse direction on the co-routed bypass
   tunnel path.  Reverse direction PLR will assume the role of PRR and
   trigger the fast-reroute in the reverse direction on the matching 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
   non-supporting nodes.  Per [RFC2205], such nodes will ignore the
   object but forward it without modification.

   This document defines the content of the Extended Association ID for
   the Extended ASSOCIATION Object for co-routed bidirectional LSPs. 
   Operators wishing to use this function SHOULD ensure that it is
   supported on the node that is expected to act on the association.


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 informational document does not make any request for IANA
   action.






 


Gandhi, Shah, et al.     Expires July 14, 2016                  [Page 7]

Internet-Draft        Co-routed Bidirectional LSP       January 11, 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.

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

   [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., Jin, L., "Extensions to Resource Reservation
              Protocol For Fast Reroute of Traffic Engineering GMPLS
              LSPs", draft-ietf-teas-gmpls-lsp-fastreroute-03, July
              2015.


9.2.  Informative References

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

   [RFC6689]  Berger, L., "Usage of The RSVP Association Object", RFC
              6689, July 2012.

 


Gandhi, Shah, et al.     Expires July 14, 2016                  [Page 8]

Internet-Draft        Co-routed Bidirectional LSP       January 11, 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, Shah, et al.     Expires July 14, 2016                  [Page 9]