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

Versions: 00 01 02 03 04 draft-ietf-pce-association-bidir

PCE Working Group                                               C. Barth
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                               R. Gandhi
Expires: September 13, 2017                          Cisco Systems, Inc.
                                                                  B. Wen
                                                                 Comcast
                                                          March 12, 2017


       PCEP Extensions for Associated Bidirectional Label Switched
                  Paths (LSPs) with Stateful PCE
               draft-barth-pce-association-bidir-01

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.  The Resource Reservation Protocol (RSVP) is used
   to signal the LSP in the network.

   This document defines PCEP extensions for binding two reverse
   unidirectional RSVP TE LSPs into an Associated Bidirectional Label
   Switched Path (LSP) when using Stateful PCE for both PCE-Initiated
   and PCC-Initiated LSPs.


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



Barth, et al.          Expires September 13, 2017               [Page 1]


Internet-Draft   PCEP For Associated Bidirectional LSP    March 12, 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  . . . . . . . . . . . . . .  4
     2.1.  Key Word Definitions . . . . . . . . . . . . . . . . . . .  4
     2.2.  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 . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Bidirectional LSP Association Group TLV  . . . . . . . . .  6
   5.  PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . .  7
     5.2.  PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . .  7
     5.3.  State Synchronization  . . . . . . . . . . . . . . . . . .  8
     5.4.  Error Handling . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  Manageability Considerations . . . . . . . . . . . . . . . . .  8
     7.1.  Control of Function and Policy . . . . . . . . . . . . . .  8
     7.2.  Information and Data Models  . . . . . . . . . . . . . . .  8
     7.3.  Liveness Detection and Monitoring  . . . . . . . . . . . .  9
     7.4.  Verify Correct Operations  . . . . . . . . . . . . . . . .  9
     7.5.  Requirements On Other Protocols  . . . . . . . . . . . . .  9
     7.6.  Impact On Network Operations . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Association Types  . . . . . . . . . . . . . . . . . . . .  9
     8.2.  Bidirectional LSP Association Group TLV  . . . . . . . . .  9
       8.2.1.  Flag Fields in Bidirectional LSP Association Group
               TLV  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.3.  PCEP Errors  . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 11



Barth, et al.          Expires September 13, 2017               [Page 2]


Internet-Draft   PCEP For Associated Bidirectional LSP    March 12, 2017


     10.2.  Informative References  . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12


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 [I-
   D.ietf-pce-stateful-pce], the focus is on Active Stateful PCE where
   LSPs are 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 initiation cases when using
   Stateful PCE.  The PCEP extensions cover the following cases:

   o  The forward or reverse LSP of an bidirectional LSP is initiated on
      a PCC by a Stateful PCE which retains the control of the LSP.  The
      PCE is responsible for computing the path of the LSP and updating
      the PCC with the information about the path.

   o  A PCC initiates the forward or reverse LSP of a bidirectional LSP
      and retains the control of the LSP.  The PCC computes the path and
      updates the PCE with the information about the path (as long as it
      controls the LSP).



Barth, et al.          Expires September 13, 2017               [Page 3]


Internet-Draft   PCEP For Associated Bidirectional LSP    March 12, 2017


   o  A PCC initiates the forward or reverse LSP of a bidirectional LSP
      and delegates the control of the LSP to a Stateful PCE.  The PCE
      may compute the path for the LSP and update the PCC with the
      information about the path (as long as it controls the LSP).


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

   The reader is assumed to be familiar with the terminology defined in
   [RFC5440] and [RFC7551].


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 initiation case, the
   bidirectional tunnel is signaled only on one ingress endpoint node
   (PCC) of a LSP tunnel.  Both forward and reverse LSPs are initiated
   by the Stateful PCE with the Association Type set to "Single-sided
   Bidirectional LSP Association" on the originating endpoint node



Barth, et al.          Expires September 13, 2017               [Page 4]


Internet-Draft   PCEP For Associated Bidirectional LSP    March 12, 2017


   (PCC).  The originating PCC identifies the forward and reverse LSPs
   in the TLV of the Association Objects.

   The originating endpoint node uses the 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, the forward LSP LSP1 and the reverse LSP LSP2
   are initiated on the originating endpoint node A by the PCE.  The
   creation of reverse LSP2 on the remote endpoint node D is triggered
   by the RSVP signaled LSP1.

3.2.  Double-sided Initiation

   As specified in [RFC7551], in the double-sided initiation case, the
   bidirectional LSP is signaled by both endpoint nodes (PCCs) of the
   tunnel.  The forward and reverse LSPs for this tunnel are initiated
   by the Stateful PCE 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 initiated on the endpoint node A and
   LSP2 is initiated on the endpoint node D, both by the PCE.

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




Barth, et al.          Expires September 13, 2017               [Page 5]


Internet-Draft   PCEP For Associated Bidirectional LSP    March 12, 2017


4.1.  Association Object

   As per [I-D.ietf-pce-association], LSPs are associated by adding them
   to a common association group.  This document defines new
   Bidirectional LSP Association Groups to be used by the associated
   bidirectional LSPs.  A member of the Bidirectional LSP Association
   Group can take the role of a forward or reverse LSP.  The reverse LSP
   source address MUST be the destination address of the forward LSP and
   destination address MUST be the source address of the forward LSP
   within a bidirectional LSP association group.

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

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

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

   The Association ID, Association Source, optional Global Association
   Source and optional Extended Association ID in the Bidirectional LSP
   Association Group Object are initiated by the Stateful PCE using the
   procedures defined in [RFC7551].

4.2.  Bidirectional LSP Association Group TLV

   The Bidirectional LSP Association Group TLV is an optional TLV for
   use with the Bidirectional LSP Association Object Type.

   o  The Bidirectional LSP Association Group 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 Group TLV is missing, it
      means the LSP is the forward LSP.

   o  The Bidirectional LSP Association Group 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.




Barth, et al.          Expires September 13, 2017               [Page 6]


Internet-Draft   PCEP For Associated Bidirectional LSP    March 12, 2017


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


    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            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Reserved                          |C|R|F|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 3: Bidirectional LSP Association Group TLV format

   Bidirectional LSP Association Flags are defined as following.

   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 associated bidirectional LSP
     is co-routed.

   The Reserved flags MUST be set to 0 when sent and ignore when
   received.

   When an associated bidirectional LSP is delegated to a Stateful PCE,
   the C flag is used by the PCE to compute paths of the forward and
   reverse LSPs those are co-routed.


5.  PCEP Procedure

5.1.  PCE Initiated LSPs

   As specified in [I-D.ietf-pce-association], Association Groups can be
   created by both PCE and PCC.

   A PCE can create and update the forward and reverse LSPs
   independently for both Single-sided and Double-sided bidirectional
   LSP association groups.

5.2.  PCC Initiated LSPs



Barth, et al.          Expires September 13, 2017               [Page 7]


Internet-Draft   PCEP For Associated Bidirectional LSP    March 12, 2017


   A PCC can associate or remove an LSP under its control from the
   bidirectional LSP association group.  The PCC must report the change
   in association to PCE(s) via PCRpt message.

5.3.  State Synchronization

   During state synchronization, a PCC MUST report all the existing
   bidirectional LSP association groups to PCE(s).  Following the state
   synchronization, the PCE MUST remove all stale associations.

5.4.  Error Handling

   The reverse LSP in the bidirectional LSP association group MUST have
   the source address matching the destination address of the forward
   LSP and destination address matching the source address of the
   forward LSP.  If a PCE attempts to add an LSP to a bidirectional LSP
   association group not complying to this rule, the PCC for the single-
   sided initiation case MUST send PCErr with Error-Type= TBD4
   (Bidirectional LSP Association Error) and Error-Value = 1 (Endpoints
   mismatch).  Similarly, if a PCC attempt to add an LSP to a
   bidirectional LSP association group at PCE not complying to this
   rule, the PCE for both single-sided and double-sided initiated
   bidirectional LSPs MUST send this PCErr.


6.  Security Considerations

   This document introduces two new Association Types for the
   Association Object, Double-sided Bidirectional LSP Association Group
   and Single-sided Associated Bidirectional LSP Group.  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].


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.

7.2.  Information and Data Models

   A Management Information Base (MIB) module for modeling PCEP is
   described in [RFC7420].  However, one may prefer the mechanism for
   configuration using YANG data model [I-D.pce-pcep-yang].  These
   SHOULD be enhanced to provide controls and indicators for support of



Barth, et al.          Expires September 13, 2017               [Page 8]


Internet-Draft   PCEP For Associated Bidirectional LSP    March 12, 2017


   the associated bidirectional LSP feature.  Support for various
   configuration knobs as well as counters of messages sent/received
   containing the TLVs (defined in this document) SHOULD be added.

7.3.  Liveness Detection and Monitoring

   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in [RFC5440].

7.4.  Verify Correct Operations

   Mechanisms defined in this document do not imply any new operation
   verification requirements in addition to those already listed in
   [RFC5440].

7.5.  Requirements On Other Protocols

   Mechanisms defined in this document do not add any new requirements
   on other protocols.

7.6.  Impact On Network Operations

   Mechanisms defined in this document do not have any new impact on
   network operations.


8.  IANA Considerations

8.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 Group  [This I.D.]
    TBD2  Double-sided Bidirectional LSP Association Group  [This I.D.]

8.2.  Bidirectional LSP Association Group TLV

   This document defines a new TLV for carrying additional LSP
   information for the Bidirectional LSP Association Group TLV as
   following:

   TLV-Type  Name                                      Reference
   ---------------------------------------------------------------
    TBD3     Bidirectional LSP Association Group TLV   [This I.D.]



Barth, et al.          Expires September 13, 2017               [Page 9]


Internet-Draft   PCEP For Associated Bidirectional LSP    March 12, 2017


8.2.1.  Flag Fields in Bidirectional LSP Association Group TLV

   This document requests that a new sub-registry, named "Bidirectional
   LSP Association Group TLV Flag Field", is created within the "Path
   Computation Element Protocol (PCEP) Numbers" registry to manage the
   Flag field in the Bidirectional LSP Association Group TLV.

   New values are to be assigned by Standards Action [RFC5226].  Each
   bit should be tracked with the following qualities:

      o  Bit number (counting from bit 0 as the most significant bit)

      o  Capability description

      o  Defining RFC


   The following values are defined in this document for the Flag field.

   Bit     Description                   Reference
   -------------------------------------------------
    31     F - Forward LSP               [This I.D.]
    30     R - Reverse LSP               [This I.D.]
    29     C - Co-routed LSP             [This I.D.]

8.3.  PCEP Errors

   This document defines new Error-Type and Error-Value related to
   bidirectional LSP association as following.

   Error-Type   Description                            Reference
   ---------------------------------------------------------------
    TBD4        Bidirectional LSP Association Error    [This I.D.]

                Error-value=1: Endpoints mismatch      [This I.D.]


9.  Acknowledgments

   TBA.











Barth, et al.          Expires September 13, 2017              [Page 10]


Internet-Draft   PCEP For Associated Bidirectional LSP    March 12, 2017


10.  References

10.1.  Normative References

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [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-group (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).

10.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).

   [I-D.pce-pcep-yang]  Dhody, D., Hardwick, J., Beeram, V., and J.
              Tantsura, "A YANG Data Model for Path Computation Element
              Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang
              (work in progress).



Barth, et al.          Expires September 13, 2017              [Page 11]


Internet-Draft   PCEP For Associated Bidirectional LSP    March 12, 2017


Authors' Addresses


   Colby Barth
   Juniper Networks

   EMail: cbarth@juniper.net


   Rakesh Gandhi
   Cisco Systems, Inc.

   EMail: rgandhi@cisco.com


   Bin Wen
   Comcast

   EMail: Bin_Wen@cable.comcast.com
































Barth, et al.          Expires September 13, 2017              [Page 12]


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