Path Computation Element Communication Protocol Extensions for Associated Bidirectional Label Switched Paths (LSPs)
draft-barth-pce-association-bidir-00

PCE Working Group                                               C. Barth
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                               R. Gandhi
Expires: April 30, 2017                           Individual Contributor
                                                                  B. Wen
                                                                 Comcast
                                                        October 27, 2016

    Path Computation Element Communication Protocol Extensions for 
         Associated Bidirectional Label Switched Paths (LSPs)
               draft-barth-pce-association-bidir-00

Abstract

   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.
    The stateful PCE extensions allow stateful control of Multi-Protocol
   Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
   (LSPs) using PCEP.

   This document defines Path Computation Element Communication Protocol
   (PCEP) extensions for binding two reverse unidirectional RSVP-TE LSPs
   into an Associated Bidirectional Label Switched Path (LSP).

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.

 

Barth, et al.            Expires April 30, 2017                 [Page 1]
Internet-Draft     PCEP Associated Bidirectional LSP    October 27, 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.  Acronyms and Abbreviations . . . . . . . . . . . . . . . .  3
     2.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Single-sided Initiation  . . . . . . . . . . . . . . . . .  4
     3.2.  Double-sided Initiation  . . . . . . . . . . . . . . . . .  5
     3.3.  Co-routed Associated Bidirectional LSP . . . . . . . . . .  5
   4.  Protocol Extensions  . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Association Object . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Bidirectional LSP Association TLV  . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Association Types  . . . . . . . . . . . . . . . . . . . .  7
     6.2.  Bidirectional LSP Association TLV  . . . . . . . . . . . .  7
   7.  Manageability Considerations . . . . . . . . . . . . . . . . .  8
     7.1.  Control of Function and Policy . . . . . . . . . . . . . .  8
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

 

Barth, et al.            Expires April 30, 2017                 [Page 2]
Internet-Draft     PCEP Associated Bidirectional LSP    October 27, 2016

1.  Introduction

   [RFC5440] describes the Path Computation Element Protocol (PCEP) as a
   communication mechanism between a Path Computation Client (PCC) and a
   Path Control Element (PCE), or between PCE and PCC, that enables
   computation of Multi-Protocol Label Switching (MPLS) Traffic
   Engineering (TE) Label Switched Paths (LSPs).

   [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable
   stateful control of MPLS TE LSPs.  It describes two modes of
   operation - Passive stateful PCE and Active stateful PCE.  In this
   [I-D.ietf-pce-stateful-pce] document, the focus is on Active stateful
   PCE where LSPs are can be provisioned on the PCC and control over
   them is delegated to a PCE.  Further [I-D.ietf-pce-pce-initiated-lsp]
   describes the setup, maintenance and teardown of PCE-initiated LSPs
   for the stateful PCE model.

   [I-D.ietf-pce-association] introduces a generic mechanism to create a
   grouping of LSPs which can then be used to define associations
   between a set of LSPs and/or a set of attributes, for example primary
   and secondary LSP associations, and is equally applicable to the
   active and passive modes of a stateful PCE [I-D.ietf-pce-stateful-
   pce] or a stateless PCE [RFC5440].

   The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]
   specifies that MPLS-TP MUST support associated bidirectional point-
   to-point LSPs.  [RFC7551] specifies RSVP signaling extensions for
   binding two reverse unidirectional LSPs into an associated
   bidirectional LSP.

   This document specifies PCEP extensions for binding two reverse
   unidirectional RSVP-TE LSPs into an Associated Bidirectional LSP for
   both single-sided and double-sided provisioning.

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

2.2.  Acronyms and Abbreviations

   LSP:  Label Switched Path

   LSR:  Label Switching Router
 

Barth, et al.            Expires April 30, 2017                 [Page 3]
Internet-Draft     PCEP Associated Bidirectional LSP    October 27, 2016

   MPLS:  Multi-Protocol Label Switching

   PCEP:  Path Computation Element Communication Protocol

2.3.  Terminology

   The following terminology is used in this document.

   Active Stateful PCE:  PCE that uses tunnel state information learned
   from PCCs to optimize path computations.  Additionally, it actively
   updates tunnel parameters in those PCCs that delegated control over
   their tunnels to the PCE.

   PCC:  Path Computation Client.  Any client application requesting a
   path computation to be performed by a Path Computation Element.

   PCE:  Path Computation Element.  An entity (component, application,
   or network node) that is capable of computing a network path or route
   based on a network graph and applying computational constraints.

3.  Overview

   As shown in Figure 1, two reverse unidirectional LSPs can be
   associated to form an associated bidirectional LSP.  There are two
   methods of initiating the bidirectional LSP association, single-sided
   and double-sided as described in the following sections.

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

      Figure 1: An Example of Associated Bidirectional LSP

3.1.  Single-sided Initiation

   As specified in [RFC7551], in the single-sided provisioning case, the
   bidirectional tunnel is signaled only on one ingress LSR of a LSP
   tunnel.  Both forward and reverse LSPs for this tunnel are initiated
   by the PCE with the Association Type set to "Single-sided
 

Barth, et al.            Expires April 30, 2017                 [Page 4]
Internet-Draft     PCEP Associated Bidirectional LSP    October 27, 2016

   Bidirectional LSP Association" on the originating ingress PCC.  The
   originating PCC identifies the forward and reverse LSPs in the TLV of
   the Association Objects.  The originating endpoint uses the signaled
   properties for the revere LSP in the RSVP REVERSE_LSP Object
   [RFC7551] of the forward LSP Path message.  The remote endpoint then
   creates the corresponding reverse tunnel and signals the reverse LSP
   in response to the received RSVP Path message.  The two
   unidirectional reverse LSPs on the originating endpoint node are
   bound together using the PCEP signaled Association Objects and on the
   remote endpoint node by the RSVP signaled Association Objects.  As
   shown in Figure 1, LSP1 and LSP2 are provisioned on the originating
   endpoint A by the PCE peer.  The creation of reverse LSP2 on the
   remote endpoint D is triggered by the RSVP signaled LSP1.   

3.2.  Double-sided Initiation

   As specified in [RFC7551], in the double-sided provisioning case, the
   bidirectional tunnel is provisioned on both endpoint nodes(PCCs) of
   the tunnel.  The reverse LSPs for this tunnel are initiated by the
   PCE peer with Association Type set to "Double-sided Bidirectional LSP
   Association" on both ingress PCCs.  The two reverse unidirectional
   LSPs on both PCCs are bound together by using the PCEP signaled
   Association Objects.  As shown in Figure 1, LSP1 is provisioned on
   the endpoint A and LSP2 is provisioned on the endpoint node D, both
   by the PCEP peer.

3.3.  Co-routed Associated Bidirectional LSP

   In both single-sided and double-sided initiation cases, forward and
   reverse LSPs may be co-routed as shown in Figure 2, where both
   forward and reverse LSPs follow the same congruent path. 

               LSP3 -->         LSP3 -->           LSP3 -->
      +-----+           +-----+           +-----+           +-----+
      |  A  +-----------+  B  +-----------+  C  |-----------+  D  |
      +-----+           +-----+           +-----+           +-----+
              <-- LSP4          <-- LSP4           <-- LSP4

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

4.  Protocol Extensions

4.1.  Association Object

   As per [I-D.ietf-pce-association], LSPs are associated by adding them
   to a common association group.  
 

Barth, et al.            Expires April 30, 2017                 [Page 5]
Internet-Draft     PCEP Associated Bidirectional LSP    October 27, 2016

   This document defines two new Association Types for the Association
   Object as follows:

   o  Association Type (TBD1) = Single-sided Bidirectional LSP
   Association

   o  Association Type (TBD2) = Double-sided Bidirectional LSP
   Association

   The Association ID, Association Source, Global Association Source and
   Extended Association ID in the Association Object of the
   bidirectional LSP are provisioned by the PCE using the procedures
   defined in [RFC7551].

4.2.  Bidirectional LSP Association TLV

   The Bidirectional LSP Association TLV is an optional TLV for use with
   the Bidirectional LSP Association Type in the single-sided
   provisioning case. 

   o  The Bidirectional LSP Association TLV follows the PCEP TLV format
      from [RFC5440].

   o  The type (16 bits) of the TLV is TBD3, to be assigned by IANA.  

   o  The length is 4 Bytes.

   o  The value comprises of a single field, the Bidirectional LSP
      Association Flags (32 bits), where each bit represents a flag
      option.

   o  If the Bidirectional LSP Association TLV is missing, it means the
      LSP is the forward LSP.

   o  The Bidirectional LSP Association TLV MUST NOT be present more
      than once.  If it appears more than once, only the first
      occurrence is processed and any others MUST be ignored.

   The format of the Bidirectional LSP Association TLV is shown in
   Figure 3:

 

Barth, et al.            Expires April 30, 2017                 [Page 6]
Internet-Draft     PCEP Associated Bidirectional LSP    October 27, 2016

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Type = TBD3           |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Bidirectional LSP Association Flags            |C|R|F|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 3: Bidirectional LSP Association TLV format

   F (FORWARD-LSP, 1 bit) - Indicates whether the LSP associated is the
     forward LSP of the bidirectional LSP.  If this flag is set, the LSP
     is a forward LSP.

   R (REVERSE-LSP, 1 bit) - Indicates whether the LSP associated is the
     reverse LSP of the bidirectional LSP.  If this flag is set, the LSP
     is a reverse LSP.

   C (Co-ROUTED-LSP, 1 bit) - Indicates whether the bidirectional LSP is
     co-routed.  If this flag is set, the bidirectional LSP is
     co-routed.

5.  Security Considerations

   This document introduces two new Association Types for the
   Association Object, Double-Sided Associated Bidirectional LSP and
   Single-Sided Associated Bidirectional LSP.  These types, by
   themselves, introduce no additional security concerns beyond those
   discussed in [RFC5440], [I-D.ietf-pce-stateful-pce] and [I-D.ietf-
   pce-association]. 

6.  IANA Considerations

6.1.  Association Types

   This document defines the following Association Types for the
   Association Object defined [I-D.ietf-pce-association].

   Value Name                                        Reference

   TBD1 Single-sided Bidirectional LSP Association   [This I.D.]
   TBD2 Double-sided Bidirectional LSP Association   [This I.D.]

6.2.  Bidirectional LSP Association TLV
 

Barth, et al.            Expires April 30, 2017                 [Page 7]
Internet-Draft     PCEP Associated Bidirectional LSP    October 27, 2016

   This document defines a new TLV for carrying additional LSP
   information for the bidirectional LSP association type as follows:

    +--------------------+------------------------+-------------+
    | TLV Type Value     | TLV Name               | Reference   |
    +--------------------+------------------------+-------------+
    | TBD3               | Bidirectional LSP      | This        |
    |                    | Association TLV        | document    |
    +--------------------+------------------------+-------------+

7.  Manageability Considerations

7.1.  Control of Function and Policy

   An operator MUST be allowed to provision the bidirectional LSP
   association parameters at PCEP peers.

8.  Acknowledgments

   TBA.

 

Barth, et al.            Expires April 30, 2017                 [Page 8]
Internet-Draft     PCEP Associated Bidirectional LSP    October 27, 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.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440.

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

   [I-D.ietf-pce-association]  Minei, I., Crabbe, E., Sivabalan, S.,
              Ananthakrishnan, H., Zhang, X., and Y. Tanaka, "PCEP
              Extensions for Establishing Relationships Between Sets of
              LSPs", draft-ietf-pce-association (work in progress).

   [I-D.ietf-pce-stateful-pce]  Crabbe, E., Minei, I., Medved, J., and
              R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-
              pce-stateful-pce (work in progress).

9.2.  Informative References

   [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
              Sprecher, N., and S. Ueno, "Requirements of an MPLS
              Transport Profile", RFC 5654, September 2009.

   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
              Hardwick, "Path Computation Element Communication Protocol
              (PCEP) Management Information Base (MIB) Module", RFC
              7420, December 2014.

   [I-D.ietf-pce-pce-initiated-lsp]  Crabbe, E., Minei, I., Sivabalan,
              S., and R. Varga, "PCEP Extensions for PCE-initiated LSP
              Setup in a Stateful PCE Model", draft-ietf-pce-pce-
              initiated-lsp (work in progress).

 

Barth, et al.            Expires April 30, 2017                 [Page 9]
Internet-Draft     PCEP Associated Bidirectional LSP    October 27, 2016

Authors' Addresses

   Colby Barth
   Juniper Networks

   EMail: cbarth@juniper.net

   Rakesh Gandhi
   Individual Contributor

   EMail: rgandhi.ietf@gmail.com

   Bin Wen
   Comcast

   EMail: Bin_Wen@cable.comcast.com

Barth, et al.            Expires April 30, 2017                [Page 10]