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

Versions: (draft-crabbe-pce-pce-initiated-lsp) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 8281

PCE Working Group                                              E. Crabbe
Internet-Draft
Intended status: Standards Track                                I. Minei
Expires: October 19, 2015                                   Google, Inc.
                                                            S. Sivabalan
                                                     Cisco Systems, Inc.
                                                                R. Varga
                                               Pantheon Technologies SRO
                                                          April 17, 2015


  PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
                  draft-ietf-pce-pce-initiated-lsp-04

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 extensions for stateful PCE provide stateful control of
   Multiprotocol Label Switching (MPLS) Traffic Engineering Label
   Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates
   control over one or more locally configured LSPs to the PCE.  This
   document describes the creation and deletion of PCE-initiated LSPs
   under the stateful PCE model.

Requirements Language

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

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




Crabbe, et al.          Expires October 19, 2015                [Page 1]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


   This Internet-Draft will expire on October 19, 2015.

Copyright Notice

   Copyright (c) 2015 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   3
     3.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Operation overview  . . . . . . . . . . . . . . . . . . .   4
   4.  Support of PCE-initiated LSPs . . . . . . . . . . . . . . . .   6
     4.1.  Stateful PCE Capability TLV . . . . . . . . . . . . . . .   6
   5.  PCE-initiated LSP instantiation and deletion  . . . . . . . .   7
     5.1.  The LSP Initiate Message  . . . . . . . . . . . . . . . .   7
     5.2.  The R flag in the SRP Object  . . . . . . . . . . . . . .   8
     5.3.  LSP instantiation . . . . . . . . . . . . . . . . . . . .   9
       5.3.1.  The Create flag . . . . . . . . . . . . . . . . . . .  11
       5.3.2.  The SPEAKER-IDENTITY-ID TLV . . . . . . . . . . . . .  11
     5.4.  LSP deletion  . . . . . . . . . . . . . . . . . . . . . .  11
   6.  LSP delegation and cleanup  . . . . . . . . . . . . . . . . .  12
   7.  Implementation status . . . . . . . . . . . . . . . . . . . .  13
   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  PCEP Messages . . . . . . . . . . . . . . . . . . . . . .  13
     8.2.  LSP Object  . . . . . . . . . . . . . . . . . . . . . . .  13
     8.3.  SRP object  . . . . . . . . . . . . . . . . . . . . . . .  14
     8.4.  STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . .  14
     8.5.  PCEP-Error Object . . . . . . . . . . . . . . . . . . . .  14
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     9.1.  Malicious PCE . . . . . . . . . . . . . . . . . . . . . .  15
     9.2.  Malicious PCC . . . . . . . . . . . . . . . . . . . . . .  15
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16



Crabbe, et al.          Expires October 19, 2015                [Page 2]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   [RFC5440] describes the Path Computation Element Protocol PCEP.  PCEP
   defines the communication between a Path Computation Client (PCC) and
   a Path Control Element (PCE), or between PCE and PCE, enabling
   computation of Multiprotocol Label Switching (MPLS) for Traffic
   Engineering Label Switched Path (TE LSP) characteristics.

   Stateful pce [I-D.ietf-pce-stateful-pce]  specifies a set of
   extensions to PCEP to enable stateful control of TE LSPs between and
   across PCEP sessions in compliance with [RFC4657].  It includes
   mechanisms to effect LSP state synchronization between PCCs and PCEs,
   delegation of control of LSPs to PCEs, and PCE control of timing and
   sequence of path computations within and across PCEP sessions and
   focuses on a model where LSPs are configured on the PCC and control
   over them is delegated to the PCE.

   This document describes the setup, maintenance and teardown of PCE-
   initiated LSPs under the stateful PCE model, without the need for
   local configuration on the PCC, thus allowing for a dynamic network
   that is centrally controlled and deployed.

2.  Terminology

   This document uses the following terms defined in [RFC5440]: PCC,
   PCE, PCEP Peer.

   This document uses the following terms defined in
   [I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Redelegation
   Timeout, State Timeout Interval LSP State Report, LSP Update Request.

   The following terms are defined in this document:

   PCE-initiated LSP:  LSP that is instantiated as a result of a request
      from the PCE.

   The message formats in this document are specified using Routing
   Backus-Naur Format (RBNF) encoding as specified in [RFC5511].

3.  Architectural Overview

3.1.  Motivation

   [I-D.ietf-pce-stateful-pce] provides stateful control over LSPs that
   are locally configured on the PCC.  This model relies on the Label
   Edge Router (LER) taking an active role in delegating locally



Crabbe, et al.          Expires October 19, 2015                [Page 3]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


   configured LSPs to the PCE, and is well suited in environments where
   the LSP placement is fairly static.  However, in environments where
   the LSP placement needs to change in response to application demands,
   it is useful to support dynamic creation and tear down of LSPs.  The
   ability for a PCE to trigger the creation of LSPs on demand can make
   possible agile software-driven network operation, and can be
   seamlessly integrated into a controller-based network architecture,
   where intelligence in the controller can determine when and where to
   set up paths.

   A possible use case is one of a software-driven network, where
   applications request network resources and paths from the network
   infrastructure.  For example, an application can request a path with
   certain constraints between two LSRs by contacting the PCE.  The PCE
   can compute a path satisfying the constraints, and instruct the head
   end LSR to instantiate and signal it.  When the path is no longer
   required by the application, the PCE can request its teardown.

   Another use case is one of dynamically adjusting aggregate bandwidth
   between two points in the network using multiple LSPs.  This
   functionality is very similar to auto-bandwidth, but allows for
   providing the desired capacity through multiple LSPs.  This approach
   overcomes two of the limitations auto-bandwidth can experience: 1)
   growing the capacity between the endpoints beyond the capacity of
   individual links in the path and 2) achieving good bin-packing
   through use of several small LSPs instead of a single large one.  The
   number of LSPs varies based on the demand, and LSPs are created and
   deleted dynamically to satisfy the bandwidth requirements.

   Another use case is that of demand engineering, where a PCE with
   visibility into both the network state and the demand matrix can
   anticipate and optimize how traffic is distributed across the
   infrastructure.  Such optimizations may require creating new paths
   across the infrastructure.

3.2.  Operation overview

   A PCC or PCE indicates its ability to support PCE provisioned dynamic
   LSPs during the PCEP Initialization Phase via a new flag in the
   STATEFUL-PCE-CAPABILITY TLV (see details in Section 4.1).

   The decision when to instantiate or delete a PCE-initiated LSP is out
   of the scope of this document.  To instantiate or delete an LSP, the
   PCE sends a new message, the Path Computation LSP Initiate Request
   (PCInitiate) message to the PCC.  The LSP Initiate Request MUST
   include the SRP and LSP objects ([I-D.ietf-pce-stateful-pce]), and
   the LSP object MUST include the Symbolic Path Name TLV and MUST have
   a PLSP-ID ([I-D.ietf-pce-stateful-pce]) of 0.



Crabbe, et al.          Expires October 19, 2015                [Page 4]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


   For an instantiation operation, the PCE MUST include the ERO and END-
   POINTS object and may include various attributes as per [RFC5440].
   The PCC creates the LSP using the attributes communicated by the PCE,
   and local values for the unspecified parameters.  It assigns a unique
   PLSP-ID for the LSP and automatically delegates the LSP to the PCE.
   It also generates an LSP State Report (PCRpt) for the LSP, carrying
   the newly assigned PLSP-ID and indicating the delegation via the
   Delegate flag in the LSP object.  In addition to the Delegate flag,
   the PCC also sets the Create flag in the LSP object (see
   Section 5.3.1), to indicate that the LSP was created as a result of a
   PCInitiate message and SHOULD include the optional SPEAKER-IDENTITY-
   ID TLV defined in [I-D.ietf-pce-stateful-sync-optimizations]
   identifying the PCE that requested the LSP creation.  This PCRpt
   message MUST include the SRP object, with the SRP-id-number used in
   the SRP object of the PCInitate message.  The PCE may update the
   attributes of the LSP via subsequent PCUpd messages.  Subsequent LSP
   State Report and LSP Update Request for the LSP will carry the PCC-
   assigned PLSP-ID, which uniquely identifies the LSP.  See details in
   Section 5.3.

   Once instantiated, the delegation procedures for PCE-initiated LSPs
   are the same as for PCC initiated LSPs as described in
   [I-D.ietf-pce-stateful-pce], with the exception that the PCC cannot
   revoke a delegation for a PCE-initiated LSP.  This applies to the
   case of a PCE failure as well.  In order to allow for network cleanup
   without manual intervention, the PCC SHOULD support removal of PCE-
   initiated LSPs as one of the behaviors applied on expiration of the
   State Timeout Interval [I-D.ietf-pce-stateful-pce].  The behavior
   SHOULD be picked based on local policy, and can result either in LSP
   removal, or into reverting to operator-defined default parameters.
   See details in Section 6.  A PCE MAY return a delegation to the PCC
   in order to facilitate re-delegation of its LSPs to an alternate PCE.

   To indicate a delete operation, the PCE MUST use the new R flag in
   the SRP object in a PCInitiate message as described in Section 5.2.
   As a result of the deletion request, the PCC MUST remove all state
   related to the LSP, and send a PCRpt with the R flag set in the LSP
   object for the removed state.  See details in Section 5.4.

   LSP State Synchronization procedures are described in section 5.4 of
   [I-D.ietf-pce-stateful-pce].  During State Synchronization, a PCC
   reports the state of its LSPs to the PCE using PCRpt messages and
   setting the SYNC flag in the LSP Object.  For PCE-initiated LSPs, the
   PCC MUST also include the Create Flag in the LSP Object and SHOULD
   include the SPEAKER-IDENTITY-ID TLV identifying the PCE that
   requested the LSP creation.  At the end of state synchronization, the
   PCE SHOULD do a sanity check between the reported PCE-Initiated LSPs
   and local configurations at PCE to initiate LSPs.  For any mismatch,



Crabbe, et al.          Expires October 19, 2015                [Page 5]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


   the PCE SHOULD send a PCInitiate message to either initiate (again)
   or remove the LSP.

4.  Support of PCE-initiated LSPs

   A PCEP speaker indicates its ability to support PCE provisioned
   dynamic LSPs during the PCEP Initialization phase.  The Open Object
   in the Open message contains the "Stateful PCE Capability" TLV,
   defined in [I-D.ietf-pce-stateful-pce].  A new flag, the I (LSP-
   INSTANTIATION-CAPABILITY) flag is introduced to indicate support for
   instantiation of PCE-initiated LSPs.  A PCE can initiate LSPs only
   for PCCs that advertised this capability and a PCC will follow the
   procedures described in this document only on sessions where the PCE
   advertised the I flag.

4.1.  Stateful PCE Capability TLV

   The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the
   following figure:

      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            |            Length=4           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Flags                                      |I|S|U|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+

               Figure 1: STATEFUL-PCE-CAPABILITY TLV format

   The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it
   has a fixed length of 4 octets.

   The value comprises a single field - Flags (32 bits).  The U and S
   bits are defined in [I-D.ietf-pce-stateful-pce] and
   [I-D.ietf-pce-stateful-sync-optimizations] respectively.

   I (LSP-INSTANTIATION-CAPABILITY - 1 bit):  If set to 1 by a PCC, the
      I Flag indicates that the PCC allows instantiation of an LSP by a
      PCE.  If set to 1 by a PCE, the I flag indicates that the PCE may
      attempt to instantiate LSPs.  The LSP-INSTANTIATION-CAPABILITY
      flag must be set by both PCC and PCE in order to support PCE-
      initiated LSP instantiation.

   Unassigned bits are considered reserved.  They MUST be set to 0 on
   transmission and MUST be ignored on receipt.





Crabbe, et al.          Expires October 19, 2015                [Page 6]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


5.  PCE-initiated LSP instantiation and deletion

   To initiate an LSP, a PCE sends a PCInitiate message to a PCC.  The
   message format, objects and TLVs are discussed separately below for
   the creation and the deletion cases.

5.1.  The LSP Initiate Message

   A Path Computation LSP Initiate Message (also referred to as
   PCInitiate message) is a PCEP message sent by a PCE to a PCC to
   trigger LSP instantiation or deletion.  The Message-Type field of the
   PCEP common header for the PCInitiate message is set to 12 (suggested
   value, to be assigned by IANA).  The PCInitiate message MUST include
   the SRP and the LSP objects, and may contain other objects, as
   discussed later in this section.  If the SRP object is missing, the
   PCC MUST send a PCErr with error-type 6 (Mandatory Object missing)
   and error-value=10 (SRP Object missing) (per
   [I-D.ietf-pce-stateful-pce]).  If the LSP object is missing, the PCC
   MUST send a PCErr with error-type 6 (Mandatory Object missing) and
   error-value=8 (LSP Object missing) (per [I-D.ietf-pce-stateful-pce]).
   LSP instantiation is done by sending an LSP Initiate Message with an
   LSP object with the reserved PLSP-ID 0.  LSP deletion is done by
   sending an LSP Initiate Message with an LSP object carrying the PLSP-
   ID of the LSP to be removed and an SRP object with the R flag set
   (see Section 5.2).

   The format of a PCInitiate message for LSP instantiation is as
   follows:























Crabbe, et al.          Expires October 19, 2015                [Page 7]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


   <PCInitiate Message> ::= <Common Header>
                            <PCE-initiated-lsp-list>
Where:

   <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>[<PCE-initiated-lsp-list>]

   <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|<PCE-initiated-lsp-deletion>)

   <PCE-initiated-lsp-instantiation> ::= <SRP>
                                         <LSP>
                                         <END-POINTS>
                                         <ERO>
                                         [<attribute-list>]

   <PCE-initiated-lsp-deletion> ::= <SRP>
                                    <LSP>

Where:
   <attribute-list> is defined in [RFC5440] and extended by PCEP extensions.

   The SRP object is used to correlate between initiation requests sent
   by the PCE and the error reports and state reports sent by the PCC.
   Every request from the PCE receives a new SRP-ID-number.  This number
   is unique per PCEP session and is incremented each time an operation
   (initiation, update, etc) is requested from the PCE.  The value of
   the SRP-ID-number MUST be echoed back by the PCC in PCErr and PCRpt
   messages to allow for correlation between requests made by the PCE
   and errors or state reports generated by the PCC.  Details of the SRP
   object and its use can be found in [I-D.ietf-pce-stateful-pce].

5.2.  The R flag in the SRP Object

   The format of the SRP object is shown Figure 2:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Flags                              |R|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        SRP-ID-number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                      Optional TLVs                          //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 2: The SRP Object format



Crabbe, et al.          Expires October 19, 2015                [Page 8]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


   The type object is defined in [I-D.ietf-pce-stateful-pce].

   A new flag is defined to indicate a delete operation initiated by the
   PCE:

   R (LSP-REMOVE - 1 bit):  If set to 1, it indicates a removal request
      initiated by the PCE.

5.3.  LSP instantiation

   LSP instantiation is done by sending an LSP Initiate Message with an
   LSP object with the reserved PLSP-ID 0.  The LSP is set up using
   RSVP-TE, extensions for other setup methods are outside the scope of
   this draft.

   Receipt of a PCInitiate Message with a non-zero PLSP-ID and the R
   flag in the SRP object set to zero results in a PCErr message of type
   19 (Invalid Operation) and value to be assigned by IANA, suggested
   value 8 (Non-zero PLSP-ID in LSP initiation request).

   The END-POINTS Object is mandatory for an instantiation request of an
   RSVP-signaled LSP.  It contains the source and destination addresses
   for provisioning the LSP.  If the END-POINTS Object is missing, the
   PCC MUST send a PCErr message with Error-type=6 (Mandatory Object
   missing) and Error-value=3 (END-POINTS Object missing).

   The ERO Object is mandatory for an instantiation request.  It
   contains the ERO for the LSP.  If the ERO Object is missing, the PCC
   MUST send a PCErr message with Error-type=6 (Mandatory Object
   missing) and Error-value=9 (ERO Object missing).

   The LSP Object MUST include the SYMBOLIC-PATH-NAME TLV, which will be
   used to correlate between the PCC-assigned PLSP-ID and the LSP.  If
   the TLV is missing, the PCC MUST send a PCErr message with Error-
   type=10 (Invalid object) and Error-value to be assigned by IANA,
   suggested value 8, (SYMBOLIC-PATH-NAME TLV missing).  The symbolic
   name used for provisioning PCE-initiated LSPs must not have conflict
   with the LSP name of any existing LSP in the PCC.  (Existing LSPs may
   be either statically configured, or initiated by another PCE).  If
   there is conflict with the LSP name, the PCC MUST send a PCErr
   message with Error-type to be assigned by IANA, suggested value 23
   (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use).
   The only exception to this rule is for LSPs for which the State
   timeout timer is running (see Section 6).

   The PCE MAY include various attributes as per [RFC5440].  The PCC
   MUST use these values in the LSP instantiation, and local values for
   unspecified parameters.  After the LSP setup, the PCC MUST send a



Crabbe, et al.          Expires October 19, 2015                [Page 9]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


   PCRpt to the PCE, reflecting these values.  The SRP object in the
   PCRpt message MUST echo the value of the PCInitiate message that
   triggered the setup.  LSPs that were instantiated as a result of a
   PCInitiate message MUST have the C flag (Section 5.3.1) set in the
   LSP object.

   If the PCC determines that the LSP parameters proposed in the
   PCInitiate message are unacceptable, it MUST trigger a PCErr with
   error-type to be assigned by IANA, suggested value 24 (PCE
   instantiation error) and error-value=1 (Unacceptable instantiation
   parameters).  If the PCC encounters an internal error during the
   processing of the PCInitiate message, it MUST trigger a PCErr with
   error-type to be assigned by IANA, suggested vlaue 24 (PCE
   instantiation error) and error-value=2 (Internal error).

   A PCC MUST relay to the PCE errors it encounters in the setup of PCE-
   initiated LSP by sending a PCErr with error-type to be assigned by
   IANA, suggeseted value 24 (PCE instantiation error) and error-value=3
   (Signaling error).  The PCErr MUST echo the SRP-id-number of the
   PCInitiate message.  The PCEP-ERROR object SHOULD include the RSVP
   Error Spec TLV (if an ERROR SPEC was returned to the PCC by a
   downstream node).  After the LSP is set up, errors in RSVP signaling
   are reported in PCRpt messages, as described in
   [I-D.ietf-pce-stateful-pce].

   A PCC SHOULD be able to place a limit on either the number of LSPs or
   the percentage of resources that are allocated to honor PCE-initiated
   LSP requests.  As soon as that limit is reached, the PCC MUST send a
   PCErr message of type 19 (Invalid Operation) and value to be assigned
   by IANA (PCE-initiated limit reached) and is free to drop any
   incoming PCInitiate messages without additional processing.

   Similarly, the PCE SHOULD be able to place a limit on either the
   number of LSP initiation requests pending for a particular PCC, or on
   the time it waits for a response (positive or negative) to a
   PCInitiate request from a PCC and MAY take further action (such as
   closing the session or removing all its LSPs) if this limit is
   reached.

   On succesful completion of the LSP instantiation, the PCC assigns a
   PLSP-ID, and immediately delegates the LSP to the PCE by sending a
   PCRpt with the Delegate flag set.  The PCRpt MUST include the SRP-ID-
   number of the PCInitiate request that triggered its creation.  PCE-
   initiated LSPs are identified with the Create flag in the LSP Object.







Crabbe, et al.          Expires October 19, 2015               [Page 10]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


5.3.1.  The Create flag

   The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included
   here for easy reference.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                PLSP-ID                |Flags  |C|    O|A|R|S|D|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                        TLVs                                 //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 3: The LSP Object format

   A new flag, the Create (C) flag is introduced.  On a PCRpt message,
   the C Flag set to 1 indicates that this LSP was created via a
   PCInitiate message.  The C Flag MUST be set to 1 on each PCRpt
   message for the duration of existence of the LSP.  The Create flag
   allows PCEs to be aware of which LSPs were PCE-initiated (a state
   that would otherwise only be known by the PCC and the PCE that
   initiated them).

5.3.2.  The SPEAKER-IDENTITY-ID TLV

   The optional SPEAKER-IDENTITY-ID TLV defined in
   [I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP
   object in a PCRpt message, as an optional TLV for LSPs for which the
   C-flag is 1.  The SPEAKER-IDENTITY-ID TLV identifies the PCE who
   initiated the creation of the LSP on all PCEP sessions, a state that
   would otherwise only be known by the PCC and the PCE that initiated
   the LSP.  If the TLV appears in a PCRpt for an LSP for which the C
   flag is 0, the TLV MUST be ignored the and the PCE MUST send a PCErr
   message with Error-type 23 ("Bad parameter value") and error value 2
   ("Speaker identity included for an LSP that is not PCE-initiated").

5.4.  LSP deletion

   PCE-initiated removal of a PCE-initiated LSP is done by setting the R
   (remove) flag in the SRP Object in the PCInitiate message from the
   PCE.  The LSP is identified by the PLSP-ID in the LSP object.  If the
   PLSP-ID is unknown, the PCC MUST generate a PCErr with error type 19,
   error value 3, "Unknown PLSP-ID" ([I-D.ietf-pce-stateful-pce]).  A
   PLSP-ID of zero removes all LSPs that were initiated by the PCE.  If
   the PLSP-ID specified in the PCInitiate message is not delegated to
   the PCE, the PCC MUST send a PCErr message indicating "LSP is not
   delegated" (Error code 19, error value 1



Crabbe, et al.          Expires October 19, 2015               [Page 11]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


   ([I-D.ietf-pce-stateful-pce]).  If the PLSP-ID specified in the
   PCInitiate message was not created by a PCE, the PCC MUST send a
   PCErr message indicating that the LSP is not PCE-initiated, Error
   code 19, error value to be assigned by IANA, suggested value 9 (LSP
   is not PCE-initiated).  Following the removal of the LSP, the PCC
   MUST send a PCRpt as described in [I-D.ietf-pce-stateful-pce].  The
   SRP object in the PCRpt MUST include the SRP-ID-number from the
   PCInitiate message that triggered the removal.  The R flag in the SRP
   object SHOULD be set.

6.  LSP delegation and cleanup

   PCE-initiated LSPs are automatically delegated by the PCC to the PCE
   upon instantiation.  The PCC MUST set the delegation bit to 1 in the
   PCRpt that includes the assigned PLSP-ID.  All subsequent messages
   from the PCC to the PCE that initiated the LSP must have the
   delegation bit set to 1.  The PCC cannot revoke the delegation for
   PCE-initiated LSPs for an active PCEP session.  Sending a PCRpt
   message with the delegation bit set to 0 to the PCE that initiated
   the LSP results in a PCErr message of type 19 (Invalid Operation) and
   error-value value to be assigned by IANA, suggested value 7,
   (Delegation for PCE-initiated LSP cannot be revoked).  The PCE MAY
   further react by closing the session.

   A PCE MAY return a delegation to the PCC, to allow for LSP transfer
   between PCEs.  Doing so MUST trigger the State Timeout Interval timer
   ([I-D.ietf-pce-stateful-pce]) for that particular LSP.

   In case of PCEP session failure, control over PCE-initiated LSPs
   reverts to the PCC at the expiration of the redelegation timeout.  At
   this point, the LSP is an "orphan" until the expiration of the State
   Timeout timer.  To obtain control of a PCE-initiated LSP, a PCE
   (either the original or one of its backups) sends a PCInitiate
   message, including just the SRP and LSP objects, and carrying the
   PLSP-ID of the LSP it wants to take control of.  Receipt of a
   PCInitiate message with a non-zero PLSP-ID normally results in the
   generation of a PCErr.  If the LSP is an orphan, the PCC MUST NOT
   generate an error and MUST redelegate the LSP to the PCE.  The State
   Timeout timer for the LSP is stopped upon the redelegation.  After
   obtaining control of the LSP, the PCE may remove it using the
   procedures described in this document.

   The State Timeout timer ensures that a PCE crash does not result in
   automatic and immediate disruption for the services using PCE-
   initiated LSPs.  PCE-initiated LSPs are not be removed immediately
   upon PCE failure.  Instead, they are cleaned up on the expiration of
   this timer.  This allows for network cleanup without manual
   intervention.  The PCC SHOULD support removal of PCE-initiated LSPs



Crabbe, et al.          Expires October 19, 2015               [Page 12]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


   as one of the behaviors applied on expiration of the State Timeout
   Interval [I-D.ietf-pce-stateful-pce].  The behavior SHOULD be picked
   based on local policy, and can result either in LSP removal, or into
   reverting to operator-defined default parameters.

7.  Implementation status

   This section to be removed by the RFC editor.

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC6982].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to RFC 6982, "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   Two vendors are implementing the extensions described in this draft
   and have included the functionality in releases that will be shipping
   in the near future.  An additional entity is working on implementing
   these extensions in the scope of research projects.

8.  IANA considerations

8.1.  PCEP Messages

   This document defines the following new PCEP messages:

                 Value     Meaning               Reference
                   12      Initiate              This document

8.2.  LSP Object

   The following values are defined in this document for the Flags field
   in the LSP Object.




Crabbe, et al.          Expires October 19, 2015               [Page 13]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


                 Bit     Description           Reference

                  4      Create                This document

8.3.  SRP object

   The following values are defined in this document for the Flags field
   in the SRP Object.

                 Bit     Description           Reference

                  31     LSP-Remove            This document

8.4.  STATEFUL-PCE-CAPABILITY TLV

   The following values are defined in this document for the Flags field
   in the STATEFUL-PCE-CAPABILITY TLV

             Bit    Description                    Reference

              29    I (LSP-INSTANTIATION-          This document
                    CAPABILITY)

8.5.  PCEP-Error Object

   This document defines new Error-Type and Error-Value for the
   following new error conditions:


    Error-Type  Meaning
       10       Invalid Object

                 Error-value=8:  SYMBOLIC-PATH-NAME TLV missing
       19       Invalid operation

                 Error-value=6:  PCE-initiated LSP limit reached
                 Error-value=7:  Delegation for PCE-initiated LSP cannot
                                 be revoked
                 Error-value=8:  Non-zero PLSP-ID in LSP initiation
                                 request
                 Error-value=9:  LSP is not PCE-initiated
                 Error-value=10: PCE-initiated operation-frequency limit
                                 reached
       23       Bad parameter value

                 Error-value=1:  SYMBOLIC-PATH-NAME in use
                 Error-value=2:  Speaker identity included for an LSP
                                 that is not PCE-initiated



Crabbe, et al.          Expires October 19, 2015               [Page 14]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


       24       LSP instantiation error

                 Error-value=1:  Unacceptable instantiation parameters
                 Error-value=2:  Internal error
                 Error-value=3:  Signaling error

9.  Security Considerations

   The security considerations described in [I-D.ietf-pce-stateful-pce]
   apply to the extensions described in this document.  Additional
   considerations related to a malicious PCE are introduced.

9.1.  Malicious PCE

   The LSP instantiation mechanism described in this document allows a
   PCE to generate state on the PCC and throughout the network.  As a
   result, it introduces a new attack vector: an attacker may flood the
   PCC with LSP instantiation requests and consume network and LSR
   resources, either by spoofing messages or by compromising the PCE
   itself.

   A PCC can protect itself from such an attack by imposing a limit on
   either the number of LSPs or the percentage of resources that are
   allocated to honor PCE-initiated LSP requests.  As soon as that limit
   is reached, the PCC MUST send a PCErr message of type 19 (Invalid
   Operation) and value to be assigned by IANA, suggested value 6 (PCE-
   initiated LSP limit reached) and is free to drop any incoming
   PCInitiate messages for LSP instantiation without additional
   processing.

   Rapid flaps triggered by the PCE can also be an attack vector.  A PCC
   can protect itself from such an attack by imposing a limit on the
   number of flaps per unit of time that it allows a PCE to generate.
   As soon as that limit is reached, a PCC MUST send a PCErr message of
   type 19 (Invalid Operation) and value to be assigned by IANA,
   suggested value 10 (PCE-initiated operation frequency reached) and is
   free to treat the session as having reached the limit in terms of
   resources allocated to honor PCE-initiated LSP requests, either
   permanently or for a locally-defined cool-off period.

9.2.  Malicious PCC

   The LSP instantiation mechanism described in this document requires
   the PCE to keep state for LSPs that it instantiates and relies on the
   PCC responding (with either a state report or an error message) to
   requests for LSP instantiation.  A malicious PCC or one that reached
   the limit of the number of PCE-initiated LSPs, can ignore PCE
   requests and consume PCE resources.  A PCE can protect itself by



Crabbe, et al.          Expires October 19, 2015               [Page 15]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


   imposing a limit on the number of requests pending, or by setting a
   timeout and it MAY take further action such as closing the session or
   removing all the LSPs it initiated.

10.  Acknowledgements

   We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas,
   Cyril Margaria, Dhruv Dhody, and Raveendra Trovi for their
   contributions to this document.

11.  References

11.1.  Normative References

   [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-10 (work in progress), October 2014.

   [I-D.ietf-pce-stateful-sync-optimizations]
              Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
              and D. Dhody, "Optimizations of Label Switched Path State
              Synchronization Procedures for a Stateful PCE", draft-
              ietf-pce-stateful-sync-optimizations-02 (work in
              progress), January 2015.

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

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

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, April 2009.

11.2.  Informative References

   [RFC4657]  Ash, J. and J. Le Roux, "Path Computation Element (PCE)
              Communication Protocol Generic Requirements", RFC 4657,
              September 2006.

   [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", RFC 6982, July
              2013.





Crabbe, et al.          Expires October 19, 2015               [Page 16]


Internet-Draft      Stateful PCE - PCE-initiated LSP          April 2015


Authors' Addresses

   Edward Crabbe

   Email: edward.crabbe@gmail.com


   Ina Minei
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   Email: inaminei@google.com


   Siva Sivabalan
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose, CA  95134
   US

   Email: msiva@cisco.com


   Robert Varga
   Pantheon Technologies SRO
   Mlynske Nivy 56
   Bratislava  821 05
   Slovakia

   Email: robert.varga@pantheon.sk



















Crabbe, et al.          Expires October 19, 2015               [Page 17]


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